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

Mon Jun 28 08:54:31 MDT 2010

Dear Karl,

this flexibility in the change of parts of the DRS, model and institute,
sounds a bit dangerous to me. As I understand, the DRS is needed to
bring data and metadata together. If the DRS names in the metafor
repository and in the TDS differ, we cannot add the TDS metadata to the
CIM simulation, automatically. And if they differ too much it will be
quite cumbersome to find the matching simulation for the TDS data. This
DRS vocabulary should be some sort of fixed or controlled.

Best wishes,
Martina

Karl Taylor wrote:
> 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.
>>>
>>>      
>>>       
>>    
>>     
> _______________________________________________
> GO-ESSP-TECH mailing list
> GO-ESSP-TECH at ucar.edu
> http://mailman.ucar.edu/mailman/listinfo/go-essp-tech
>   

-- 
----------- DKRZ / Data Management -----------

Martina Stockhause
Deutsches Klimarechenzentrum
Bundesstr. 45a
D-20146 Hamburg
Germany

phone:	+49-40-460094-122
FAX:	+49-40-460094-106
e-mail:	martina.stockhause at zmaw.de

----------------------------------------------