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

[Aparna Radhakrishnan]

Hi Karl,

Just a clarification - Our unsolicited Amon table_id is "AmonExtras", not
AmonExtra .

Thanks for the continued guidance,

Aparna



On Sat, Feb 25, 2012 at 12:20 PM, Karl Taylor <taylor13 at llnl.gov> wrote:

>  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 <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
>>
>>
>
> _______________________________________________
> GO-ESSP-TECH mailing list
> GO-ESSP-TECH at ucar.edu
> http://mailman.ucar.edu/mailman/listinfo/go-essp-tech
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/go-essp-tech/attachments/20120227/80b0e7fd/attachment-0001.html