Create an inventory of features to drop in v4

[erikvansebille]

This Issue tracks a list of features/capabilities in Parcels that we want to keep, and which to drop (at least initially)

Some features we don't want to keep in Parcels v4-alpha:

• Support for AnalyticalAdvection under the hood Remove analytical output #1928
• time_periodic in FieldSet
• transpose in FieldSet
• to_write="once" for ParticleFile (but need an alternative)
• ParcelsRandom -> implemented in Removing ParcelsRandom and rng for v4 #1858
• NestedFields (at least for v4-alpha) Remove NestedField #1929
• Removing grid.py and time_origin for v4 #2068 (because all time can be np.datetime64 now that JIT is dropped)
• postIterationCallbacks functions in pset.execute() (Minimal v4 particleset #2060 )
• SGrids and time-varying depth dimensions (since they can be handled with the CROCO-type-advection kernel?)
• Field chunking
• Field.cell_edge_sizes and Field.cell_areas
• Avoid casting field input data to float32 #1607
• indices to select subdomain in the FieldSet creation
• Remove methods for computing halos #1898
• Remove latitude flipping in Grid #1902
• Remove deferred loading of FieldSets #1908, Remove Grid.time_full #1930
• Field.set_scaling_factor() Removing scaling_factors #1924
• FieldSet.compute_on_defer
• Remove vmin and vmax from Field #1910
• FieldSet and Field writing Removing Field.to_write and FieldSet.to_write methods #1938
• Re-evaluating support for timevarying depth dimension #1914
• Remove timestamps keyword from Field and FieldSet #1918
• Removing FieldSet.from_parcels() method #1935
• Reconsider FieldSet.from_xarray_dataset() #1940

[VeckoTheGecko]

• time_periodic in FieldSet

just noting that this would extend to Field.time_periodic and would result in Grid.period being dropped as well. Quite keen for this to go - should I work on this @erikvansebille ?

[erikvansebille]

• time_periodic in FieldSet

just noting that this would extend to Field.time_periodic and would result in Grid.period being dropped as well. Quite keen for this to go - should I work on this @erikvansebille ?

Yes, feel free to take this up. Should(?) be a relatively simple feature to remove

[VeckoTheGecko]

• postIterationCallbacks functions in pset.execute()

This was introduced in #764 . It looks like its main usage was as a hook for the test_from_netcdf_memory_containment test, would that be correct @erikvansebille or is there some usecase I'm missing?

[erikvansebille]

• postIterationCallbacks functions in pset.execute()

This was introduced in #764 . It looks like its main usage was as a hook for the test_from_netcdf_memory_containment test, would that be correct @erikvansebille or is there some usecase I'm missing?

Yep indeed, this was introduced by @CKehl to analyse memory use, for his study published at https://doi.org/10.1016/j.cageo.2023.105322. Keeping it has the advantage that we can monitor memory usage, but we don't do that now so I'm not sure how useful it is...