[Go-essp-tech] CMIP5 - altering tables

[Charles Doutriaux]

Hi Stephane,

I don't think this checksum (while a great idea in my opinion) will ever 
be implemented...

So I wouldn't worry about it too much... Just try not to do it anymore ;)

C.

On 7/26/11 11:59 PM, Stéphane Senesi wrote:
> Dear Karl,
>
> Karl Taylor wrote, On 27/07/2011 02:16:
>> Dear Stéphane,
>>
>> You really should not alter the CMIP5 CMOR tables in any way (we 
>> record the checksums in the files I think, so we will know exactly 
>> which files were written using each table).
>
> We did alter table "3h" for publishing albedo data. Can anybody 
> confirm that this is really a technical issue in the ESG system ? For 
> the time being, I did not notice any problem : at PCMDI gateway, both 
> faceted search and free text search allow to discover and retrieve the 
> data. Will any control of table checksum occur at the stage of QC L2  
> or L3 ?
>
> Thanks for the answer provided below.
>
> S
>
>
>>
>> We have already provided guidance to a group wanting to write out 
>> ocean output on their native grid and on another grid after vertical 
>> interpolation.  We said they should create a special CMOR table for 
>> the second regridded data with a name of their choosing, and we urged 
>> them to choose a name that guaranteed uniqueness across the ESG archive.
>>
>> You could do this for  tos and sic on the atmospheric grid.  By the 
>> way tos and ts should be identical except in regions of sea ice, and 
>> ts is already written on the atmospheric grid.
>>
>> You might consider a table name like "CNRM-Amon" or "Amon-CNRM" which 
>> would then contain tos and ts.
>>
>> Best regards,
>> Karl
>>
>> On 7/13/11 7:37 AM, Stéphane Senesi wrote:
>>> Dear Karl and Bob
>>>
>>> We are concerned with the ease of use of CMIP5 data by various
>>> communities of users. Hence, we are considering providing some variables
>>> both on atmospheric and oceanic grids.
>>>
>>> For some variables/tables, we know that the ESG infrastructure will be
>>> OK : for instance, we can publish two additional  variables "tos" and
>>> "sic" in table Amon (and on the atmospheric grid), and the gateways will
>>> allow to discover it (we checked that already, with variable "albedo"
>>> and table 3hr). They are not in resquested output, and will not add much
>>> load to the ESG system (except for the disk space on our datanode)
>>>
>>> However, for those tables which do already mix realms, like the daily
>>> table, the solution is not that simple ; I assume that mixing files of
>>> the same realm with various grids in a single table would cause a mess
>>> in the system. We are here again concerned with variables "sic" and "tos"
>>>
>>> Can you see a way forward ?
>>>
>>>      
>
>
> -- 
> Stéphane Sénési
> Ingénieur - équipe Assemblage du Système Terre
> Centre National de Recherches Météorologiques
> Groupe de Météorologie à Grande Echelle et Climat
>
> CNRM/GMGEC/ASTER
> 42 Av Coriolis
> F-31057 Toulouse Cedex 1
>
> +33.5.61.07.99.31 (Fax :....9610)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/go-essp-tech/attachments/20110727/24ef4c1a/attachment.html