`modeling_realm` not defined in CORDEX data request

[larsbuntemeyer]

The original CORDEX data request does not define the modeling_realm. I am not sure how to derive that or which realms are allowed in CORDEX. Simple example: orog has modeling_realm = land in CMIP6_fx.json, tas is typically atmos, but that column is missing.

[wachsylon]

I think, right now only the atmos variable list exist, right? So there will be several lists for several realms.

[larsbuntemeyer]

Honestly, i am not sure what that attribute really describes, i just see, e.g., in CMIP6 variables like mrsos have modeling_realm land. And for the TIER1 list, it is not clear, if we use the same attribute also for CORDEX. So, also for the sake of completeness, I would prefer to have an explicit column for modeling_realm also in the CORDEX data request. what do you think @gnikulin ? Or can we simply skip that attribute? I am not sure, if CMOR3 checks for that attribute...

[gnikulin]

We traditionally consider output from atmosphere-land RCMs as atmospheric variables even if many of them belong to land. The CORDEX-CMIP5 CMOR tables has no relams, only frequencies https://github.com/PCMDI/cordex-cmor-tables/tree/master/Tables and now we need to introduce realms in CORDEX-CMIP6. The simplest way here is to follow CMIP6, the same realms for respective variables as in CMIP6. Regarding the CORDEX-CMIP6 CMOR tables we can add the realms:

• atmos – Aday, Amon, Asubday {1hr, 3hr, 6hr}
• land – Lday, Lmon, Lsubday
• seaIce – SImon (currently only siconca)
• aerosol – AERmon (currently only od550aer)

Later we can expand these tables by adding new variables from coupled RCMs.

[larsbuntemeyer]

Here is a notebook on the modeling_realm discussion: https://nbviewer.org/github/WCRP-CORDEX/cordex-cmip6-data-request/blob/main/cmip6_duplicated_out_name_freq.ipynb

[larsbuntemeyer]

I think the tables (in CMIP6) are also sometimes distinguished by other factors than only frequency and modeling_realm but also, e.g., different dimensions (vertical coordinates) for different activities, additional aggreations (zonal means) or physics reason (cloud forcing) etc.. I guess they grew with time... For CORDEX, i think splitting the tables into frequencies might be enough, we can still keep the modeling_realm as an attribute anyway. There can also be different modeling_realms in the same table anway and didnt see a case yet where this should lead to duplicated variable keys...

[larsbuntemeyer]

maybe just skip the modeling_realm?

[gnikulin]

after all discussions, the simplest is perhaps to completely skip modeling_realm in CORDEX-CMIP6