Vertical Search for unstructured Grids

[fluidnumericsJoe]

An interesting, subtle issue with the UxArray.uxgrid has turned up and impacts our move to pushing search underneath the XGrid and UXGrid classes. The UxArray.uxgrid class does not contain information about the vertical grid at all; instead it holds information about the lateral unstructured grid only.

tests/v4/test_uxarray_fieldset.py::test_fesom2_square_delaunay_uniform_z_coordinate_eval <uxarray.Grid>
Original Grid Type: regional_delaunay
Grid Dimensions:
  * n_node: 400
  * n_face: 721
  * n_max_face_nodes: 3
Grid Coordinates (Spherical):
  * node_lon: (400,)
  * node_lat: (400,)
Grid Coordinates (Cartesian):
Grid Connectivity Variables:
  * face_node_connectivity: (721, 3)
Grid Descriptor Variables:

The vertical grid is housed in the DataArray as a dimension and coordinate. There are typically two options for the vertical grid dimension that are relevant, depending on whether the Field is centered on vertical layers or placed at vertical layer faces.

Within our UxGrid object, I'd propose that we require a vertical dimension to be passed in during construction. We should assume that the vertical dimension is the vertical layer faces (in uxarray this is the nz dimension); the layer centers can be easily calculated on the fly. This would enable vertical searching

[VeckoTheGecko]

Initially I was wondering whether it's something worth upstreaming into uxarray.Grid, but after reading the docstring

Represents a two-dimensional unstructured grid encoded following the UGRID conventions and provides grid-specific functionality.

It seems the vertical dimension is intentionally out of scope for this class

Within our UxGrid object, I'd propose that we require a vertical dimension to be passed in during construction. We should assume that the vertical dimension is the vertical layer faces (in uxarray this is the nz dimension); the layer centers can be easily calculated on the fly. This would enable vertical searching

I think this is a good approach

[erikvansebille]

About the vertical dimension; don't forget that this can also be a 4D array of depth as a function of (i, j, k and time). So we should be more flexible than assuming a 1D array of z(k)

[VeckoTheGecko]

To clarify, this issue is only about the unstructured case (structured grids are handled separately). @fluidnumerics-joe can the depth dimension in uxarray be spatially and temporally varying?

[fluidnumericsJoe]

@VeckoTheGecko - For unstructured grids, the vertical coordinate can vary with face id and time. e.g. for FESOM2 see https://fesom2.readthedocs.io/en/latest/vertical_discretization.html

The thinking is to approach this incrementally. The only test cases I've been given have the vertical coordinate as 1-d . Further, uxarray hasn't seen a FESOM2 input file with topography (where z would also vary with face id) or with moving ALE coordinate so IO would need to be implemented there first anyway.