<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Dear Karl,<br>
<br>
Karl Taylor wrote, On 27/07/2011 02:16:
<blockquote cite="mid:4E2F58E7.904@llnl.gov" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
<font face="Times New Roman">Dear </font>Stéphane,<br>
<br>
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). <br>
</blockquote>
<br>
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 ?<br>
<br>
Thanks for the answer provided below.<br>
<br>
S<br>
<br>
<br>
<blockquote cite="mid:4E2F58E7.904@llnl.gov" type="cite"> <br>
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. <br>
<br>
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.<br>
<br>
You might consider a table name like "CNRM-Amon" or "Amon-CNRM" which
would then contain tos and ts.<br>
<br>
Best regards,<br>
Karl<br>
<br>
On 7/13/11 7:37 AM, Stéphane Senesi wrote:
<blockquote cite="mid:4E1DADBB.2040007@meteo.fr" type="cite">
<pre wrap="">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 ?
</pre>
</blockquote>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
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)</pre>
</body>
</html>