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

[Kettleborough, Jamie]

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