[Go-essp-tech] can I cmor extra variable ?
Kettleborough, Jamie
jamie.kettleborough at metoffice.gov.uk
Mon Feb 27 06:16:20 MST 2012
Hello,
not sure how helpful this is, but I've copied the main responses here to
http://esgf.org/wiki/CMIP5ForProvidersFAQ
Any one who is interested should
1. check this is a reasonable summary of the current view on
'unsolicited data' (I have added a few bits to Karls main reply)
2. flag whether you think putting this in an FAQ is the best thing to do
- if not where should it be put (I'm very happy to delete the wiki page,
I just wanted to try and put a summary of this issue somewhere).
Jamie
ps I just noticed these links:
http://cmip-pcmdi.llnl.gov/cmip5/modeling_faq.html
http://cmip-pcmdi.llnl.gov/cmip5/data_faq.html
should these link to the FAQ Stephen has started to put together?
________________________________
From: go-essp-tech-bounces at ucar.edu
[mailto:go-essp-tech-bounces at ucar.edu] On Behalf Of Karl Taylor
Sent: 25 February 2012 17:20
To: Si Shen; go-essp-tech at ucar.edu; cmor at lists.llnl.gov
Subject: Re: [Go-essp-tech] can I cmor extra variable ?
Dear Eddie,
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:
toa_net_downward_shortwave_flux
toa_net_downward_shortwave_flux_assuming_clear_sky
If they are "positive upward", then:
toa_net_upward_shortwave_flux
and please write the CF mail list with a request to add:
toa_net_upward_shortwave_flux_assuming_clear_sky, which isn't currently
listed as a standard name.
thanks,
Karl
On 2/25/12 5:16 AM, Si Shen wrote:
Dear Karl,
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!
Cheers,
eddie
2012/2/25 Karl Taylor <taylor13 at llnl.gov>
Hi all,
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).
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
1. They are written through CMOR (or
equivalent)
2. A special CMOR table has been put together
including the metadata associated with unsolicited variables and would
get written by CMOR.
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.)
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.
Does anyone foresee any problems with this?
best regards,
Karl
On 2/24/12 8:39 AM, Kettleborough, Jamie wrote:
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
-----Original Message-----
From: owner-cmor at lists.llnl.gov
[mailto:owner-cmor at lists.llnl.gov] 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:
Hello! I met a problem on CMOR output
of Amon. Our model
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?
Thank you !
Eddie ,Shen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/go-essp-tech/attachments/20120227/aea777aa/attachment.html
More information about the GO-ESSP-TECH
mailing list