<!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">
<font face="Times New Roman">that's my impression too.<br>
Karl<br>
</font><br>
On 7/27/11 8:39 AM, Charles Doutriaux wrote:
<blockquote cite="mid:4E303139.407@llnl.gov" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Hi Stephane,<br>
<br>
I don't think this checksum (while a great idea in my opinion)
will ever be implemented...<br>
<br>
So I wouldn't worry about it too much... Just try not to do it
anymore ;) <br>
<br>
C.<br>
<br>
On 7/26/11 11:59 PM, Stéphane Senesi wrote:
<blockquote cite="mid:4E2FB73B.9030204@meteo.fr" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
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>
</blockquote>
<br>
</blockquote>
</body>
</html>