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:

• [x] Support for AnalyticalAdvection under the hood #1928
• [x] time_periodic in FieldSet
• [x] transpose in FieldSet
• [ ] to_write="once" for ParticleFile (but need an alternative)
• [x] ParcelsRandom -> implemented in #1858
• [x] NestedFields (at least for v4-alpha) #1929
• [x] #2068 (because all time can be np.datetime64 now that JIT is dropped)
• [x] postIterationCallbacks functions in pset.execute() (#2060 )
• [x] SGrids and time-varying depth dimensions (since they can be handled with the CROCO-type-advection kernel?)
• [x] Field chunking
• [x] Field.cell_edge_sizes and Field.cell_areas
• [x] #1607
• [x] indices to select subdomain in the FieldSet creation
• [x] #1898
• [x] #1902
• [x] #1908, #1930
• [x] Field.set_scaling_factor() #1924
• [x] FieldSet.compute_on_defer
• [x] #1910
• [x] FieldSet and Field writing #1938
• [ ] #1914
• [x] #1918
• [x] #1935
• [x] #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...

[VeckoTheGecko]

I think we should also remove deferred_load (opting for the deferred_load = False path in the code). This will be handled down the line by xarray, and we default to deferred_load = True in (all?) the execution flow of Parcels.

Removing this will help with refactoring.

[erikvansebille]

I think we should also remove deferred_load (opting for the deferred_load = False path in the code). This will be handled down the line by xarray, and we default to deferred_load = True in (all?) the execution flow of Parcels.

Removing this will help with refactoring.

Yes, I agree. deferred_load=True is only for very large (>10GB) hydrodynamic datasets, and we don't test these in our suite. So we can remove deferred_load without crippling the CI

[VeckoTheGecko]

Ah yes. I agree. Let's drop deferred_load=True (not deferred_load=False). That would be much clearer.