search

WCRP-CORDEX / cordex-cmip6-cmor-tables

JSON Tables for CMOR3 to create CORDEX-CMIP6 datasets
https://wcrp-cordex.github.io/cordex-cmip6-cmor-tables
BSD 3-Clause "New" or "Revised" License
1 stars 1 forks source link

choose version of CF conventions #72

Closed larsbuntemeyer closed 3 months ago

larsbuntemeyer commented 4 months ago

which version of the CF conventions do we want? The latest is CF-1.11?

There are some differences, e.g., see https://github.com/PCMDI/cmor/issues/729

gnikulin commented 4 months ago

The first idea, several years ago, was to use the same CF conventions as in CMIP6 (1.7) and of course using CF 1.7 in 2024 perhaps not so good idea any more. I would use the latest CF 1.11 if that doesn't create any critical problems for example with CMOR, although not all CORDEX modelling groups use CMOR.

gnikulin commented 3 months ago

Another question is how to check that data is consistent to CF-1.11? As I see the latest CF version implemented in the CF checker is 1.8 https://cfchecker.ncas.ac.uk

larsbuntemeyer commented 3 months ago

Ok, actually, i think there is no big differences concerning us except those about the boundary variable attributes. However, with latest CF-1.11 that should be fine. Maybe we should say something like CF>=1.7 since the conventions are probably compatible. I think https://github.com/WCRP-CORDEX/data-request-table/issues/17 is more urgent since that would really violate CF conventions...

gnikulin commented 3 months ago

CF-1.10 was used in the SOD and can be changed to CF-1.11 in the final CORDEX-CMIP6 archiving specs. I would try to avoid using a wide range of the CF conventions as e.g. CF>=1.7 and simply take the latest one.

larsbarring commented 3 months ago

Copied from an archive specs comment:

Require CF-1.11 instead? This would be relevant IF either of these applies:

In addition, the new concept of units_metadata might be relevant for temperature variables when considering how they might be used used to produce downstream derived statistics, see CF-1.11 Sect 3.1.2. However, some some further details in the convention text still need to be implemented, and the same goes for some boilerplate text in the standard name table.

larsbuntemeyer commented 3 months ago

@larsbarring Thanks for clarifications here!

larsbuntemeyer commented 3 months ago

Note, that right now we don't really have a tool that can check for CF > 1.8 (cfchecker will raise an error if CF > 1.8, compliance-checker throws a warning.)

larsbarring commented 3 months ago

This shortcoming has been noted, but to my knowledge there is no timeline for updating the tool to cover more recent versions.

gnikulin commented 3 months ago

Now we use CF-1.11 in the final version.

larsbuntemeyer commented 3 months ago

Ok, agreed. I'll update the CI, try to ignore the cfchecker error it will throw...

larsbuntemeyer commented 3 months ago

The CI now ignores the CF conventions error for CV > 1.8... I will probably also add a check using the compliance-checker as seen in the examples notebook...

larsbarring commented 3 months ago

@larsbuntemeyer: Sorry for jumping after this issue was closed, but I would be interested to see what particular elements of CF > 1.8 that CORDEX are using.

larsbuntemeyer commented 3 months ago

@larsbarring no worries, in CORDEX, we are probably mostly concerned about the recommendations with respect to boundary variables of auxilliary coordinates as described in this comment: https://github.com/PCMDI/cmor/issues/729#issuecomment-1953881259

However, there was probably a mismatch between what the cmor API allowed and what was recommended about boundary variable attributes before CF-1.11... However, this is all only about recommendations...