# Interpolate onto different Arakawa-grid positions

**URL:** <https://discourse.pangeo.io/t/interpolate-onto-different-arakawa-grid-positions/4560>\
**Category:** Uncategorized\
**Created:** [October 2, 2024, 7:35am UTC](https://discourse.pangeo.io/t/interpolate-onto-different-arakawa-grid-positions/4560 "2024-10-02T07:35:27Z")\
**Posts on this page:** 1\
**Showing post:** 9

<div class="post-metadata">

**Author:** ![jbusecke](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.pangeo.io/jbusecke/32/118_2.png) [@jbusecke](https://discourse.pangeo.io/u/jbusecke)\
**Post date:** [October 10, 2024, 8:18pm UTC](https://discourse.pangeo.io/t/interpolate-onto-different-arakawa-grid-positions/4560/9 "2024-10-10T20:18:28Z")

</div>

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` (or `thetao` or another variable that I know lives at the grid cell centers), then xgcm should be able to match `uo`’ s `(lon, lat)` with one of `areacello`’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](https://github.com/jbusecke/xMIP/blob/main/xmip/grids.py), 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](https://discourse.pangeo.io/t/collecting-grid-metric-files-for-cmip6-output-for-cloud-analysis/935/11) 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](https://wcrp-cmip.org/cmip7-task-teams/data-access/) 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 from `uo` (only possible with sufficient metadata, as described above), defining what you mean by `grid_type='C'` and `position='u'`, and them wrapping the `Grid.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](https://xgcm.readthedocs.io/en/latest/api.html#xgcm.Grid.interp_like) for this?

---

_[View the full topic](https://discourse.pangeo.io/t/interpolate-onto-different-arakawa-grid-positions/4560)._