order in required_global_attributes matters

[larsbuntemeyer]

Just wanted to dump this here, since we now have fixed our required global attributes for CORDEX. I'm not sure if it's by intention, but it seems like the order of variables in the required_global_attributes tables seems to matter when they are evaluated during cmorization. This is probably related to #628. For example, if if have...

{
    "CV": {
        "required_global_attributes": [
            "domain_id",
            "domain",
        ],
        "domain_id": {
            "EUR-50": {
                "domain": "Europe",
                "domain_id": "EUR-50"
            }
        }
    }
}

... and my input dataset file contains domain_id: "EUR-50", cmor will correctly and automatically add the global attributes domain: "Europe" to the file. However, this wil not work if the domain attribute comes before the domain_id attribute in the list of required_global_attributes, e.g., this will not work...

"required_global_attributes": [
       "domain",
       "domain_id",
],

This is somehow confusing and it's not the case for attributes like, e.g., source_id and source....

[larsbuntemeyer]

Sorry, I'll try to provide a minmal example, but, e.g., see here...

[durack1]

@larsbuntemeyer it's not obvious what is required here - if you can provide an example, or even better a PR to correct logic, then that would be ideal and can get merged in for a future release (3.11 would be a target, 3.10 we hope to have out soon)

[durack1]

@larsbuntemeyer just circling on a couple of these open issues. CMOR 3.9.0 expects a project_CV.json file that contains a simple dictionary of valid terms, themselves either a simple list or a "flat" dictionary with keys and single values. The software then checks for matches (or regex matches) before continuing. In CMIP6, there were two exceptions, experiment_id and source_id, both of which are more complex python dictionaries, as they contain embedded information (see cmip6-cmor-tables/Tables/CMIP6_CV.json).

For CMOR 3.10, this has been augmented so that license_id is also now a more complex entry, which includes a string identifier, URL, etc, the remainder continue to be the "simple" types.

This issue is now stale, so I will close for now - if you want to provide more concrete guidance as to what your asking for here, feel free to reopen