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

[Karl Taylor]

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/20120224/264532a4/attachment.html