Core variables beyond the DECK experiments: ScenarioMIP

[matthew-mizielinski]

While there is a core set of variables in the DECK + historical experiments, the same does not appear to be true for the scenarios. For example Amon/tas appears to only be requested from the ScenarioMIP ssp245 experiment by Dynvar, LUMIP and VIACSAB. We may not respond to requests from these MIPs from all of our model configurations by default, which could lead to situations where we would not submit such a basic variable.

Should the core set of variables used in the DECK + hist experiments be extended to all ScenarioMIP experiments, or does a new subset of these need to be defined?

I note that Amon/tas does appear to be requested from ScenarioMIP experiments according to the spreadsheets, but I'm assuming that this is part of the issue addressed in #56 and we are not using the spreadsheets as our primary source of information.

[matthew-mizielinski]

A scan through the ScenarioMIP GMD paper finds the quote below

Page 3477 final paragraph;

ScenarioMIP has not defined a separate data request for CMIP6, but rather recommends that variables that are re- quested for the DECK and the CMIP6 historical simulations are also stored for the future climate model simulations. This includes climate model output of interest to the IAM and IAV communities as identified by the CMIP6 VIACS advisory board, see the contribution on the CMIP6 data request to this Special Issue for further details.

(IAM = "Integrated Assessment Models", IAV="Impacts, Adaptation and Vulnerability")

My first thought is that extending the core list to ScenarioMIP should be sufficient to cover this.

[durack1]

@matthew-mizielinski @martinjuckes @taylor13 @markelkington @balaji-gfdl I agree with the suggestion above that the DECK request is duplicated for all ScenarioMIP simulations

[martinjuckes]

Probably there should be. We could perhaps use the VIACSAB ScenarioMIP request, which is fewer variables than the CMIP DECK request, reflecting, I think, the different purpose of these experiments. The VIACSAB request does, however, omit fixed variables, so we need to add those. I'll do some further analysis tomorrow and then bring Karl into the conversation.

[matthew-mizielinski]

Given the importance of the scenarios, and the quote from the GMD paper above, I would argue that this is not the place to skimp or cut back on variables. I know this is going to be a large addition to the total volumes (something in the range of 30-40Tb on top of the volumes listed here), but I'd be happier starting off with adding everything and then looking at the high cost areas, e.g. high frequency/model level data, for "efficiency" savings rather than have several changes to the request to consider as we approach what ScenarioMIP actually want.

On this last point is there anyone from ScenarioMIP we can bring into this discussion as a technical representative?.

[taylor13]

I'm not going to have time to review the ScenarioMIP data request, so hopefully someone from ScenarioMIP will engage. If not, let me know, and I'll write the CMIP panel to try to get some feedback.

[durack1]

I agree with @matthew-mizielinski, the ScenarioMIP data request should align tightly with the DECK (particularly historical) data request, as often these projections are "spliced" onto the historical simulation time histories providing an ~1850-2100 time history for analysis. It would be unfortunate if for key variables this historical-future matching wasn't possible due to a limited data request for the latter