Data Request Physical Parameters - Labelling choices and options

[CMIP-Data-Request-coleads]

Themes:

• Ocean & Sea-Ice

Description

There are many variables for which choices are specified: output A or B depending on model physics/configuration. There are also variables which should only be produced under certain conditions. Such options and choices should be made more visible. Some of them are listed in this query,

[martinjuckes]

From an email chain.

From Martin

There have been a couple of questions about how we handle conditional elements of the request. One from Marie-Pierre a week or two back and more recently from Anne-Marie.

There were 25 variables in the CMIP6 data request which had a conditional element: 4 associated with different numbers of pressure levels. 21 associated with choices depending on model configuration/physics.

These are listed in https://clipc-services.ceda.ac.uk/dreq/index/varChoiceLinkR.html and https://clipc-services.ceda.ac.uk/dreq/index/varChoiceLinkC.html. Many of these conditions are inherited from the CMIP5 Standard Output workbook, where they were referred to in the "comment" text for each variable.

The table in the baseline variables paper contains, I hope, information which is consistent with the CMIP6 request.

We took the explicit references to these conditions out of the CMIP7 database structure because we felt that it added too much complexity. The CMIP6 approach included extra tables to describe the choices. The advantage of this approach is that you can easily link to the tables (links above) to see a full list, but the attempt to make the whole process machine operable made it too complicated.

I can see 3 options: Return to the CMIP5 approach and describe these options in the existing "Processing Notes" column. Add an extra column for this information, as Eleanor suggests. Add two extra columns: one for the explanation and a 2nd to link to related variables.

2 & 3 involve modifications to the database schema but would still be significantly simpler than what was done in CMIP6. 1 & 2 would refer to related variables by name in the text. This carries the risk of becoming ambiguous if variable names are revised. Option 3 provides a more robust link to related variables as well as the convenience of a link to follow to the related variables in the web interface.

Chloe

So thinking through these options, I'd like to suggest an additional potential option that hopefully sits somewhere in the middle:

We add a Boolean column called 'conditional', and then put the condition description into the 'processing note' (clearly indicated as 'Condition: ..." I don't know if full variable linking (option 3) is necessary, and there is a reason it was pulled in the move to airtable. This 'conditional' column would make it easy for people to see whether there is a condition to check on, and allows for filtering for conditional variables collectively, but is less onerous and confusing than 2 whole extra columns.

Martin

That sounds good, especially the idea of making the additional column a simple yes/no switch.

[martinjuckes]

I've added a "Conditional" column to the physical parameters table, and added entries for bigthetao (and variants) , msfty (and variants), hfgeo, hfgeobed, thkcello, masscello, volcello, areacello.

There are many more to add which are referred to in the links above and in processing notes.

Notes for thkcello, volcello, masscello need additional text from BCV paper.

Some choices are more to do with the vertical coordinate, e.g. two choices with different numbers of levels. These would have to be entered in a different table.