source_id registration of ARTS-2-3

[olemke]

label = ARTS 2.3
label_extended = ARTS 2.3 (Current development version of the Atmospheric Radiative Transfer Simulator)
source_id = ARTS-2-3
institution_id = UHH
release_year = 2015
activity_participation = [RFMIP]

aerosol:
description = none
nominal_resolution = none
atmos:
description = none
nominal_resolution = none
atmosChem:
description = none
nominal_resolution = none
land:
description = none
nominal_resolution = none
landIce:
description = none
nominal_resolution = none
ocean:
description = none
nominal_resolution = none
ocnBgchem:
description = none
nominal_resolution = none
seaIce:
description = none
nominal_resolution = none

[durack1]

@taylor13 for these MIP-specific configurations (in this case RFMIP-only) how is the cohort property being managed? Can you provide a link to the documentation defining this here please?

[durack1]

@taylor13 it would be great to get this registration finalized this week

[durack1]

@RobertPincus we're going to need to get some information for you to deal with these RFMIP registration requests. We were anticipating that each would be using the host AOGCM/ESM` identifier, rather than having their own identifier. Please let us know when you're back from leave.

@taylor13

[RobertPincus]

Paul, Karl -

I’m back from leave but will be in Australia until 7 March.

I’ve tried to make clear (e.g. the email from 23 Jan) that we can expect a number of submissions to RFMIP-IRF that do originate with host AOGCMs. It’s vital that we be able to include these. ARTS and LBLRTM are only the first two of perhaps six to come.

• Robert

On Feb 22, 2018, at 4:31 PM, Paul J. Durack notifications@github.com wrote:

@RobertPincus we're going to need to get some information for you to deal with these RFMIP registration requests. We were anticipating that each would be using the host AOGCM/ESM` identifier, rather than having their own identifier. Please let us know when you're back from leave.

@taylor13

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[taylor13]

@RobertPincus

As I understand it, the "offline" radiation codes used in some of the RFMIP experiments are of two types: 1) codes pulled out of a GCM participating in CMIP6, and 2) codes (perhaps line-by-line codes) that won't be used in any CMIP6 model.

These two types of model codes need to be registered differently. A code that is used in one or more of the CMIP6 GCMs is considered to be a component of its host model, so it doesn't need to be registered. It's source_id is the name of the host model (which does have to be registered). There are a couple of additional considerations: a) If the radiation code is used in more than one CMIP6 host model, one of those model's names will need to be chosen as identifying the radiation model; it can't have two source_id's b) The name of the "institution" responsible for the offline radiation calculation contributions to RFMIP needs to be registered (if it is different from the host model's institution), and we will need to make sure that both the host model's institution and the offline code institution are associated with the source_id.

In case 2 when an offline radiation code is not being used in any CMIP6 host model, then a source_id must be registered for the radiation code (as if it were a GCM).

For both types of radiation codes, it may not be obvious how to define a few of the global attributes. Here are the attributes that might be difficult:

source_type = "RAD" which means that this is a offline radiation calculation. nominal_resolution = "0.5 km" (which is the finest resolution option available in CMIP6 and hopefully reflects the fact that a radiation calculation is performed in a single column). grid_label = "gn" (even though there really is no grid in this case) grid = ??? (I need help here. would the following be appropriate? "results reported for atmospheric columns representative of a variety of conditions")

As a reminder to Paul and me: We need to determine once these codes have completed the RFMIP experiments, which "cohort" they should be assigned to? "CMIP6-fringe", "DECK", or "CMIP6"?

[durack1]

@olemke is the registration of ARTS-2-3 a case 2 example as noted above?

[RobertPincus]

@durack1 Yes. (I know the model that @olemke refers to.)

[RobertPincus]

@taylor13 @durack1 LBLRTM, which Rick Pernak is trying to register, is in the same boat.

There will be some radiation models associated with more than one GCM. It's acceptable to have the source_id arbitrarily map to one of those models - perhaps the first to provide results?

I agree that, for radiation models not associated with a GCM, that it makes sense to register new source_ids, institutions, etc. My understanding is that that's what Rick Pernak and Oliver Lemke have been trying to do. Is there further information needed on their part, or is it possible to register these models based on what you know now?

Best - Robert

[taylor13]

@RobertPincus To answer your first question .... Yes, one of the sources using the radiation code should be (arbitrarily) selected as being the source_id for the offline radiation code runs.

[durack1]

@RobertPincus and to answer the second question, as both ARTS-2-3 and LBLRTM #460 are both standalone, we have enough information to complete these registrations - I'll do that shortly.

[durack1]

@olemke apologies for the delay, ARTS-2-3 is now registered, please review the details at CMIP6_source_id.html and let me know if any further edits are required.