Hi Karl,<br><br>Long time ago, we (GFDL) got some help from you in learning how to report additional/unsolicited variables for CMIP5. From that conversation (attached below) , I recall that we could name the special tables say for instance "AmonExtras" Hence, we have been following that for the publishing process. <br>
<br>Thanks,<br><br>Aparna<br><br><br>Email reference below- <br><pre><br></pre><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Karl Taylor</b> <span dir="ltr"><<a href="mailto:taylor13@llnl.gov">taylor13@llnl.gov</a>></span><br>
Date: Tue, Apr 12, 2011 at 2:58 PM<br>Subject: Re: DRS question on unsolicited variables<br>To: Aparna Radhakrishnan <<a href="mailto:Aparna.Radhakrishnan@noaa.gov">Aparna.Radhakrishnan@noaa.gov</a>><br>Cc:
"Doutriaux, Charles" <<a href="mailto:doutriaux1@llnl.gov">doutriaux1@llnl.gov</a>>, "V. Balaji"
<<a href="mailto:V.Balaji@noaa.gov">V.Balaji@noaa.gov</a>>, Kyle Olivo <<a href="mailto:Kyle.Olivo@noaa.gov">Kyle.Olivo@noaa.gov</a>>,
"Drach, Bob" <<a href="mailto:Drach1@llnl.gov">Drach1@llnl.gov</a>><br><br><br>
<div bgcolor="#ffffff">
<font face="Times New Roman">Dear Aparna,<br>
<br>
You need to create a new CMOR table yourself, patterned after the
standard ones. <br>
</font><div class="im"><br>
On 4/12/11 11:08 AM, Aparna Radhakrishnan wrote:
<blockquote type="cite">
<pre>Hi Charles and Karl,
I understand that we're welcome :) to report additional variables for
AR5. In that case, how does CMOR identify those variables? - Should we
notify you the list of such variables and corresponding
realms,dimensions etc to form the MIP tables, or can we create one
ourselves?
So, the DRS in which the "unsolicited" variables would appear like the
following ? Also, how should the global attribute "product"/ (and the
one in DRS)look like in such cases?
</pre>
</blockquote></div>
In your new CMOR table you should set product to "unsolicited".<br>
<blockquote type="cite">
<pre>../CMIP5/product?/GFDL-ESM2M/historical/mon/ocean/intpbp/r1i1p1/intpbp_OmonExtras_GFDL-ESM2M_historical_r1i1p1_186101-186512.nc
</pre>
</blockquote>
<br>
this looks o.k. [By the way, be careful to avoid use of "-" in the
variable name since folks like to use these names in their Fortran
codes.]<div class="im"><br>
<blockquote type="cite">
<pre>I think drslib gets lost while transforming the DRS paths for the
"non-requested" variables since it relies on the MIP tables as well.
</pre>
</blockquote></div>
Bob is modifying the publisher so that if a table name or a variable
name is unrecognized, then the output gets placed in "unsolicited",
so I think we'll be o.k.<br>
<br>
Best regards,<br>
Karl<br>
<blockquote type="cite">
<pre>Please advise.
Thanks,
Aparna
</pre>
</blockquote>
</div>
</div><br><br><div class="gmail_quote">On Fri, Feb 24, 2012 at 12:44 PM, Karl Taylor <span dir="ltr"><<a href="mailto:taylor13@llnl.gov">taylor13@llnl.gov</a>></span> wrote:<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 href="mailto:owner-cmor@lists.llnl.gov" target="_blank">owner-cmor@lists.llnl.gov</a>
[<a 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>
<pre></pre>
</blockquote>
</blockquote>
</div></div></div>
</blockquote></div><br>