QA/QC wishlist

[bouweandela]

Here is a list of things that prevented the ESMValTool community from working with CMIP6 data that we would like to avoid in CMIP7. This is summarized from the fixes in ESMValCore.

Can be checked per file

Can be checked without accessing data

• Parametric vertical coordinates were unusable: https://cfconventions.org/cf-conventions/cf-conventions.html#parametric-v-coord. I have not been able to find a single CMIP6 file that follows the CF conventions for these coordinates. Could this be a bug in CMOR?
• Wrong variable name for coordinate (example: variable name/out_name latitude instead of lat)
• Wrong or missing standard_name, long_name attribute for coordinate
• Invalid value for parent_time_units attribute (for example: days since 1850-01-01-00-00-00)
• Missing positive attribute for vertical coordinates
• _FillValue or missing_value attribute dtype does not match data dtype (for example: data dtype is float32 and missing value dtype is float64)
• Missing scalar coordinate (e.g. height2m, typeland)
• Missing coordinate bounds (for example for the latitude coordinate)

Need to read data

• Non-monotonic coordinate value or bounds
• Units attribute does not correspond to the actual data (e.g. data in degrees Celsius but units say Kelvin, data is a fraction but units say percentage)
• Data uses a different _FillValue/missing_value than declared in the attribute

Can be checked for collections of files

Can be checked without accessing data

• Different calendar attribute on the time coordinate of files from the same dataset
• Differences in long_name for horizontal index coordinates for 2D grids within the same dataset

Need to read data

• Slightly different coordinate and bounds values within the same dataset

[climate-dude]

Here are a few additional checks that come easily to mind.

Can be checked per file

Need to read data

• For many variables in units of %, like sftlf and clt, some use 0–100 and others use 0.0–1.0
• Coordinates should be contained within the spatial bounds
• Time values should be contained within the time bounds

[rswamina]

Not sure if this is QA/QC as such but ensuring areacella and areacello files are in place is one thing to check.

[lewisjared]

@taylor13 @matthew-mizielinski For CMIP6 datasets we read the long_name from the variable in and track it in a database. What goes in this database is MIP-era dependent so can (and will) change with CMIP7. The REF database assumes that the long_name may not be present (

climate-ref/packages/climate-ref/src/climate_ref/models/dataset.py

Line 121 in 01eabb5

long_name: Mapped[str] = mapped_column(nullable=True)

).

long_name is not directly used for filtering (or validated), but the values are made available via the API when describing the datasets used for a given analysis. Conceptually the term long_name is used extensively for figure legends/titles within the REF (https://github.com/search?q=repo%3AClimate-REF%2Fclimate-ref%20long_name&type=code) with our intermediate data products including long_names.

ESMValTool uses long_name for figure legend generation (e.g.

climate-ref/packages/climate-ref-esmvaltool/src/climate_ref_esmvaltool/diagnostics/example.py

Line 61 in 01eabb5

variable["caption"] = "Annual global mean {long_name} according to {dataset}."

). If a long_name is missing the default from the CMOR tables is used. The REF doesn't make this assumption, but would have to if we wanted to use the values in figures in the portal.

PMP doesn't use long_name and I saw a diagnostic in ILAMB assumes that it is present.
I imagine that there are also other places where the long_name attribute is assumed to exist (https://github.com/rubisco-sfa/ilamb3/blob/63f5d4e23378a9278d9da47552ec517e013769a7/ilamb3/analysis/hydro.py#L375 would break if long_name wasn't present).

If long_name is no longer mandatory, it would still be useful to have a community maintained mapping between standard_name and long_name (currently the CMOR table) for easy interpretation.

[bouweandela]

@glevava I've updated the text above to include more examples. Please let me know if there is anything more I can do to help clarify.

[glevava]

Thanks @lewisjared for the concrete and helpful examples. It is important to distinguish between ensuring that a long_name attribute is present and enforcing a specific value for it in NetCDF files. The presence of long_name itself is not under question, it will remain mandatory and will continue to be checked through QA/QC.

What is currently under discussion at the WIP level is whether the value of long_name should be standardized via the controlled vocabulary.

It is therefore possible that the REF and other downstream tools may need to revisit their assumption that long_name is standardized across all models.

[taylor13]

@lewisjared Jared, thanks for explaining so completely and clearly what you know about the REF's possible need for long_name. Your input was very helpful to me at least in understanding software "dependencies".

I think the REF would be wise to consider extracting long_names for a given branded variable from a source other than the model output files (if you want the same name to always be returned) Currently, the recommended long_names are listed in the "Title" column of the data request airTable v1.2.2.3: https://airtable.com/app2jDtttIhxC5fx7/shrAlTC2M6rDigwAr/tblpo5L8maBIGlM1B/viwNNzrqK5oPL7zk2 . You could access that to retrieve the long_name (or you could transfer those to your own lookup table).

Hope this advice is sensible and helpful.