[Go-essp-tech] can I cmor extra variable ?
Karl Taylor
taylor13 at llnl.gov
Sat Feb 25 10:20:18 MST 2012
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 <mailto: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>
>>> [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/20120225/40dbc72a/attachment-0001.html
More information about the GO-ESSP-TECH
mailing list