CORDEX-CMIP6 cmor tables

[larsbuntemeyer]

Hey everybody,
i have some issues since i am working on CMOR tables for downscaling of CMIP6 datasets. I try to understand some of the attribute dependencies and i have some preliminary tables here and a rendered example. For theses tests i have basically adapted the CMIP6_CV table and modified them. This all works fine, however, in CORDEX we don't require any parent_* or sub_* attributes and i tried to remove them completely from the CV and the dataset table. But somehow i can't get it to work, since i always get something like:

!!!!!!!!!!!!!!!!!!!!!!!!!
!
! Error: Your "sub_experiment_id" key could not be found in
! your Control Vocabulary file.
! 
!
!!!!!!!!!!!!!!!!!!!!!!!!!

So the cmorizer looks for that attribute although it is not defined or required either in the dataset table nor in the CV table. Is there some special attributes for CMOR3 that are required? I suspect so when i have a look at the source code, e.g., here

cmor/Src/cmor_CV.c

Line 821 in c805fe0

int cmor_CV_checkSubExpID(cmor_CV_def_t * CV)

it seems like this is somehow hardcoded and required?

At the same time, i wonder how this works, e.g., with the input4MIps or obs4MIPs tables since they don't define, e.g., the sub_experiment attributes...

Maybe i get something totally wrong, i am not sure...

[larsbuntemeyer]

Ok, i now see that this behaviour is activated by the presence of the _cmip6_option keyword in the dataset table... So i guess this should be absent if one wants to define an arbitrary CV?

[larsbuntemeyer]

Just one hint for myself here:

If i have derived attributes in the CV, e.g., source depends on source_id, i have to specify both in the input datasets table (because i want both required), however, conflicting values of derived attributes are overwritten silently now. Could there be a warning if derived attributes are overwritten?

Is it correct that i have to specifiy derived required attributes in the dataset table (although theoretically they could be added automatically since they are overwritten anyway...)?

[durack1]

@larsbuntemeyer you're almost there, if you wanted to see some of the CMOR_input_example.json inputs for the input4MIPs project, take a peek at PCMDI/amipbcs/CMOR/drive_input4MIPs_obs.json.

As you noted this does NOT include the _cmip6_option and thanks to the recent CMOR 3.7.0 release, depends on most of the inputs from the registered content (in the input4MIPs case information found in the https://github.com/PCMDI/input4MIPs-cmor-tables (and specifically the info found in the PCMDI/input4MIPs-cmor-tables/Tables/input4MIPs_CV.json) file

[larsbuntemeyer]

Thanks @durack1 for that swift reply! I appreciate it! I guess, there is no way to configure PrePARE to run with arbitrary CV, is there? For example, could you run PrePARE on input4MIPs datasets?

[larsbuntemeyer]

@larsbuntemeyer you're almost there, if you wanted to see some of the CMOR_input_example.json inputs for the input4MIPs project, take a peek at PCMDI/amipbcs/CMOR/drive_input4MIPs_obs.json.

As you noted this does NOT include the _cmip6_option and thanks to the recent CMOR 3.7.0 release, depends on most of the inputs from the registered content (in the input4MIPs case information found in the https://github.com/PCMDI/input4MIPs-cmor-tables (and specifically the info found in the PCMDI/input4MIPs-cmor-tables/Tables/input4MIPs_CV.json) file

Yes, i updated to the latest version, now this makes the input file really slim and convenient, very nice!!

[durack1]

@larsbuntemeyer it makes sense to me that we migrate this "issue" into a "discussion" as there is no obvious issue or bug that this thread identifies, rather it's about CMOR usage (and potential expansion/features)

[larsbuntemeyer]

I agree!