<!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 text="#000000" bgcolor="#ffffff">
Thanks all for the prompt answer and clarification.<br>
<br>
<br>
Le 10/11/2010 20:59, Karl Taylor a écrit :
<blockquote cite="mid:4CDAF986.2060301@llnl.gov" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<font face="Times New Roman">Dear all,<br>
</font><br>
The filenames called for by the DRS and output by CMOR2 (recent
versions) are the same and unchanged. Right?<br>
<br>
I'm not absolutely certain that the quoted section of the DRS is
accurate. My latest understanding is that the "ESG version will
usually be assigned by the ESG publisher, and it cannot be guaranteed
that it always will be consistent with version number appearing in the
ESGF data node directory structure for the data being published. In
many cases the directory structure will be generated some days prior to
ESG publication, so the dates may differ."<br>
<br>
Does anyone disagree with this? <br>
</blockquote>
<br>
That's clearer. So the DRS needs some adaptation concerning the version
number "issuer" ; the publisher is the real driver. It implies that if
we publish a simulation in several streams so at different dates (many
reason to support that) they will have different version number. I
think loudly just to put myself in situation.<br>
<br>
<br>
<blockquote cite="mid:4CDAF986.2060301@llnl.gov" type="cite"> In any
case I think it's much too late to change the directory structure
created by CMOR2 (which, by the way, is optional).<br>
</blockquote>
<br>
Ok. <br>
<br>
<blockquote cite="mid:4CDAF986.2060301@llnl.gov" type="cite"> Note that
drslib has functionality to transform from any directory structure
whatsoever to the ESGF data node directory structure called for by the
DRS. Also note that the ESG publisher doesn't rely on the directory
structure being consistent with DRS, although we think it is important
that it be so.<br>
</blockquote>
<br>
Yes we think as well it's important that at the filesystem level we
stick to the ESG-F datanode DRS. To organize multi model / multi
experiment analysis by AR5 author and by institute researcher this is
important for every group. We will use drslib in the production system
then.<br>
<br>
I still have questions for Martin about the different "derived product
class" and their link with "raw" CMIP5 output. I will discuss that
first with Martin "offline" and may get back "online" to enhance my
understanding.<br>
<br>
Regards.<br>
Sébastien<br>
<br>
<br>
<blockquote cite="mid:4CDAF986.2060301@llnl.gov" type="cite"> regards,<br>
Karl<br>
<br>
On 11/10/10 6:51 AM, Sébastien Denvil wrote:
<blockquote cite="mid:4CDAB16D.4060406@ipsl.jussieu.fr" type="cite">
<pre wrap="">Dear all,
I have seen that version v1.0 of the DRS has been released
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://BLOCKEDcmip-pcmdi.llnl.gov/cmip5/output_req.html?submenuheader=2#req_format">http://BLOCKEDcmip-pcmdi.llnl.gov/cmip5/output_req.html?submenuheader=2#req_format</a>
which is very good.
Reading it, it's clear that CMOR2.x will output files to a directory
structure (but not a filename encoding) mapping the old DRS version
(v0.27).
</pre>
</blockquote>
<br>
<blockquote cite="mid:4CDAB16D.4060406@ipsl.jussieu.fr" type="cite">
<pre wrap="">My question is, what is the strong rational behind that fact? Can't
CMOR2.x follow the version v1.0 DRS and be natively compatible with the
ESGF data node directory structure?
The version number is apparently the reason.
<activity>/<product>/<institute>/<model>/<experiment>/<frequency>/<modeling
realm>/<MIP table>/<ensemble member>/<version number>/<variable name>/
<CMOR filename>.nc
But quoting the DRS:
"Note that the version number assigned to the dataset by ESG is supposed
to reflect the date of ESG publication, but the version will usually be
assigned by the user so this cannot generally be guaranteed. The user
will be instructed to provide ESG with the date that appears in the ESGF
data node directory structure for the dataset being published. In many
cases the directory structure will be generated some days prior to
publication, so the date will not in fact reflect the date of
publication, but the date that the directory structure was created."
In fine, the user will decide/provide the version number. So I think the
user should do that via CMOR2.x.
CMOR2.x could use the current date as a version number. Or preferably,
because cmor post-processing can last few days for a MIP_TABLE, be
assigned to CMOR2.x via an option by the user. This would guarantee that
all variables belonging to the same "stream" belongs to the same version
number.
As we all hold the presses waiting for the CMOR2.5 release to continue
the production, it could be a good timing to have CMOR2.x compatible
with DRS v1.0. Depending on the CMIP5 data distribution system "big
opening day" I'm willing to rewrite now what we have to be from the
beginning in line with CMOR2.x, DRS v1.0 and publication aspect.
Regards.
Sébastien
</pre>
</blockquote>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Sébastien Denvil
IPSL, Pôle de modélisation du climat
UPMC, Case 101, 4 place Jussieu,
75252 Paris Cedex 5
Tour 45-55 2ème étage Bureau 209
Tel: 33 1 44 27 21 10
Fax: 33 1 44 27 39 02
</pre>
</body>
</html>