[Go-essp-tech] CMIP5 / DRS controlled vocabulary

martin.juckes at stfc.ac.uk martin.juckes at stfc.ac.uk
Mon Jun 28 08:35:49 MDT 2010


Hello Stephen, Karl,

I certainly wouldn't want to remove the "Had" from "HadGEM" -- as
Stephen says, we were discussion a suggestion from Bob to modify the
DRS. 

On Stephen's question about what the "institute" represents I think the
answer is neither the institute that created the model nor the one that
ran it, but the institute that is responsible for a suite of
experiments. Thus, MOHC is responsible for all experiments done in the
UK with their models. This is important, as it guarantees that control
and perturbation experiments which might be carried out by different
institutions will not be split into different branches of the DRS,

Cheers,
Martin 

> -----Original Message-----
> From: go-essp-tech-bounces at ucar.edu [mailto:go-essp-tech-
> bounces at ucar.edu] On Behalf Of stephen.pascoe at stfc.ac.uk
> Sent: 28 June 2010 15:07
> To: taylor13 at llnl.gov
> Cc: Drach1 at llnl.gov; go-essp-tech at ucar.edu; doutriaux1 at llnl.gov
> Subject: Re: [Go-essp-tech] CMIP5 / DRS controlled vocabulary
> 
> 
> 
> > I think some of the modelling groups will be reluctant to remove
some
> indication of institution from their
> > model names.  For example, HadGEM1 includes an indication that this
> is
> a Hadley center model.  They
> > wouldn't want to shorten it to GEM1.
> 
> Hi Karl, I wasn't suggesting striping "Had" from Hadley centre models
> but Bob had the term "mohc-hadgem1-2" which seems redundant to me.  I
> think this is partially a branding question.  I think of HadGEM1 as a
> model that was created at MOHC but which might be run by another
> institution.  In fact I'm slightly surprised we don't have a Had*
model
> from NERC in our CMIP5 mapping but I guess it's up to the institutions
> to decide how they brand their contributions to CMIP5.
> 
> Maybe the definition of the DRS institution is a bit vague.  Is it the
> owners of the model codebase or the institution where the simulation
> was
> done?
> 
> S.
> 
> ---
> Stephen Pascoe  +44 (0)1235 445980
> British Atmospheric Data Centre
> Rutherford Appleton Laboratory
> 
> -----Original Message-----
> From: Karl Taylor [mailto:taylor13 at llnl.gov]
> Sent: 28 June 2010 14:55
> To: Pascoe, Stephen (STFC,RAL,SSTD)
> Cc: Drach, Bob; Doutriaux, Charles; go-essp-tech at ucar.edu
> Subject: Re: [Go-essp-tech] CMIP5 / DRS controlled vocabulary
> 
> Dear Stephen,
> 
> I think some of the modeling groups will be reluctant to remove some
> indication of institution from their model names.  For example,
HadGEM1
> includes an indication that this is a Hadley center model.  They
> wouldn't want to shorten it to GEM1.  Similarly MIROC4.2(M) couldn't
> eliminate institute from the name.  The "model name" is meant to be
> used
> *as is* by researchers when they want to identify a model in a
> publication.  For this reason modeling groups should have the freedom
> to
> specify what the model name is without too many restrictions.
> 
> In some cases there will obviously be some redundancy between
> institution and model name, but I think this is o.k.  Groups may, of
> course, omit any indication of institute in their model name and that
> is
> o.k. too.
> 
> Best regards,
> Karl
> 
> 
> 
> On 6/28/10 1:39 AM, stephen.pascoe at stfc.ac.uk wrote:
> >
> > Hi Bob,
> >
> >
> >> Since the institute names are fairly short, it might not be so bad
> to
> >>
> > include them in the model name. It
> >
> >> has the advantage of making the models unique, which simplifies
> >>
> > searching.
> >
> >> If the duplication is undesirable, my preference would be to not
use
> >>
> > the institute name in the directory
> >
> >> structure at all, and thereby reduce the number of levels.
> >>
> > I'm agnostic on the merit of separating institute and model but
since
> > it's been in the DRS document for months I feel the decision has
been
> > made and we should comply with it.  With separate DRS components for
> > institute and model it is counter-productive to include the
institute
> > in the model name.  The institute component becomes redundant and
> > searching for a particular model, wherever it was run, becomes more
> difficult.
> >
> > Cheers,
> > Stephen.
> >
> >
> > ---
> > Stephen Pascoe  +44 (0)1235 445980
> > British Atmospheric Data Centre
> > Rutherford Appleton Laboratory
> >
> > -----Original Message-----
> > From: Bob Drach [mailto:drach1 at llnl.gov]
> > Sent: 25 June 2010 18:56
> > To: Pascoe, Stephen (STFC,RAL,SSTD)
> > Cc: Bob Drach; Charles Doutriaux; go-essp-tech at ucar.edu; Karl Taylor
> > Subject: Re: [Go-essp-tech] CMIP5 / DRS controlled vocabulary
> >
> > Hi Stephen,
> >
> > I don't know if Charles is around - I'll add my two cents.
> >
> > On Jun 25, 2010, at 8:44 AM,<stephen.pascoe at stfc.ac.uk>
> > <stephen.pascoe at stfc.ac.uk>  wrote:
> >
> >
> >> Hi Bob, Charles
> >>
> >> Thanks for this, distributing these mappings are really important
> for
> 
> >> getting the DRS structure right.  I'm trying to reconcile this
> >> mapping
> >>
> >
> >> with our DRS-checking code.
> >>
> >> I have a few questions about the model ->  institute mappings:
> >>
> >> * How does these mappings relate to the directory structure created
> >> by
> >>
> >
> >> CMOR.  For instance the model ids in the link are a combination of
> >> model and institute from the DRS.  I don't think CMOR will produce
> >> directories of the form CMIP5/output/MOHC/MOHC-HADCM3/... it will
be
> >> CMIP5/output/MOHC/HADCM3/...
> >>
> > Since the institute names are fairly short, it might not be so bad
to
> > include them in the model name. It has the advantage of making the
> > models unique, which simplifies searching. If the duplication is
> > undesirable, my preference would be to not use the institute name in
> > the directory structure at all, and thereby reduce the number of
> levels.
> >
> >
> >> * Which institutions do the GISS-E and MIROC* models map to?  I
have
> >> sketched in NASA and NIES but these don't appear in your institute
> >> list
> >>
> > Probably GISS or NASA GISS, CCSR for MIROC. Karl may have an
opinion.
> > It should ultimately be the modelling group's choice.
> >
> >
> >> * Which models map to institute NCC?
> >>
> > ncc-noresm
> >
> >> * CMOR appears to use upper case for model and institute names.  Is
> >> there a reason why you have lower case here?
> >>
> > Only because that's the convention we used for CMIP3. The
comparisons
> > should be case insensitive IMO.
> >
> >
> >> * The institute "CNRM/CERFACS" is clearly inappropriate for use in
> >> the DRS since it can't translate into a directory name.  Is CNRM
> >> sufficient?
> >>
> > I believe so, with the same caveat as above.
> >
> > Best regards,
> >
> > Bob
> >
> >> Cheers,
> >> Stephen.
> >>
> >> ---
> >> Stephen Pascoe  +44 (0)1235 445980
> >> British Atmospheric Data Centre
> >> Rutherford Appleton Laboratory
> >>
> >> -----Original Message-----
> >> From: go-essp-tech-bounces at ucar.edu
> >> [mailto:go-essp-tech-bounces at ucar.edu] On Behalf Of Bob Drach
> >> Sent: 17 June 2010 19:44
> >> To: GO-ESSP
> >> Subject: [Go-essp-tech] CMIP5 / DRS controlled vocabulary
> >>
> >> I've posted a summary of the CMIP5 / DRS controlled vocabulary, as
> >> represented in the ESG publisher configuration. See:
> >>
> >> http://**esg-pcmdi.llnl.gov/internal/esg-data-node-documentation/
> >> cmip5_con
> >> trolled_vocab.txt/view
> >>
> >> The document is also linked from the CMIP5 website.
> >>
> >> Some of the model information is not yet complete, particularly the
> >> URLs associated with each model. It is also likely that more models
> >> will be added to the list. Please let me know of any errors or
> >> omissions.
> >>
> >> Bob D.
> >> _______________________________________________
> >> GO-ESSP-TECH mailing list
> >> GO-ESSP-TECH at ucar.edu
> >> http://**mailman.ucar.edu/mailman/listinfo/go-essp-tech
> >> --
> >> Scanned by iCritical.
> >>
> >>
> >
> --
> Scanned by iCritical.
> _______________________________________________
> GO-ESSP-TECH mailing list
> GO-ESSP-TECH at ucar.edu
> http://mailman.ucar.edu/mailman/listinfo/go-essp-tech
-- 
Scanned by iCritical.


More information about the GO-ESSP-TECH mailing list