[Go-essp-tech] CMIP5 - altering tables

[Karl Taylor]

that's my impression too.
Karl

On 7/27/11 8:39 AM, Charles Doutriaux wrote:
> 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/4283970a/attachment.html