Add support for particleset.fieldset as a uxarray object

[fluidnumericsJoe]

Make changes to the particleset to handle the scenario when the fieldset is a uxarray object.

[fluidnumericsJoe]

I've started really re-working this in the https://github.com/OceanParcels/Parcels/tree/feature/uxarray_xarray_fields branch.

At the moment, most of the work is being done in the xfield.py module.

This module defines the XField and XVectorField classes. XField is meant to be a thin wrapper around the xarray.DataArray or uxarray.UxDataArray classes that enforces a uniform schema (ensuring appropriate dims, coords, attributes, and attribute values) and permits dynamic definition of the interpolation scheme as a Callable function with a validated signature (matching the signature of the provided XField._interp_template function). When no interpolation function is provided, the default is to use XField._interp_template`, which simply returns zeros for the evaluation.

Additionally, I'm working on preserving some of the functionality from the original Field class; specifically, I've retained the Field.igrid and Field.allow_time_extrapolation attributes in addition to a pointer to the parent Fieldset object. With the XVectorField class, we will be able to create UV attributes in the XFieldset class to keep much of the same programming patterns that currently exist in Parcels modules that leverage the new XFieldset.

After reviewing xarray and uxarray documentation and playing around with creating sample xarray and uxarray datasets for the stommel gyre configuration, it became clear that leveraging field and fieldset as thin wrappers around the (Ux)DataArray and (Ux)Dataset classes (respectively) is quite a major rewrite of the Field and Fieldset classes. Ultimately, yes, XField and XFieldset will be renamed ultimately back to Field and Fieldset.

[fluidnumericsJoe]

@erikvansebille and @VeckoTheGecko - I've started summarizing some of the changes I've made (and am planning) in this hackmd document Any feedback is welcome.

[VeckoTheGecko]

Overall, I think that looks good (namely the attributes available, and considerations on units and time extrapolation - didn't look into the unstructured naming conventions) . I can imagine this changing somewhat as development progresses

[fluidnumericsJoe]

I can imagine this changing somewhat as development progresses

I agree. This has been slowly evolving as I'm working on the implementation and the stommel examples.

[erikvansebille]

@erikvansebille and @VeckoTheGecko - I've started summarizing some of the changes I've made (and am planning) in this hackmd document Any feedback is welcome.

I agree that it looks good! I also added a comment about the fieldtype versus UnitConverter. fieldtype is now used to assigna. UnitConverter if it can't be picked up from the Field name (see https://docs.oceanparcels.org/en/latest/examples/tutorial_unitconverters.html#Adding-a-UnitConverter-object-to-a-Field), but it would be nice to have a more pythonic way to add UnitConverters (e.g. a method Field.add_UnitConverter()?)