parcels
parcels copied to clipboard
Main code for Parcels (Probably A Really Computationally Efficient Lagrangian Simulator)
Make changes to the particleset to handle the scenario when the `fieldset` is a `uxarray` object.
`FieldSet.from_xarray_dataset()` fundamentally works off of the assumption that a single dataset contains all field information, which may not be correct as the field information can be scattered across multiple files...
- [x] Chose the correct base branch (`main` for v3 changes, `v4-dev` for v4 changes) `numpy.testing.assert_allclose` has a better Pytest error message. Before: ``` > assert np.allclose(pset.u, lat, rtol=1e-6) E...
As discussed in person, and mentioned in #1844, in `v3` there is some coupling in the codebase between FieldSet and ParticleFile in order to support the writing of analytical trajectories....
In `main` we have `check_fieldsets_in_kernels` which defines restrictions on the FieldSet. I think that these can be implemented a different way directly via the kernel API in v4. I propose...
We need to decide to what extent we want to support broken or xarray incompatible metadata in Parcels (e.g., for units). I am of the mindset that we rely on...
In v4, the idea is to change the API of `Field.eval()` to use explicitly `particle.ei` instead of `particle as last argument. And the output of eval could then also be...
To support timevarying depth we have `Field.set_depth_from_field()` and "not_yet_set" in the dimension dict (this is outlined in `tutorial_timevaryingdepthdimensions.ipynb`). This feature, however, is quite intertwined with the codebase (in `FieldSet._check_complete` as...
- [x] Chose the correct base branch (`main` for v3 changes, `v4-dev` for v4 changes) - xref #1844
Some of the kwargs in the Field initialiser (e.g., `dataFiles`) aren't used in the codebase, or they're used for tasks that will be implemented via other means in the v4...