[Go-essp-tech] standard_name to variable mapping in CMIP5

[Sébastien Denvil]

  Dear Karl,

the file we published on ESG where originally created using "23 August 
2010" or "30 November 2010" tables.

But we rewrote them using "31 January 2011" tables where necessary.

For example *all* our land variables has been rewritten using 31 January 
2011 tables. So *all* our land files have standard name in it.

I don't know how gateways feed their standard names database. But it 
could be that they use CMOR2 tables and not the metadata coming from the 
files. This could be another explanation.

------------------------
creation_date = "2011-01-08T01:50:31Z" ;
history = "2011-01-08T01:50:31Z CMOR rewrote data to comply with CF 
standards and CMIP5 requirements." ;
table_id = "Table 6hrLev (30 November 2010) 
6c116423753a0c320c0cf3e31acd51b9" ;
------------------------
creation_date = "2011-02-23T17:56:33Z" ;
history = "2011-02-23T17:56:33Z CMOR rewrote data to comply with CF 
standards and CMIP5 requirements." ;
table_id = "Table Lmon (31 January 2011) a84ae296f75bb85ff61668fac8fcf090" ;
------------------------

Regards.
Sébastien

On 27/05/2011 23:37, Karl Taylor wrote:
> Dear Stephen,
>
> Here's some information that might provide a partial explanation:
>
> 1.  all 10 variables you list do indeed have the same same standard 
> name (area_fraction).  The standard_name alone is *not meant to* 
> uniquely identify a variable (you need other metadata attributes to do 
> this).
>
> 2.  All but 1 (prveg) of the 22 standard names listed were not agreed 
> until early November 2010.  So the CMOR tables did not include a 
> standard name for these variables prior to that time.  [Note inclusion 
> of the standard_name attribute is not required for CF compliance.]  If 
> IPSL wrote this output before November 2010 (or subsequent to that 
> time used out-dated CMOR tables), then the standard_name attribute 
> will not appear in their files.
>
> Because of the above (and for many other reasons), a user should be 
> able to discover variables not only by searching on the standard_name, 
> but also the long_name or the variable name itself (i.e., netCDF 
> variable name).  Does someone know whether anyone is working on 
> improving the search capability?
>
> We should at least make user's aware that only variables with 
> standard_names will appear in the current search.
>
> Best regards,
> Karl
>
> On 5/27/11 4:15 AM, stephen.pascoe at stfc.ac.uk wrote:
>>
>> I've noticed the mapping between standard_name and variable name 
>> isn't 1-to-1 for some IPSL data in the BADC Gateway.  This may be a 
>> Gateway configuration error or it might be a standard_name issue.  
>> Details below:
>>
>> The dataset 
>> "cmip5.output1.IPSL.IPSL-CM5A-LR.historical.mon.land.Lmon.r4i1p1" has 
>> 49 variables but only 18 show up on the faceted search.  If I 
>> investigate the Gateway database I see that :
>>
>> * 10 variables are given the standard name "area_fraction":
>>
>>       cropFrac c4PftFrac residualFrac  grassFrac  landCoverFrac 
>> treeFracPrimEver   treeFracPrimDec treeFrac  baresoilFrac c3PftFrac
>>
>>  * 22 variables don't have a standard_name:
>>
>>       fLuc, fLitterSoil, nppWood, nep, cSoilMedium, nppLeaf, 
>> fHarvest, rGrowth, nppRoot, cLitterBelow, nbp, cSoilSlow, cRoot, 
>> cSoilFast, cLeaf, prveg, cWood, rMaint, cLitterAbove, fFire, cMisc, 
>> cProduct
>>
>> Is this how it should be?
>>
>> Thanks,
>>
>> Stephen.
>>
>> ---
>>
>> Stephen Pascoe  +44 (0)1235 445980
>>
>> Centre of Environmental Data Archival
>>
>> STFC Rutherford Appleton Laboratory, Harwell Oxford, Didcot OX11 0QX, UK
>>
>>
>> -- 
>> Scanned by iCritical.
>>
>>
>
> _______________________________________________
> GO-ESSP-TECH mailing list
> GO-ESSP-TECH at ucar.edu
> http://mailman.ucar.edu/mailman/listinfo/go-essp-tech


-- 
Sébastien Denvil
IPSL, Pôle de modélisation du climat
UPMC, Case 101, 4 place Jussieu,
75252 Paris Cedex 5

Tour 45-55 2ème étage Bureau 209
Tel: 33 1 44 27 21 10
Fax: 33 1 44 27 39 02

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/go-essp-tech/attachments/20110530/dacf42a8/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4172 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.ucar.edu/pipermail/go-essp-tech/attachments/20110530/dacf42a8/attachment.bin