Add skeleton Iris regridder scheme

[stephenworsley]

This PR adds the bare bones of a regridding scheme. To make this scheme minimally functional, it should be sufficient to fill out the _make_mint_regridder and _regrid functions. This should allow regridding in Iris by calling:

result = src.regrid(tgt, MINTScheme())

This code should be able to handle a cube with data stored on mesh edges. Other cases are planned to be handled but these can be tackled in a different PR.

TODO for this section of work:

• [ ] Handle metadata in _create_cube.
• [ ] Add error handling for incompatible grids/meshes.
• [ ] Add basic docstrings.
• [ ] Add minimal unit tests.

[pletzer]

Thanks @stephenworsley that's a great start!

[pletzer]

@stephenworsley Are we making some assumptions about the cubes? (grid or mesh?) Will methods such as "x = cube.mesh.node_coords.node_x.points" work for grids as well?

[pletzer]

Hi @stephenworsley Ami I correct to assume that your primary focus is on 1d axes? Not curvilinear coordinates or meshes?

[pletzer]

@stephenworsley The _regrid method will need to take u and v fields (as opposed to data). For a structured grid, u and v will have different dimensions, (nx+1)ny and nx(ny+1) for Arakawa C grid where nx and ny are the number of cells in x and y. The coordinates should have shape (nx + 1)*(ny + 1). Do we agree on this?

[stephenworsley]

@stephenworsley Are we making some assumptions about the cubes? (grid or mesh?) Will methods such as "x = cube.mesh.node_coords.node_x.points" work for grids as well?

For the time being, yes, we're making assumptions for the sake of simplicity. My thinking is that we can focus on a simple case for the time being (data stored on mesh edges) and add logic for the handling of other cases once we've demonstrated that this structure works. This is similar the the approach I've taken in iris-esmf-regrid where I'm currently bringing together the functionality to work on both meshes and grids https://github.com/SciTools-incubator/iris-esmf-regrid/pull/198.

[pletzer]

@stephenworsley

How should we represent the field's staggering? Some fields will be on vertices, others on cells and yet others (like u and v) will be on Arakawa C or D. In Iris, a cube contains the field and its coordinates. There is currently no metadata in Iris to designate whether a field is on cells, edges (Arakawa D) or faces (Arakawa C). Moreover, the shape of the data matches the grid size. Here are two possibilities:

1. We have one grid and different fields attached to different grid elements. Ie the fields will not have all the same dimensions. Eg a cell field will have dimensions (nx-1)(ny-1), a u field might have nx(ny - 1), etc.
2. Each cube/field will have its own set of coordinates and these will be the centre point of the mesh element (eg cell centres, edge centres, etc.)

[pletzer]

In the case of vector field regridding, we will have (u, v) cubes. The data should be a tuple of cubes.

[pletzer]

Ok to raise an error if some cells are not quads?

[pletzer]

Deliverable: a function in Iris to regrid (u, v) from cubed-sphere to lat-lon and reversely. Might involve converting lat-lon representation to ugrid (?)

[pletzer]

Regarding https://github.com/pletzer/mint/pull/95#issuecomment-1275193905, I don't think 1) will work unless the cell bounds are also provided. This is because MINT needs the start/end points of each edge.

Hence, approach 2) has the advantages of: (a) being more concise (one grid instead of two), (b) the grid does not need to have cell_bounds defined and (c) simpler to implement ( otherwise would have to infer the start/end points of each edge from the individual u, v grids by using the cell_bounds)

[stephenworsley]

I've spent some time looking up existing conventions for Arakawa grids and I've found SGRID, which as far as I can tell describes only grids with 1D coordinates and COMODO which looks like it describes 2D coords but I can't figure out how it describes bounds. These also both look like they haven't been maintained in a while.

[pletzer]

Thanks @stephenworsley . I think all these standards are based on: (1) u, v having different dimensions [eg (n, m_u), (n_v, m) where m_u = m - 1 and nv = n - 1 for Arakawa C], (2) they all attach different coordinates to u and v, and these correspond to the edge centres and (3) they allow for multiple components to be attached to the edges. However, they are not clear about what they mean by u and v? Is u the zonal component? Even in on a curvilinear grid?

[pletzer]

The plan is to have an interface that covers both comodo and sgrid. The interface will take u and v fields and assume these to be perpendicular/aligned to the edges. The vector regridder (MINT) needs the endpoint coordinates of the edges, which the vertices of the grid. The interface will receive (u, v), (x, y), the dimensions of x and y are (n, m). Depending on the dimensions of u and v, we figure out whether it is Arakawa C or D.

[pletzer]

Task: create a few datasets that conform to sgrid and/or comodo