I’m working on some calculations involving precipitation and omega using CMIP6 models. However, I’ve encountered an issue with some models, such as ‘ACCESS-ESM1-5’, where the latitude and longitude grids for precipitation and omega don’t match.
I need both precipitation and omega to be on the same grid. Is it okay to reindex one of the variable grids using rearest method?
Has anyone faced a similar issue, or can anyone suggest a solution?
I wouldn’t use nearest neighbor for this. Within models, variables are regridded from corners, or edges to center and vice-versa all the time, and from what I’ve seen in another model, this is done using finite differences. I think I’d try first with bilinear interpolation to interpolate omega onto the precip grid, because I expect omega to be smoother and less susceptible to interpolation errors than precip. Others will probably have more informed opinions on this.
Hi @chaithra – I agree with @huard’s rationale to remap omega to the precipitation grid. You could use xESMF or xcdat (xcdat uses either regrid2 or xesmf under the hood) for remapping (these both work with xarray). They have bilinear interpolation (and can handle circular coordinate systems) or you could also consider conservative regridding if you wanted to regrid precipitation and make sure that you conserved total precipitation globally. Others might have additional regridder suggestions.
I think @huard is on the right track here. These variables seem to be on different grid positions (cell face vs center). Remapping would probably work, but is expensive. You could also try to use xgcm to interpolate between grid positions. But to verify the assumption I would suggest to check that the lat/lon values of one variable are captured by the lat_bounds/lon_bounds of the other. If true I would assume that no additional interpolation was carried out and the variables are simply output on different grid positions. A simple linear interpolation on the logically rectangular grid could thus be a good way to co-locate the variables.
On a more general note this sort of thing is (to my knowledge) totally undocumented for CMIP data, which is pretty bad, since it leaves the detective work to the user!
Unfortunately they skipped over the more common scenario of staggered quad grids! AFAIK there is still no solution in CF conventions for how to encode this sort of information into the files.
For ACCESS models you’re more than welcome to hop on over to the ACCESS Hive Forum and see if someone else has already discussed that issue:
Or sign up and ask for more information, though I think the suggestion about staggered grids is likely correct, but I personally don’t know much about the atmospheric fields.
AFAIK there is still no solution in CF conventions for how to encode this sort of information into the files.
