Proposed CMIP5-era experiment_ids for CMIP and ScenarioMIP

[durack1]

From: Taylor, Karl E.
Date: Tuesday, October 8, 2019 at 1:29 PM
To: Brian ONeill, wgcm-wip, claudia tebaldi, detlef.vanvuuren,
Jean-Francois Lamarque, veronika.eyring, Jerry Meehl, Ron Stouffer,
Cath Senior, Greg Flato
Subject: Re: WIP telco in 18 hours

Hi All,

In additional to their ScenarioMIP runs, CCCma is carrying out some RCP scenario runs
(with CMIP5 forcing) with one of their CMIP6 CanESM models.  These simulations are
not called for in CMIP6, but can provide perspective on differences between CMIP5
and CMIP6 (forcing the same model withCMIP5 and CMIP6 future forcing).  The IPCC
will likely be interested.

I think we should enable CCCma (and anyone else) to include CMIP5 RCP future
scenario runs in the CMIP6 archive (to be run with a model that also performs the
CMIP6 DECK, historical, and at least some of the ScenarioMIP simulations).  To do
this within the CMIP6 organizational framework and software infrastructure, one
option would be to ask ScenarioMIP to "sponsor" these experiments (at tier2 or
tier3 priority), and to come up with names for these experiments (or simply adopt
the names from CMIP5:  rcp26, rcp45, rcp85, rcp60)   

What do the ScenarioMIP leaders think of this idea?

A related question concerns performing *historical* simulations with both CMIP5
forcing and CMIP6 forcing to understand how different the responses are to these
different forcing estimates.  There are a couple of options:

1) Define a new experiment name (e.g., Paul has suggested "historical-cmip5"),
and this could be considered a tier3 experiment under the "CMIP" activity, under
the responsibility of the CMIP Panel)

2) Permit publication of a CMIP5-forced historical runs under the name "historical"
and distinguish them from CMIP6-forced runs using a different "forcing_index". 
In CMIP, the forcing_index is assigned an integer value (usually, but not always,
set to "1" for "standard forcing") and is generally used to distinguish similar runs,
but with different forcing estimates (e.g., two historical runs run with different
prescribed ozone, or two historical runs with different estimates of biomass
burning aerosol precursors).  

The second option would not require any special action on our part; the first
option would require registration of 4 new experiments but would make it
absolutely clear that these runs were performed with forcing different from
the standard CMIP6 forcing (for those who can't be bothered with the definition
of "forcing_index"). 

Thoughts?

best regards,
Karl

[taylor13]

from Claudia T.:

We have a section in the paper that talks about "relation to CMIP5" and we describe
this turn of events (modeling groups running CMIP5 experiments with the new
models) as a desired effort to allow a better evaluation of the differences. So I think
from the scientific point of view this would be a no brainer. In terms of the practical
steps involved though we would need to understand what exactly is required, we
are all up to our necks in work and IPCC commitments and if a lot of overhead in
dealing with paper additions, data requests, forcings publications and pointers are
required on a strict timeline I see that as a problem at this moment. 

[claudiatebaldi]

I also would want to make sure that users are clear about the experiments purpose. A lot of people outside of the climate modeling community are downloading this data, possibly without a full understanding of the new framework, how the SSP-driven scenarios differ from the older RCPs... I would be concerned that while exploring the data available on the ESGF and seeing the name RCP* they would go for those with no understanding of what they are downloading...so the naming in my view is a non-straightforward issue.

[durack1]

@claudiatebaldi good point. I had a quick think about the historical CMIP5 forcing equivalent and this could be called historical-cmip5 to make that point clear. For the RCPs, you could equivalently have rcp26-cmip5 etc which makes it a little hard to ignore the *cmip5 part of the experiment name.

To be honest it also provides a motivation to get the CMIP5 forcings into input4MIPs, which was on the to-do list at some stage

[durack1]

@veyring @rjstouffer ping

[slavakharin]

My vote would also be in favour of historical-cmip5, rcp26-cmip5, rcp45-cmip5, etc., may be piControl-cmip5 as well, for completeness.

[matthew-mizielinski]

+1 for the definition of new experiments, rather than use of the forcing index -- I think allowing the "special" use of certain f indices will lead to confusion and incorrect use of data. Documenting exactly what has been done in these additional "ensemble members" will also be difficult to communicate to the users (would require integration of the ES-Doc conformance documentation with other systems).

[MartinaSt]

+1 for the experiment solution. In the IPCC AR5 Reference Data Archive as well as the CMIP6 Citation the ensemble members "subgranular" and thus hidden. Thus the new experiment is more transparent for the citation and the IPCC DDC use cases as well.

[durack1]

@martinjuckes what will be required to augment the data request to deal with the 6 new proposed experiments:

Sponsoring MIP	experiment_id	tier	GMD article requiring update
CMIP	historical-cmip5	2	Eyring et al. (2016)
CMIP	piControl-cmip5	2	Eyring et al. (2016)
ScenarioMIP	rcp26-cmip5	3	O'Neill et al. (2016)
ScenarioMIP	rcp45-cmip5	3	O'Neill et al. (2016)
ScenarioMIP	rcp60-cmip5	3	O'Neill et al. (2016)
ScenarioMIP	rcp85-cmip5	3	O'Neill et al. (2016)

[durack1]

From Brian O and Cath S:

From: Brian O'Neill
Date: Wednesday, October 9, 2019 at 7:58 AM
To: Claudia Tebaldi, "Taylor, Karl E."
Cc: WIP List, detlef.vanvuuren, Jean-Francois Lamarque , veronika.eyring, Jerry Meehl,
Ron Stouffer, Cath Senior, Greg Flato
Subject: RE: WIP telco in 18 hours

Hi all,
I agree with Claudia’s and Cath’s responses (pasted together below to keep everything
on one email thread). During the development of the ScenarioMIP design this was
definitely considered valuable, but just a step too far in what we could really ask
modeling centers to do. So it would be entirely consistent with ScenarioMIP to somehow
“sponsor” such runs as Karl has suggested (and I would think tier 3 would be appropriate,
so that it didn’t compete with other experiments already identified as tier 2). However as
Claudia indicated, if there is a lot of detailed work to be done to set up forcing files,
document them, provide protocols, etc., I don’t see that happening anytime soon. If
CCCma is going through it anyway, can write it all down, and we simply point to it, that
might be an efficient way forward.

In terms of names my first reaction is that I like the idea of using the rcpX.X names, and
maybe even better appending “cmip5” to drive home the point that these are re-runs of
the CMIP5 versions of the rcps (eg, “rcp26-cmip5”). There is a lot of recent attention to
the plausibility of the RCPs, and not a lot of understanding of differences between CMIP5
RCPs and the new SSP-based CMIP6 simulations, so we’d need to really try not to
confuse things further.
I am not familiar with the use of the forcing index convention, so if that is a better
alternative that might be ok too.
Brian

From: Senior, Cath 
Sent: 09 October 2019 08:24
To: Taylor, Karl E.; Brian ONeill; WIP List; claudia tebaldi ; detlef.vanvuuren; Jean-Francois Lamarque;
veronika.eyring; Jerry Meehl; Ron Stouffer; Greg Flato
Subject: RE: WIP telco in 18 hours

Hi Karl

A quick reply from me – I am in Addis Ababa at a meeting this week

I am all for making this work in whatever is the most efficient way for all. It certainly
seems like a very valuable addition for CMIP6 analysis both for the scenarios and
the historical runs. At the Met Office we have used the forcing_index to indicate the
runs we had to repeat when we found issues with ozone representation in the idealised
experiments. I am not sure if this makes it more or less desirable to use it also for the
CMIP5/CMIP6 differences. Presumably we would need to agree a number for the
forcing_index across all models (e.g. lets pick ‘5’ for everyone if centres, like ours
have already used other numbers!)

[durack1]

From Detlef:

From: "Vuuren, van Detlef"
Date: Wednesday, October 9, 2019 at 1:07 PM
To: Brian O'Neill, Claudia Tebaldi, "Taylor, Karl E."
Cc: WIP List, Jean-Francois Lamarque, veronika.eyring, Jerry Meehl, Ron Stouffer,
Cath Senior, Greg Flato
Subject: RE: WIP telco in 18 hours

Dear all,

I think that these runs make a lot of sense…. in order to better understand the different
causes of the differences in climate response (and in fact we indeed discussed this at
the time in Aspen; also the alternative of running the new forcing files with the older
models).

Regarding the naming: In IPCC there was also some discussion how to best refer to the
scenarios. At the moment, they are using SSP2-4.5 names in all WGs, but in some WGs
the “SSP dimension” makes most sense; while in others the “RCP dimension”. Calling
scenarios SSP2-4.5 in WG1 can be confusing: it more-or-less speaks again the original
idea that people could probably use these climate runs also in combination with the
socio-economic variables of the other SSPs. This is obviously not coupled to the CMIP
naming, but I assume that there will be different names at some point in IPCC as well.

Detlef

[durack1]

@charliepascoe @eguil @bnlawrence @martinjuckes ping

[taylor13]

Hi all,

It appears that for the historical and piControl runs with CMIP5 forcing, the consensus is that option 2 would be better:

• The CMIP panel will be responsible for two new Tier 2 (or 3?) experiments named "piControl-cmip5" and "historical-cmip5"
• These experiments are defined by the CMIP5 protocol, but run with a model that will also be contribute output from the CMIP6 DECK and historical runs.
• The historical-cmip5 simulation would be expected to cover the period for which CMIP5 forcing is available (1850 though 2005).
• The output requested from these runs should be the same as for the CMIP6 historical simulations.

For the CMIP5 era future runs, these also will be "new" experiments for CMIP6:

• The ScenarioMIP leaders will be responsible for four new tier-3 experiments named rcp26-cmip5, rcp45-cmip5, rcp60-cmip5, and rcp85-cmip5.
• These experiments will adopt the same protocol as the CMIP5 rcp26, rcp45, rcp60, and rcp85 experiments but run with CMIP6 models.
• The output requested from these runs should be the same as for the CMIP6 ssp126, ssp245, ssp370, and ssp585 simulations.
• These experiments should be spawned from the end of the historical-cmip5 experiment; this will avoid large discontinuities in forcing in transitioning from the "past" to the "future".

If there is agreement on the above, then

1. Paul will begin the registration process by creating entries for these new experiments in the CVs located at https://github.com/WCRP-CMIP/CMIP6_CVs/blob/master/CMIP6_experiment_id.json
2. The CMIP panel will review the "piControl-cmip5" and "historical-cmip5" entries and make any corrections needed.
3. The scenarioMIP leaders will review the "rcpXXX-cmip5" entries and make any corrections needed.

Once the new CMIP6 experiments have been added to the experiment CV (https://github.com/WCRP-CMIP/CMIP6_CVs/blob/master/CMIP6_experiment_id.json), that information will propagate to other parts of the CMIP6 infrastructure (notably CMOR3, ESGF, the citation services, and ES-DOC). This will replace the current (39th!) CV version with a new version: 6.2.40.0.

Paul's changes to the CV will be implemented through a github pull request. These will be visible and directly editable by the ScenarioMIP leads and CMIP panel. As an example, which captures the recent FAFMIP registration of 3 new experiments, see https://github.com/WCRP-CMIP/CMIP6_CVs/pull/804/files#diff-6642f67f4f38024deabaa41b20af5e65 .

thanks, Karl

[martinjuckes]

@taylor13 : that looks good. It will also propagate to the data request: I would like to make the next data request version 1.1 to signal some kind of finality with regard to CMIP6. The data request will also implement the links between the experiments and the requested data.

For ES-DOC there is a technical question about how historical-cmip5 etc should be represented in the system. These experiments are, of course, already documented for CMIP5, but I don't know whether it is better to just point to that documentation or create copies within the CMIP6 system. I've created an ES-DOC issue (#285) for discussion of the technical options .. I don't think this needs to delay the decision here.

[matthew-mizielinski]

For ES-DOC there is a technical question about how historical-cmip5 etc should be represented in the system. These experiments are, of course, already documented for CMIP5, but I don't know whether it is better to just point to that documentation or create copies within the CMIP6 system. I've created an ES-DOC issue (#285) for discussion of the technical options .. I don't think this needs to delay the decision here.

I'd vote for new records / copies associated with historical-cmip5 , etc., within CMIP6 if possible, particularly as I cannot find the historical experiment for CMIP5 in the ES-Doc search page.

[claudiatebaldi]

Sounds good to me. We will send around an email "advertising" this additional experiments to the ScenarioMIP mailing list (unless my co-chairs want to do it differently).

Thank you and happy weekend to all.

Claudia

[taylor13]

It just occurred to me that we had already anticipated that something like this might happen: namely that we might want to host simultaneously CMIP experiments from different phases. For that purpose we defined the global attribute, mip_era, to "CMIP5". mip_era is defined in https://goo.gl/v1drZl):

to enable one to determine what cycle of CMIP dictates experiment and data specifications.  
This means that mip_era = “CMIP6” for all CMIP6 output no matter how old the model is 
that produced it.  Used in faceted searches.

I think we should make use of this attribute to clearly flag the CMIP5-era experiments being run for CMIP6. Specifically, we would retain the names piControl, historical, rcpcp26, rcp45, rcp60, and rcp85, but they would be CMIP5 era. There has been discussion of eventually merging the CMIP5 and CMIP6 data in ESGF, so output from both eras could be retrieved through a common search interface. The new runs expected from CCCma could serve as the first datasets to populate this trans-era CMIP data archive.

The main change to producing model output would be to correctly store "CMIP5", rather than "CMIP6" in mip_era. I suspect this change would, however, impact several pieces of software, including CMOR and PrePARE and probably ESGF, ES-DOC, and the citation services?

The CoG search interface would have to be modified to include "CMIP5" under the "MIP Era" facet to enable users to sub-select CMIP5 or CMIP6. We might set the default there to select only CMIP6 experiments, so users wouldn't inadvertently download historical runs with CMIP5 forcing. They would have to do something special before the CMIP5 runs would be visible. Will need to check on the details of this.

If others agree with the merits of this proposal, let's check what implications there are to the infrastructure.

Note that we would need to modify the description of mip_era to read

to enable one to determine what cycle of CMIP defined the experiment protocol and 
specified the forcing data.  The era of the model that performs the experiment does 
not determine the mip_era.   Used in faceted searches.

The global Conventions attribute includes the version of the CMIP output requirements that apply (e.g. "CMIP-6.2") and the data_specs_version global attribute indicates the version of the data request (e.g., "01.00.31")

[taylor13]

One further note. For CMIP6, the "era" is not part of the file name. To ensure uniqueness of filenames the historical (and piControl) runs subjected to both CMIP5 and CMIP6 forcing would still need to be distinguished using different "forcing" indexes. [We might want to make it really obvious that a different forcing is used by requiring for CMIP5 forcing an index in the range 500-599 (with 500 recommended)]. Note, that by storing CMIP5 under mip_era='CMIP5', there will be little chance that someone would by mistake get CMIP5-forced runs unintentionally, but if someone really wants these runs and downloads both the CMIP5-forced and CMIP6-forced runs of a model, we need to be able to distinguish them in the file names.

Looking ahead to future phases of CMIP, there is a proposal (see http://bit.ly/CMIPHarmony) to incorporate the mip_era into the file name. Then there would be no need to assign different forcing indexes to the historical (and piControl) subjected to both CMIP5 and CMIP6 forcing. Under the proposed file name template, two such output files might be named:

      ts_mon_atmos_CESM2_historical_r1i1p1f1_glb-2d-gn_CMIP5_196001-199912.nc
      ts_mon_atmos_CESM2_historical_r1i1p1f1_glb-2d-gn_CMIP6_196001-199912.nc

What can see immediately that the output in the first file was produced by CMIP5 forcing and in the second by CMIP6 forcing.

[jflamarque]

One thing I mentioned in an earlier email (maybe it was a separate threads) but seems to have been lost was the details of those CMIP5-CMIP6 runs. How are the emissions connected between historical and future, how is land-use harmonized, ...? I agree the idea sounds good, I am not sure I understand the details on how this will be done in such a way that it is useful. It seems to me premature to have a discussion on infrastructure/naming before we know if this is even doable. Unless I misunderstand what is being proposed and that groups are actually planning to do historical+RCP under the CMIP5 protocol. Don't they need to retune their PI?

[durack1]

@jflamarque as I was not privy to conversations about the mip_era = CMIP5 forcing datasets back in ~2010, I assume the datasets produced for the piControl/historical and those produced for the rcpXX experiments were harmonized?

If we use the complete CMIP5 forcing datasets (for piControl/historical and rcpXXs), then presumably there would be no harmonization issue, whereas this would occur if mip_era = CMIP6 historical forcings were used, and then the mip_era = CMIP5 rcpXX forcings were used from 2015 onward.

Note the suite of 6 new experiments requested are captured in the table up in https://github.com/WCRP-CMIP/CMIP6_CVs/issues/805#issuecomment-540135116

[taylor13]

I think the requirement is that if your piControl under CMIP5 forcing conditions is different from CMIP6, you must provide a new piControl-cmip5 run (or whatever we call it). Similarly, if you want to run rcp simulations, you must initialize them from a historical-cmip5 simulation (which usually will have been initiated from a piControl-cmip5 run.

I'm pretty sure that CCCma is planning (has done?) piControl-cmip5, historical-cmip5, and the rcp runs, so the potential problems you describe above are avoided.

@slavakharin ? let us know if this is incorrect.

[slavakharin]

Yes, we have done these experiments with CMIP5 forcing:

• piControl-cmip5 - 500 yrs
• historical-cmip5 - 1850-2005, 5 ensemble members
• rcp26-cmip5 - 2006-2100, 5 members
• rcp45-cmip5 - 2006-2100, 5 members
• rcp85-cmip5 - 2006-2100, 5 members

We didn't do rcp60 for CMIP5 so we didn't do it for CMIP6 as well.

The historical runs are initialized from the piControl-cmip5 run (50 years apart). The rcp runs are started from the end of the corresponding historical runs. This is the same setup we used for CMIP6 runs.

[slavakharin]

I am ok with labelling the CMIP5 runs with the original CMIP5 experiment names and using mip_era='CMIP5' as proposed by Karl. The requirement of using a different forcing index to make file names unique is not quite optimal but I think it's acceptable to use the forcing index in the range 500...599.

[jflamarque]

Great! Did you have to retune your model much?

Jean-François

---

Jean-François Lamarque Climate and Global Dynamics Laboratory Director National Center for Atmospheric Research P.O. Box 3000 Boulder, CO 80305 Tel: 303-4971495 https://staff.ucar.edu/users/lamar https://staff.ucar.edu/users/lamar

On Tue, Oct 15, 2019 at 1:45 PM slavakharin notifications@github.com wrote:

Yes, we have done these experiments with CMIP5 forcing:

• piControl-cmip5 - 500 yrs
• historical-cmip5 - 1850-2005, 5 ensemble members
• rcp26-cmip5 - 2006-2100, 5 members
• rcp45-cmip5 - 2006-2100, 5 members
• rcp85-cmip5 - 2006-2100, 5 members

We didn't do rcp60 for CMIP5 so we didn't do it for CMIP6 as well.

The historical runs are initialized from the piControl-cmip5 run (50 years apart). The rcp runs are started from the end of the corresponding historical runs. This is the same setup we used for CMIP6 runs.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/WCRP-CMIP/CMIP6_CVs/issues/805?email_source=notifications&email_token=AG52JX2DB3FOAV2FOTU62S3QOYMWXA5CNFSM4I6W27FKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBJ7VNI#issuecomment-542374581, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG52JX3ATLLIGYKAVKS4KBTQOYMWXANCNFSM4I6W27FA .

[slavakharin]

In addition to CMIP5 all-forcing historical runs, we would also like to submit CMIP5 single-forcing runs:

• hist-GHG - GHG-only
• hist-nat - natural-only (volcanic + solar)
• hist-aer - anthropogenic aerosols-only

My preference would be to use experiment_ids that are more aligned with CMIP6 names listed above. I believe the CMIP5 names were historicalGHG, historicalNAT, and historicalMisc. In particular, we would really like to avoid using historicalMisc since different forcing combinations were labelled by different "p" indices which caused no-end questions.

So if possible, could we also add 3 more experiment ids to CMIP5-era experiments?

[slavakharin]

@jflamarque No, we used exactly the same model settings, no retuning, except for changes in the forcings. Our piControl-cmip5 run is tiny bit warmer than CMIP6 piControl, mainly because we use zero volcanic forcing in CMIP5 in the pre-industrial era (I believe this was prescribed by the CMIP5 protocol) while there is some non-zero background volcanic aerosol levels in CMIP6. There are some differences in the historical period, mainly to the different volcanic forcing specification, as we far as we can see at the moment. There are some differences in RPCs, as compared to the corresponding SSPs but CO2 concentrations in are generally larger in SSPs as compared to RCPs by 2100.

[durack1]

@slavakharin for CMIP6 those experiments hist-GHG, hist-aer and hist-nat are sponsored by DAMIP. If we added these 3 additional experiments, we'd need Nathan (Gillett) to agree to add these to the DAMIP experiment suite (expanding from 13 to 16 experiments), so the proposal, adding these would now be:

Sponsoring MIP	experiment_id	tier	GMD article requiring update
CMIP	historical-cmip5	2	Eyring et al. (2016)
CMIP	piControl-cmip5	2	Eyring et al. (2016)
ScenarioMIP	rcp26-cmip5	3	O'Neill et al. (2016)
ScenarioMIP	rcp45-cmip5	3	O'Neill et al. (2016)
ScenarioMIP	rcp60-cmip5	3	O'Neill et al. (2016)
ScenarioMIP	rcp85-cmip5	3	O'Neill et al. (2016)
DAMIP	hist-GHG-cmip5	3	Gillett et al. (2016)
DAMIP	hist-aer-cmip5	3	Gillett et al. (2016)
DAMIP	hist-nat-cmip5	3	Gillett et al. (2016)

If these are all approved, the current 299 experiment count will increase to 308

[taylor13]

Just to reiterate: I don't like assigning these CMIP5-era experiments to the "CMIP6" cmip_era . If we assign cmip_era = "CMIP5" to these experiments, we can drop the "-cmip5" suffixes on the experiment names.

[durack1]

@taylor13 for the recent DAMIP experiments hist-GHG etc, these experiments did not exist in CMIP5, rather this was called historicalGHG, so we will need to define at least some new experiment_id entries. I think this is also true for the rcpXX-* for the reasons that @claudiatebaldi and Brian noted, that we want to make sure naive users don't go and grab an rcpXX experiment in preference of an sspXXX experiment without realizing what they are doing

[taylor13]

Sasha says there are ways we might configure the search interface to guard against users accidentally confusing CMIP5 experiments from CMIP6 experiments, even when both are done with the same model.

[slavakharin]

@taylor13 @durack1 As far as I understand, Karl's proposal is to have these CMIP5-era experiments:

Sponsoring MIP	cmip_era	experiment_id	forcing_index	tier	GMD article requiring update
CMIP	CMIP5	historical	500...599	2	Eyring et al. (2016)
CMIP	CMIP5	piControl	500...599	2	Eyring et al. (2016)
ScenarioMIP	CMIP5	rcp26	500...599	3	O'Neill et al. (2016)
ScenarioMIP	CMIP5	rcp45	500...599	3	O'Neill et al. (2016)
ScenarioMIP	CMIP5	rcp60	500...599	3	O'Neill et al. (2016)
ScenarioMIP	CMIP5	rcp85	500...599	3	O'Neill et al. (2016)
DAMIP	CMIP5	hist-GHG	500...599	3	Gillett et al. (2016)
DAMIP	CMIP5	hist-aer	500...599	3	Gillett et al. (2016)
DAMIP	CMIP5	hist-nat	500...599	3	Gillett et al. (2016)

The forcing_index is needed to distinguish file names between CMIP6- and CMIP5-era runs with the same experiment ids (e.g. historical, piControl). Also, the CMIP6-era experiment ids are used for DAMIP runs since they are more evocative than CMIP5-era names such as historicalMisc.

The ESGF search interface must be configured such to avoid downloading data from both eras, defaulting to CMIP6-era, and requiring some additional user action to download data for CMIP5-era.

Is this the proposal? I am ok with this.

[durack1]

@claudiatebaldi on behalf of the ScenarioMIP folks, are you ok with identical CMIP5 experiment names being used in CMIP6, but with the mip_era attribute pinned to CMIP5?

We had suggested appending a -cmip5 to these rcpXX experiment names to make it crystal clear, but the discussions above have diverged from this path

[durack1]

@taylor13, we may have to think about adding the activity_id = CMIP5 to the CVs, and then registering contributing models with an activity_participation update

[taylor13]

I need to check on how difficult it will be to modify CMOR to handle the proposed solutions. We also haven't heard. Also need to get confirmation from @martinjuckes @MartinaSt and especially someone from ES-DOCS on hard this will be to implement. Let's hold off on modifying the CVs.

[MartinaSt]

From the technical aspect of the citation this solution would require several little tweaks but is manageable.

What is not clear to me is: This data is pure CMIP5 data (incl. the forcings). Why shouldn't this CMIP5 data be published under the CMIP5 guidelines using CMIP5 DRS, CMIP5 CMOR tables etc.? Then the data would be searchable in the ESGF alongside the other CMIP5 data, which might be less confusing for data users.

A second thought: We provide additional services for CMIP6 like the citation or errata. We have not offered them for CMIP5. It is rather difficult to communicate why this late CMIP5 data is treated different from any other CMIP5 data.

[claudiatebaldi]

Hi Martina

for me "CMIP" refers to an intercomparison of models, and these experiments are run with the models participating in CMIP6, documenting themselves within the CMIP6 DECK, so I would not consider this CMIP5 data But CMIP6 data running CMIP5 experiments. But I'll let the real CMIP people speak.

[slavakharin]

@MartinaSt We are using the CMOR 3 software package to prepare netcdf output in our model, and I am not aware of an option in this package to produce CMIP5-compliant output.

[martinjuckes]

I don't think we would be able to publish this data as CMIP5 data. It is not only CMOR that has changed, the whole ESGF infrastructure has been adapted to deal with CMIP6 data. Publication of data using the CMIP5 standards is no longer supported. There are a number of changes, such as directory structure, granularity of ESGF datasets, persistent identifiers, and furtherinfourl, which have been introduced to make life easier for everyone.

Another option might be to have historical as the experiment_id and introduce cmip5 as a sub_experiment_id. I'm not sure how well this would work. To make it work well for users I think we would need a change in the search interface to allow people to select none for sub_experiment_id (at the moment you can only select specific values, you can't choose to search for datasets which have no sub_experiment_id).

[MartinaSt]

ESGF has CMIP6-specific extension, which are not used by other projects. The additional services are offered for CMIP6. If this data would be published under the CMIP5 standards, the adaption effort would lie with the modeling center. And if we decide to publish it under the CMIP6 standards the adaption is on the infrastructure side. But I don't think this is a technical issue.

If we decide to publish this CMIP5 data with CMIP6 standards, the DRS defines the ESGF search facets and thus an ESGF CoG user will find this data in the CMIP6 collection but not in the CMIP5 collection ( https://esgf-data.dkrz.de/search/cmip6-dkrz/ instead of https://esgf-data.dkrz.de/search/cmip5-dkrz/ ). Such a user will not find the new CMIP5 data.

From the different possibilities discussed the mip_era needs the most adaptation as we have used it at several points to distinguish from CMIIP5 and other projects. sub_experiment_idmixes CMIP5 and CMIP6 in the citation. For centers publishing CMIP5 and CMIP6 under CMIP6 standards, they cannot cite the CMIP6 experiment separately. Thus I still favor the experiment_id suggestion.

[taylor13]

To be clear, I think we said on the telco that publishing any CMIP5-compliant data (even data from CMIP5 experiments) is not being considered because that would break too many things.

I think we should probably focus on what we should do in the CMIP7-era, and then see if we can fit in new CMIP5-era experiments to whatever approach we plan to adopt for the future. In the future, we hope that the DECK and historical simulations will be ongoing. If we keep their "experiment_ids", but at least in the historical expt., we modify the forcing data sets and extend the historical period to near-present, then how will users best be served through a faceted search?

The strategy (which we can consider changing) was to distinguish the historical run with CMIP6-era forcing from the historical run with CMIP7-era forcing using the mip_era attribute (set either to "CMIP6" or "CMIP7"). Then a user could either find all available historical simulations by not choosing an era, or could limit their search to historical simulations from a single mip_era. The mip_era does not refer to the era of a model, but, rather, the era in which the experiment was defined.

If we follow this strategy in treating the new CMIP5-era experiments (historical, piControl, and rcpXXXs), we would tag this output (in the CMIP6 archive) with mip_era = "CMIP5".

The question is whether the infrastructure could be modified easily to accommodate this. I have looked into modifying the CoG search interface, and it looks like we could do this. I do not, however, know how difficult it would be to modify PrePARE, CMOR3, ES-doc, citation services, etc., and we should not adopt the planned CMIP7 strategy if this is too difficult to implement at this time; we should wait for CMIP7. We would then have to find a kludge to accommodate these new CMIP5 runs in CMIP6.

[durack1]

Ok folks, I have made a first pass at registering the 6 new experiments, take a peek at the edited content CMIP6_experiment_id.json and if changes are required please suggest these directly using the notation tools in github (you'll need to login, and then you'll see the blue plus sign below which once clicked will open a comment window) following the screenshots below, which should be visible using the link above:

ping @taylor13 @claudiatebaldi @slavakharin @matthew-mizielinski @MartinaSt @martinjuckes @jflamarque @rjstouffer @veyring

[durack1]

Updated URL to latest file which includes suggested edits by @slavakharin, to add a piControl-spinup-cmip5 experiment - see CMIP6_experiment_id.json with SHA-1 c2817a6

[durack1]

Unless I misunderstand what is being proposed and that groups are actually planning to do historical+RCP under the CMIP5 protocol. Don't they need to retune their PI?

@jflamarque exactly, as you'll see in CMIP6_experiment_id.json with SHA-1 c2817a6 there are CMIP5-era piControls, historical and RCPxx simulations requested

[taylor13]

I have come around to the view that we should go with identifying the "era" as CMIP6, but only because doing anything else will break too many things. This isn't how we should do things in the future. We'll distinguish these experiments with "-cmip5" suffixes and we'll not use the forcing_index in any special way to identify these experiments.

[durack1]

@slavakharin for CMIP6 those experiments hist-GHG, hist-aer and hist-nat are sponsored by DAMIP. If we added these 3 additional experiments, we'd need Nathan (Gillett) to agree to add these to the DAMIP experiment suite

@slavakharin have you received confirmation from Nathan (Gillett), that DAMIP is willing to sponsor them?

[durack1]

@npgillett adding you into this thread

[durack1]

Updated URL to latest file which includes suggested edits by @taylor13, add 3 DAMIP experiments hist-GHG-cmip5,hist-aer-cmip5 and hist-nat-cmip5 experiments - see CMIP6_experiment_id.json with SHA-1 8ac8802

@npgillett, please double check the hist-* experiments for values, e.g. finishing in 2012 etc

[durack1]

@martinjuckes @charliepascoe @davidhassell @momipsl pinging you all so that the data request and ES-Docs can be updated to reflect these new experiments when they are finalized and merged

[durack1]

On 11/24/19, 6:20 PM, "Hideo SHIOGAMA" wrote:
Dear all,
Should "end_year":"2012" of hist-???-CMIP5  be "end_year":"2020"?
1850-2005 use the CMIP5 historical forcing and 2006-2020 use the CMIP5 RCP4.5 forcing.
Best wishes,
Hideo

[martinjuckes]

@durack1 : who is defining the data request for these experiments?

[durack1]

@martinjuckes as these experiments are basically cmip5-forced clones of their CMIP6 counterparts, it seems logical that each *-cmip5 experiment should inherit the same data request. I've tabulated this below:

Sponsoring MIP	experiment_id	forcing_index	tier	GMD article to update	Data request template experiment
CMIP	historical-cmip5	500...599	2	Eyring et al. (2016)	historical
CMIP	piControl-cmip5	500...599	2	Eyring et al. (2016)	piControl
CMIP	piControl-spinup-cmip5	500...599	2	Eyring et al. (2016)	piControl-spinup
DAMIP	hist-GHG-cmip5	500...599	3	Gillett et al. (2016)	hist-GHG
DAMIP	hist-aer-cmip5	500...599	3	Gillett et al. (2016)	hist-aer
DAMIP	hist-nat-cmip5	500...599	3	Gillett et al. (2016)	hist-nat
ScenarioMIP	rcp26-cmip5	500...599	3	O'Neill et al. (2016)	ssp126
ScenarioMIP	rcp45-cmip5	500...599	3	O'Neill et al. (2016)	ssp245
ScenarioMIP	rcp60-cmip5	500...599	3	O'Neill et al. (2016)	ssp460
ScenarioMIP	rcp85-cmip5	500...599	3	O'Neill et al. (2016)	ssp585