Merge aerosol data request in main data request

[pierrenabat]

No description provided.

[larsbuntemeyer]

Thanks @pierrenabat AFAIK, the aersol are parte of the MED-CORDEX data request #68 and should not go into the default one, right? I think, at this point, we can't make aerosol variables part of the default data request (at least, not with CORE priority)...?

[pierrenabat]

Aerosols are not only in the MED-CORDEX data request, at CNRM we have CORDEX simulations with aerosols also for EURO-CORDEX and CORDEX-CAM, so they should not be attached to a specific domain, and I thought we would put all variables in the general data request, and models produce what they can depending on their components and the associated realms of each variable. But maybe I did not understand well our discussion yesterday ?
I think that the level of priority should be defined for each realm. For models with aerosol, ocean or river output, they should be able to have different priorities for these different realms.

[jesusff]

yes, priority comes after this realm/component, so even if we place the aerosol request in the default, modelling groups should not worry about it if they do not have an interactive aerosol component.

Anyway, I understand your concern Lars, since people filtering the default data request by the Core variables will see a wealth of new variables requested. We could aim at having first a nicely formatted version of the DReq for MED, where they know what all this is about. In EUR and CAM, I think the only group running with interactive aerosols is CNRM, so you are aware of this. We can then spread the word and add other components to the default. What do you think?

[larsbuntemeyer]

We could aim at having first a nicely formatted version of the DReq for MED, where they know what all this is about. In EUR and CAM, I think the only group running with interactive aerosols is CNRM, so you are aware of this. We can then spread the word and add other components to the default. What do you think?

Yes, i agree! I thought of this default one always as being the one we published on zenodo and it should be consistent (For example, priority of od550aer monthly was raised from TIER1 to CORE priority). Also the published one explicitly mentions an atmospheric data request. However, many groups also already have finished the cmorization process and archived model data and they might argue that they could have delivered those new CORE variables if requested earlier. I create a tag last week that should be consisten with the current CMOR table release. I will link that one to the zenodo table. Then we can also make new releases...