Hey folks,
Couple of thoughts from my end:
Is it possible to automate this process further by using another variable that is already centered? E.g., if I also loaded
areacello
(orthetao
or another variable that I know lives at the grid cell centers), then xgcm should be able to matchuo
’ s(lon, lat)
with one ofareacello
’s centers, face centers, edge centers, or edge corners, thus determining both the grid type (A, B, C, etc.) and the orientation (B-grid top right, B-grid bottom left, etc.) right?
That is essentially what I tried to do in xMIP/xmip/grids.py at main · jbusecke/xMIP · GitHub, but this could definitely use more work.
I agree 10000% with Ryans comments that this information should be included as metadata, it would make the logic above a lot more robust and accurate.
I started collecting the ‘real’ grid data for various models by emailing folks I know Collecting grid-metric files for CMIP6 output for cloud analysis - #11 by emaroon but I never got around to putting this data up. Having the original grid information would solve this problem if we can assume that all the outputs are actually unaltered. But I am not sure that is the case. I have encountered examples where I had the original grid file, e.g. indicating that a B grid with velocities in the lower left corner was used, but diagnosing from the provided lon/lat values told me that the position is in the upper/right corner or on the center. It is hard to tell whether this is an error with the provided coordinates, or if the data has actually interpolated - I think in some cases this is done, but again I know of no way to tell this from the data and I have not found any reliable documentation of this anywhere.
After all, the model developers know that they are using an Arakawa grid! It’s fundamental to all of the algorithms. This metadata belongs in the dataset itself, but CF doesn’t give a way to do that.
If I ever find a minute I would love to retrofit this in some way shape or form, but I think an important thing to do here from the community is to flag this as an issue to be addressed for CMIP7! I encourage you to contact the Data Access Task Team and describe this as a blocking issue.
This is an easier ask. It would be possible to create an API like this for xgcm. It would involve automatically generating a
Grid
object fromuo
(only possible with sufficient metadata, as described above), defining what you mean bygrid_type='C'
andposition='u'
, and them wrapping theGrid.interp
operation.We would welcome a PR to xgcm to add that sort of functionality.
Unless I misunderstand this ask, you can already use grid.interp_like for this?