Basin coordinate in CMIP(6)

[zklaus]

In a recent discussion about AMOC, we stumbled across a peculiarity with the basin coordinate in CMIP6. In the tables, it is listed with out_name as basin which we interpret to mean that that should be the var_name of the coordinate (see here). However, it seems this is really meant to refer to the dimension itself. It works reasonably well in most cases because most dimensions have a dimensional coordinate associated with them, i.e. there is a coordinate variable in the file that has the same name as the dimension. But this is not a hard rule. For basin that doesn't happen because the coordinate is made of character data and thus needs an additional dimension for the string length. CMIP6 Model Output Requirements: File Contents and Format, Data Structure and Metadata
makes it clear how this is intended to be encoded, see also Example 4 in the same document) (ibid).

How should we deal with this? A simple ad-hoc fix is to rename the variable as shown by @dhohn. Alternatively, we could base the comparison on the dim names. That would solve related problems with land type and as yet unknown string coordinates, but might need a change in Iris to preserve the dimension name. Maybe there are other approaches?

@ESMValGroup/esmvaltool-coreteam, any thoughts?

[ledm]

We wrote the weirdly specific extract_named_regions preprocessor to deal with the region/basin coordinate. Does this help?

ESMValCore/esmvalcore/preprocessor/_area.py

Line 315 in 9d5cceb

def extract_named_regions(cube, regions):

[dhohn]

Hi @zklaus @ledm ,

I dont think I can follow all the nuances of the CF standard coordinate requirements. But the following dataset fixes are working for me to make the coordinates usable in esmvaltool: https://github.com/ESMValGroup/ESMValCore/compare/main...dhohn:fix_datasets_amoc?expand=1

Would it be ok to open a PR for these changes?

[dhohn]

Adressed by #1612