[Go-essp-tech] can I cmor extra variable ?

[Karl Taylor]

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