Conversation
|
@pierrenabat i added a table in this PR basically containing all requested aerosol variables and some meta data derived from the information provided. I kept the "ag" column for now to check cell methods. The default for cell methods is (all frequencies aver averaged values)
in case of "i" in the aggregation column, for subdaily frequencies it's
However, i'm unsure how to handle the "c" (cumulative). Should the subdaily cell method be something like "area: mean time: sum"? I could't find anythin im CMIP6 to hang on, e.g., no cumulative subdaily frequncies. |
|
@jesusff for aerosols, i now see in the comments a lot of pressure levels requested for aerosol variables, e.g.,
The default data request splits pressure levels in individual datasets with scalar coordinates. Should we stick with one approach or have both? I'm unsure... |
|
@larsbuntemeyer thanks for creating the table. |
It should be possible, however, not consistent with the default data request. I think we need more opinions on this. |
|
I've added a separate discussion on the model levels issue in #76 For the moment, I'd leave this aerosol request as is now, with 3D variables including the vertical dimension. @pierrenabat, how standard is the set of levels you propose here? |
|
Ok, we can keep 3D variables and i will add a coordinate. However, we still have to decide about the invalud standard names, see #34 (comment) That is about half the variables that have invalid standard names, should we remove them for now? |
Update aerosol standard_names for CF compliance
Update aerosol data request
Update datasets.csv with aerosol variables
|
The new aerosol variable entires have no realm yet, should they go under atmos? |
|
Thanks for the merge @larsbuntemeyer |
|
Hi, yes, I would not mix it with the atmos "realm" (or "component", as we called it in #68). We still need to decide on how to proceed with the organization of the data request. Not in the derived content (datasets.csv and CMOR tables), but in the "user files". In #68 there is a proposal to have a data request per domain (or activity in general, e.g. there could be a data request for CORDEX-CORE or for some FPS) and have the component/realm as an additional column to indicate the the data is requested only in case the model has this component (aerosol chemistry, in this case) |
|
Agreed, it doesn't make much sense to have data requested by compents etc, but rather by domain or/and activity. I will go on with this PR and merge the aerosol component variables with realm aerosol in the cmor/datasets table. We can then let it the communities decide which subset to choose for their activties. |
see #34
The initial aerosol table created using: