Update `add_bounds` to support 2D coordinate variables.

[dcherian]

Should we change the name of this function?

Some relevant existing code is here: https://github.com/NCAR/pop-tools/blob/d771f8d7280696c890bb6a21255c5ad298c8b373/pop_tools/grid.py#L324-L363

cc @huard

[dcherian]

@mgrover1 I think pop_tools code is a decent guess at the bounds points for a 2D variable.

cc @jbusecke

[jbusecke]

Is that pop specific? I think that we could really use a package/module that is general and does these things + estimate grid metrics from curvilinear grids. But I guess this is not really within the limits of cf-conventions (if it goes beyond a simple multiplication of metrics)?

[mgrover1]

@mgrover1 I think pop_tools code is a decent guess at the bounds points for a 2D variable.

cc @jbusecke

Is this different than the grid corner function within pop-tools?

[jbusecke]

If you have the corners, the bounds should be trivially just be interpolated between them?

[zxdawn]

The xgcm has a function to calculate the boundary. Please see this example.

[dcherian]

Nice! A PR would be very welcome though we don't want to add an xgcm dependency. In fact, perhaps xgcm can depend on cf-xarray instead for bounds generation (cc @jbusecke )

[jbusecke]

Hey @zxdawn, the autogenerate module is somewhat defunct (since it relies on an 'extrapolate' boundary handling, which our newest refactor does not support anymore https://github.com/xgcm/xgcm/issues/497). This is not well documented on our end, sorry.

Overall I want to move this functionality out of xgcm entirely! Instead I think the community needs a specific tool (maybe this is cf-xarray?) that achieves the following things:

1. Create some sort of grid defined by lon/lat values (see a related discussion over at xesmf)
2. From that grid, infer cell corners (bounds can be inferred from the corner points?) and add these to an xarray dataset with some naming convention (that xesmf recognizes) and metadata that can be automatically ingested by xgcm.
3. From the grid points calculate horizontal metrics (cell area, distance between grid points) for different grid positions (e.g. located on different grid points.

There are several use cases that could enter this logic at various stages:

• Users who have all the C-grid positions and just want to recompute the area (https://github.com/jbusecke/cmip6_preprocessing/issues/237) and would just use 3.

   full_grid_ds =  calculate_metrics(cmip6_c_grid_ds)
   grid = Grid(full_grid_ds) # metrics should ultimately be encoded in metadata and parsed automatically

• Users who have an observationally gridded dataset (coordinates only on cell centers) and want to use xgcm to calculate stuff. This would use 2. and 3.

   argo_finite_grid = infer_grid_positions(argo_gridded_ds)
   full_grid_ds =  calculate_metrics(argo_finite_grid)
   grid = Grid(full_grid_ds)

• xesmf users who want to use 'conservative' interpolation. This would use 1. and 2.

    target_grid = grid_global(..., center_only=False) # In a simple case of a regular lon/lat grid this should already produce the cell corners?
    regridder = xe.Regridder(some_ds, target_grid, ...)

All of this does not actually need xgcm or xesmf (I think this can be achieved with pure xarray), but it would be tremendous if the result of this could readily be parsed by both xgcm (we might need to do some work over there on updating our parsing) and xesmf.

For me the question here is firstly: Do all of these stages fit into the scope of cf-xarray? I think 1. and 2. should definitely fit, but does 3.? If not is it worth to have a separate package for that? I have long been wondering how to do the recalculation for metrics 'properly'. GCMs do that routinely, right? Can we extract that logic somehow?

[jbusecke]

I feel there might be some synergy with https://github.com/pytroll/pyresample/issues/440#issuecomment-1176495056 here.

[dcherian]

From that grid, infer cell corners (bounds can be inferred from the corner points?) and add these to an xarray dataset with some naming convention (that xesmf recognizes) and metadata that can be automatically ingested by xgcm.

The "convention" is sgrid AFAICT though it always confuses me! and bounds to corners and corners to bounds are totally within scope here IMO. We already have it! Only thing that is missing is 2D autogeneration and am definitely happy to add that.

rom the grid points calculate horizontal metrics (cell area, distance between grid points) for different grid positions (e.g. located on different grid points.

IMO xgcm should interpret sgrid and do this.

[jbusecke]

I am not quite decided on whether this functionality should be living in xgcm but I think we have some consensus on the fact that the other elements should indeed live in cf-xarray (which we can add as a dependency in xgcm)?