Reconstructing grid metrics from cf type bounds

[jbusecke]

@dcherian just made me aware of this package and it looks super cool (have only skimmed the exmpamples so far). I noticed in the last example that you are recreating a (simplified) grid cell area. I have recently added the ability to estimate grid distances from cf type 'bounds' (two bounding values per logical axis) and verticies/vertex-points (4 bounding points representing cell corners).

This enables us to recreate grid metrics for many CMIP6 models and then use xgcm (my upcoming earthcube presentation gives some examples.

I think that this sort of functionality is probably of use to a broader community than 'just' CMIP6 users. Originally I was planning to suggest implementing the 'recalculation' of metrics upstream in xgcm, but when I saw this package, I thought perhaps it would make sense to add it here?

Just wanted to quickly drop this here and see if there is interest and also to avoid possible duplication of efforts here and over at xgcm.

cc'ing @rabernat

[dcherian]

Yes, I think this belongs here. We should figure out how to do this properly though.

I think we want to follow the "Cell Measures" part of the documentation (http://cfconventions.org/Data/cf-conventions/cf-conventions-1.8/cf-conventions.html#cell-measures).

To indicate extra information about the spatial properties of a variable’s grid cells, a cell_measures attribute may be defined for a variable. This is a string attribute comprising a list of blank-separated pairs of words of the form "measure: name". For the moment, "area" and "volume" are the only defined measures, but others may be supported in future.

There are two approaches I can think of:

1. we could have newds = ds.cf.update.cell_measures() which will use bounds info to calculate areas and/or volumes for different variables; assign these "measures" to a new dataset and assign the ds.VARIABLE.attrs["cell_measures"] = "area: area_measure_name" attributes as necessary. The sub-namespace update (or some other better name) should make it clear that the functions in this namespace "update" or "add things to" the existing Dataset and return a new Dataset with extra variables.

2. we could have measures = ds.cf.calc.cell_measures() or measures = da.cf.calc.cell_measures() that calculates area and/or volumes and returns an xarray object with only area and volume in the coords i.e. no variables from the input dataset are returned.

In both cases, we would choose some unique name based on the dimensions: area_g, area_c mitgcm dimensions for example?

For interactive use, I prefer approach 1. When the attributes are set on the input dataset, they are now interpretable, and we can do newds.cf.weighted("area")

For library use that just want to get the measures (like xgcm), option 2 would be preferable.

This suggests that we need two namespaces:

1. .update for interactive use.
2. .calc for library use. The two namespaces should have the same function names, e.g. cell_measures.

What do you think?

PS: The conventions have this to say about rectangular grids:

For rectangular longitude-latitude grids, the area of grid cells can be calculated from the bounds: the area of a cell is proportional to the product of the difference in the longitude bounds of the cell and the difference between the sine of each latitude bound of the cell. In this case supplying grid-cell areas via the cell_measures attribute is unnecessary because it may be assumed that applications can perform this calculation, using their own value for the radius of the Earth.

So approach 1 is saving a redundant variable but I don't think this is a dealbreaker.

[dcherian]

Iris has some features in this space: https://scitools.org.uk/iris/docs/latest/iris/iris/analysis/cartography.html#iris.analysis.cartography.area_weights

[jbusecke]

Oh interesting. Ill def dig deeper next week (taking a long weekend off w/o any github and work haha). But I am motivated to do this properly (and get it out of cmip6_preprocessing).