<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">Hi all,<br>
<br>
I have included the go-essp-tech group in this reply, since the
software will have to handle "unsolicited" CMIP5 output (i.e.,
output not officially requested by CMIP5, but produced by CMIP5
model runs).<br>
<br>
Thanks, Jamie, for recovering the earlier discussion about this.
From that discussion (and with some expansion/decisions),
unsolicited variables may be written and served through ESG if<br>
<br>
1. They are written through CMOR (or equivalent)<br>
2. A special CMOR table has been put together including the
metadata associated with unsolicited variables and would get
written by CMOR.<br>
3. The unsolicited variable names are not the same as any of the
requested CMIP5 variable names. (A possible exception is that one
might want to provide output of one of the CMIP5 variables, but at
a different frequency than was requested. In this case the
variable name should be the same as the variable written at a
requested frequency.)<br>
4. The special CMOR table is named "none" and the "product"
recorded in the table is "unsolicited" (not "output"). Thus, the
global attribute in the netCDF files would be "unsolicited", and
the filename would begin with "<varName>_none_..." where
varName is the unsolicited variable name.<br>
<br>
Does anyone foresee any problems with this?<br>
<br>
best regards,<br>
Karl<br>
<br>
</font>On 2/24/12 8:39 AM, Kettleborough, Jamie wrote:
<blockquote
cite="mid:E51EDFEBF10BE44BB4BDAF5FC2F024B90FB7FBBE@EXXMAIL02.desktop.frd.metoffice.com"
type="cite">
<pre wrap="">Hello,
I think this has come up before. From what I remember the conclusion
was these kind of variables should be product=unsolicited, MIP table to
be decided...
I've attached the previous discussion I could related to this. Not sure
if anyone can find anything more recent. I guess this should also be
written up somewhere as 'advice to data providers'?
Jamie
</pre>
<blockquote type="cite">
<pre wrap="">-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:owner-cmor@lists.llnl.gov">owner-cmor@lists.llnl.gov</a>
[<a class="moz-txt-link-freetext" href="mailto:owner-cmor@lists.llnl.gov">mailto:owner-cmor@lists.llnl.gov</a>] On Behalf Of Doutriaux, Charles
Sent: 24 February 2012 16:30
To: Si Shen
Cc: cmor
Subject: Re: can I cmor extra variable ?
I agree,
Please DO NOT modify the official CMIP5 tables, these are
md5s and the md5 of the table you used s actually recorded in
your output files. Any discrepancy might trigger a flag at QC time.
I would strongly recommend instead to simply create a copy of
the table with only your additional variables in it.
Karl do you think it would be acceptable for this copy to be
named the same (e.g. Amon etc..) or should we create a
"special" category for non-standard tables? For example UAmon
(User Amon)? Of course because of the drs that would push
this variable in a separate location from the "regular"
variables, I'm no expert on this so I will defer to the CMIP5 experts.
C.
On Feb 23, 2012, at 7:19 PM, Si Shen wrote:
</pre>
<blockquote type="cite">
<pre wrap=""> Hello! I met a problem on CMOR output of Amon. Our model
</pre>
</blockquote>
<pre wrap="">didn't output rsdt (TOA Incident Shortwave Radiation) and
rsut (TOA Outgoing Shortwave Radiation) , but we have TOA Net
Shortwave Radiation, which might be useful in diagnosing the
model but not in Amon Table. Could I cmor this extra variable and How?
</pre>
<blockquote type="cite">
<pre wrap="">
Thank you !
Eddie ,Shen
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
</blockquote>
</body>
</html>