<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">Dear Eddie,<br>
<br>
For consistency with guidance provided to Aparna at GFDL, perhaps
it would be better to store "table_id" as AmonExtra (rather than
"none"). The variable names look o.k. If your net fluxes are
"positive down", then the standard names should be:<br>
toa_net_downward_shortwave_flux<br>
toa_net_downward_shortwave_flux_assuming_clear_sky<br>
<br>
If they are "positive upward", then:<br>
toa_net_upward_shortwave_flux<br>
and please write the CF mail list with a request to add: </font><font
face="Times New Roman">toa_net_upward_shortwave_flux_assuming_clear_sky</font>,
which isn't currently listed as a standard name.<br>
<br>
thanks,<br>
Karl<br>
<font face="Times New Roman"><br>
</font><br>
On 2/25/12 5:16 AM, Si Shen wrote:
<blockquote
cite="mid:CAC40pX_Kct33XvRfsUeOk_Jt=eKxbcorcX7C4eOQ=2E8J3iu6g@mail.gmail.com"
type="cite">Dear Karl,<br>
<br>
We have written a new ad-hoc table "CMIP5_AmonExtra", which
includes the two variables named "rsnt" and "rsntcs". The table id
and product have been modified to "none" and "unsolicited"
respectively. And the data can be generated successfully. Is this
ok for releasing? Thanks for everybody's help!<br>
<br>
Cheers,<br>
<br>
eddie<br>
<br>
<div class="gmail_quote">2012/2/25 Karl Taylor <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:taylor13@llnl.gov">taylor13@llnl.gov</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div 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>
<div>
<div class="h5">On 2/24/12 8:39 AM, Kettleborough, Jamie
wrote:
<blockquote type="cite">
<pre>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>-----Original Message-----
From: <a moz-do-not-send="true" href="mailto:owner-cmor@lists.llnl.gov" target="_blank">owner-cmor@lists.llnl.gov</a>
[<a moz-do-not-send="true" href="mailto:owner-cmor@lists.llnl.gov" target="_blank">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> Hello! I met a problem on CMOR output of Amon. Our model
</pre>
</blockquote>
<pre>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>Thank you !
Eddie ,Shen
</pre>
</blockquote>
</blockquote>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
</body>
</html>