[Go-essp-tech] CMIP5 - altering tables

[Stéphane Senesi]

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/ae0f442b/attachment.html