Skip to content

Remove Field and Grid classes from the public API #2630

@VeckoTheGecko

Description

@VeckoTheGecko

Thinking about this today - what is the benefit of even having Field (and FieldSet.add_field) in the public API?

If a user wants to add a field, either:

  • The grid is already in fset1
    • (in-memory data) before constructing fset1 - modify the xarray dataset directly by adding a dataarray before passing to .from_...
    • (on-disk data) before constructing fset1 - update the netcdf/zarr dataset itself adding a dataarray, ingest in Xarray then pass to .from_...
  • The grid isn't already in a fieldset
    • construct a fieldset using from_....
    • do fset1 + fset2

Similarly I don't see the benefit of having XGrid/UxGrid in the public API. I am personally not opposed to having users go through .from_... (i.e., go through SGRID or UGRID) if they want to define their own custom grids - in fact I think that would be more robust, and less ambiguous than if we were to expose additional interfaces with no(?) benefit.

Originally posted by @VeckoTheGecko in #2587


This ideally also means that we update a lot of our test suite (that does manual tinkering of individual fields where that behaviour isn't explicitly being tested)

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    Status

    Backlog

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions