Shared ownership of experiments: AerChemMIP and RFMIP

[matthew-mizielinski]

I've been reminded that certain experiments are shared between AerChemMIP and RFMIP; piClim-aer piClim-control

In the CVs, e.g. here these experiments do have multiple activity IDs (as do a small number of other experiments), however I don't see anything in the data request to reflect this.

Is this an omission in the data request, or should we expect users to (know of) and work around this?

[martinjuckes]

Hello Matthew, I'm not sure what the implication of this is. Where would you have to work around it?

[matthew-mizielinski]

Sorry Martin, this is almost certainly a problem in our interface to the data request, which won't allow us to request variables from the piClim-aer experiment being performed for AerChemMIP as it is owned by RFMIP within the data request. We'll need to put in a work around to allow for the few experiments which are shared between MIPs.

The issue arises as we'll be submitting UKESM1 for AerChemMIP, but HadGEM3 (physical model) for RFMIP. The publication process will get upset if we submit data for the piClim-aer experiment for RFMIP using the UKESM1 model as we have not registered this MIP for this model.

There are 9 other models that are being submitted to AerChemMIP, but not RFMIP according to the CVs, so depending on how other centres access the data request this could cause a little confusion.

Looking at this again I'm not sure that this is an issue for you to fix; your drq tool doesn't care about which MIP "owns" the experiment, but depending on how modelling groups access the data request this could cause complications unless everyone is aware of the issue ahead of submission.

@senesis, CNRM-ESM2-1 is another model that is registered against AerChemMIP, but not RFMIP -- is this issue likely to cause any complications in configuring your model?

[senesis]

The logic for dr2xml (the tool I designed for translating DR to XIOS configuration files for CNRM-CM, CNRM-ESM, IPSL-CM, and possibly Nemo in EC-Earth model) is roughly first to gather all request links which apply to the set of MIPs the model is involved in, and next to filter all corresponding request items which apply to the experiment being performed. So, there is no issue with this case. Thanks for the care, Matthew

[martinjuckes]

Hi Matthew,

I'm not sure I understand what you are saying, but it is important to provide data requested by MIPs from experiments not "owned" by them. Many MIPs are, for example, requesting data from ScenarioMIP experiments. The shared ownership in the CMIP6 CVs does not reflect all the cases in which MIPs are requesting data from experiments of other MIPs,

regards,

Martin

---

From: Matthew Mizielinski notifications@github.com Sent: 05 June 2018 16:39 To: cmip6dr/Request Cc: Juckes, Martin (STFC,RAL,RALSP); Comment Subject: Re: [cmip6dr/Request] Shared ownership of experiments: AerChemMIP and RFMIP (#79)

Sorry Martin, this is almost certainly a problem in our interface to the data request, which won't allow us to request variables from the piClim-aer experiment being performed for AerChemMIP as it is owned by RFMIP within the data request. We'll need to put in a work around to allow for the few experiments which are shared between MIPs.

The issue arises as we'll be submitting UKESM1 for AerChemMIP, but HadGEM3 (physical model) for RFMIP. The publication process will get upset if we submit data for the piClim-aer experiment for RFMIP using the UKESM1 model as we have not registered this MIP for this model.

There are 9 other models that are being submitted to AerChemMIP, but not RFMIP according to the CVs, so depending on how other centres access the data request this could cause a little confusion.

Looking at this again I'm not sure that this is an issue for you to fix; your drq tool doesn't care about which MIP "owns" the experiment, but depending on how modelling groups access the data request this could cause complications unless everyone is aware of the issue ahead of submission.

@senesishttps://github.com/senesis, CNRM-ESM2-1 is another model that is registered against AerChemMIP, but not RFMIP -- is this issue likely to cause any complications in configuring your model?

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/cmip6dr/Request/issues/79#issuecomment-394757616, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AHcQvzAXmgSwBt5nFTNny9LcZ0tP1aVdks5t5qYpgaJpZM4UWcrJ.

[matthew-mizielinski]

Martin,

This issue isn't about respecting requests from other MIPs for particular experiments, rather about how the data request represents experiments that can be owned by one of two MIPs. The following will hopefully clarify the issue as I see it. As noted above I don't think data request changes are necessary, but users may need to made aware of how to deal with shared experiments.

In the ESGF publication process I believe there is a step where the mip, source_id combination for a data set is compared against the CVs.

For the piClim-aer experiment noted above I expect to submit data to

• RFMIP from HadGEM3-GC31-LL
• AerChemMIP from UKESM1-0-LL

According to the CVs this is fine (see here), but in the data request this experiment is owned only by RFMIP, i.e. there is no connection to piClim-aer listed under AerChemMIP.

As UKESM1 is not registered in the CVs against RFMIP, I would expect the publication process to fail (at the doi stage?) if we attempted to submit data sets with mip set to RFMIP and source_id set to UKESM1-0-LL.

I think it is only our interface to the data request that is affected by this issue, and we will deal with that, but it may be worth putting a note somewhere to direct anyone looking for experiments such as piClim-aer in AerChemMIP to look for it in the first activity_id listed in the CVs (RFMIP in this case). I believe there are around 5 or 6 experiments that are shared between two MIPs.

I'm happy for this issue to be closed if you don't see any required actions.

[martinjuckes]

I don't think there is a data request issue here. The publisher will use the PCMDI CVs, so you should be OK if you register as PCMDI want you to .... the data request is out of this loop.