Med-CORDEX data request with merged components

[jesusff]

This is an attempt to create the data request for Med-CORDEX using a single file. The idea is to simplify the request for users: if you want to contribute to Med-CORDEX, the data request is in dreq_MED.csv, instead of cherry-picking dreq_default.csv, dreq_ocean.csv, dreq_aerosol.csv, ...

In the new file data-request/dreq_MED.csv there is an additional column component, with values atmosphere, ocean, ... and, in general, the components defined by the Essential Model Documentation (EMD, Section 7.1). The component takes precedence over the priority. For example, if your model does not have an ocean component, you don't need to provide so (Sea Water Salinity), even if it is a CORE variable:

data-request-table/data-request/dreq_MED.csv

Line 550 in d58751f

so,mon,0.001,Sea Water Salinity,sea_water_salinity,area: mean where sea time: mean,CORE,"3D, practical salinity",ocean

It is a CORE variable for the ocean component. That is, for all models which include this component. Note that nor the priority, nor the component, go to the main data request file from which the CMOR tables are created.

PROS:

• Single data request for each domain. No cherry-picking data requests.
• Flexibility for each regional community to have their own variables and priorities (as is the case with the atmospheric/default variables)

CONS:

• Some of the existing variables in the default data request already belong to different model components (e.g. land_surface) and are at the moment assigned to atmosphere
• Some of the data requests in Med-CORDEX (e.g. river) are not currently considered model components in EMD.

[jesusff]

The script creating the xlsx version of the data request ignores the component

[LluisFB]

I am wondering about the variables that are transferred between components (e.g. evaporated water from the sea, fresh water from rivers into the sea, heat, ...) is there a clear protocol to define the sign of the flux/transfer?
Also, when models will gain complexity and become more ESM, could it happen that the same variable can have different values depending on the component from which it gets its values (not only the sign)?

[larsbuntemeyer]

is there a clear protocol to define the sign of the flux/transfer?

That should be covered by the variables attribute positive which can take values up/down to indicate the direction of unsigned/signed values (most often also the long_name attributes indicates it by using something like upward/downward wording etc..)

the same variable can have different values depending on the component

I think the understanding today was that we do not cover this in CORDEX-CMIP6 because the DRS does not allow to distinguish this...

[LluisFB]

I understand attribute positive, but my question was regarding if there is a protocol to decide which is the main climate component to which the variable has to be associated with and therefore, decide the sign of the positiveattribute.

But, yes, this is beyond CMIP6. Let's stick to that by now.

I would just kept down-written the discussion (in case to follow the thread for CMIP7 and kept it mind) about the difference between prescribed/active, what really means ts or differences tsk, the possibility for example for atmospheric sea ice vs oceanic sea ice ,...