Advice for MRI-ESM2-0 SI grids

[BrendanMD]

Hi. I am having issues with the SI grid for MRI-ESM2-0. I am using cdo to do a conservative remap of siconc to a regular grid. I have attached a figure of the result.

With other tripolar grids I simply trim a one cell border and the discontinuity in remapping goes away, but this is not working for the MRI grid. Does anyone on the ESMValTool team have experience with this?
(I am getting even stranger results from CAMS-CSM1-0, but that is a whole other question).
(EDIT: Unless I am seeing things, both CAMS-CSM1-0 and MRI-ESM2-0 issues resolved when I upgraded cdo to 2.10.0)

[valeriupredoi]

@zklaus any ideas? 🍺

[zklaus]

Sorry, I don't have time for very deep debugging, but after looking into this for 30 mins or so, it seems to me that the bounds on 2d coordinates are not correct. @BrendanMD, I suggest you take a good hard look at the bounds, probably best for one individual cell close to the north pole to see what's going on.

[zklaus]

For example, in the following figure, I plot the point (i.e. the cell center) and the bounds (i.e. the 4 vertices) for the grid point (360, 0), i.e. the westernmost point in the third row from the top. The blue dot at the bottom is the cell center and the 4 colored dots are supposed to be the 4 corners of the cell. Clearly, the center is not inside that boundary and given boundary seems to indicate a degenerate cell.

[bouweandela]

Note that this discussion board is about the ESMValTool, if you're having issues with CDO I would recommend contacting CDO support.

To do this with ESMValTool, you could try using the 'generic' regridding scheme provided by iris-esmf-regrid. Instructions for setting up a regridding preprocessor function in the ESMValTool recipe are available here. If you'd rather just use the Python function to regrid the data, you can find the documentation here.

[bouweandela]

Couldn't agree more on cooperation, it's the way to go!

If there is a proper database of these issues where CMIP6 data users can search for answers to their problems, please let me know.

Yes, there is the CMIP6 Errata page for this. We recommend reporting issues so they can be listed there and we also try to do this ourselves, see e.g. talk in the ESMValCore issues labelled CMOR. Unfortunately, the experience with reporting issues is quite mixed: if I understood it correctly, you're supposed to report the issue through the modelling group that created the data and while some modelling groups are very responsive, others are not. In any case, it's always worth a try to contact the modelling group, you can find the contact email in the global netcdf attribute of the CMIP6 data files, the attribute is called 'contact'.

[BrendanMD]

I do use the Errata page extensively, and have written many, many emails to the CMIP groups. The fact remains that it is too expensive for the modelling groups to fix these mistakes. They simply do not have the human resources. Many of the ocean grids have halos and/or degenerate points that break software like cdo. I have brought up with the cdo team the idea of having a tool to filter bad grids, but from their point of view, it is a format compliance problem.

[bouweandela]

In the ESMValTool we solve this problem by implementing fixes (issues) for the data. These are python functions that will be applied to the model data before doing any further processing. In case of a faulty grid, they could for example replace it with the correct grid. See ESMValGroup/ESMValCore#1673 and ESMValGroup/ESMValCore#1764 for similar work on CORDEX datasets.

In the longer term, it would be better if the people organizing the CMIP would set up a central repository for these, as there are several software packages out there that implement the same concept, e.g. xmip, daops, cube-helper, etc..

[BrendanMD]

Thanks so much bouweandela. Hopefully CMIP7 will implement some of these cooperative practises. For the point of view of a lone data user it is obvious not enough resources were allocated for CF/CMIP compliance nor for communications with data users. My personal worry is that people will use the data incorrectly e.g. not realize they must rotate ocean vector data to true coordinates.

I opened a topic on the CF-Metadata discussion suggesting they adopt the grid definition meta data standards proposed by V. Balaji (gridspec). Adopting a grid standard such as this, coupled with the seminal grid interpolation work by Grady B. Wright, would effectively remove the burden from users for interpolation/vector field rotation, for any type of Arakawa or unstructured grid. This would include being able to properly interpolate and rotate vector fields from u and v grid points onto common grid locations. I also proposed this idea to the cdo software team.

If anyone wants links to papers on these resources, please let me know. I do not have them with me at the moment. I will try to remember to post them here later today.

[BrendanMD]

Gridspec: A standard for the description of grids used in Earth System models
Grady B. Wright's publications page
Full disclosure. I have not read any of Dr.Wright's publications. The math is way above my pay grade. What caught my eye, several years ago, was this presentation on decomposition of vector fields and his other slides from this conference. I corresponded with him briefly. His work has progressed significantly, but like much good practical science these days, getting funding was problematic.