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

[Aparna Radhakrishnan]

Hi Karl,

Long time ago, we (GFDL) got some help from you in learning how to report
additional/unsolicited variables for CMIP5. From that conversation
(attached below) , I recall that we could name the special tables say for
instance "AmonExtras"  Hence, we have been following that for the
publishing process.

Thanks,

Aparna


Email reference below-



---------- Forwarded message ----------
From: Karl Taylor <taylor13 at llnl.gov>
Date: Tue, Apr 12, 2011 at 2:58 PM
Subject: Re: DRS question on unsolicited variables
To: Aparna Radhakrishnan <Aparna.Radhakrishnan at noaa.gov>
Cc: "Doutriaux, Charles" <doutriaux1 at llnl.gov>, "V. Balaji" <
V.Balaji at noaa.gov>, Kyle Olivo <Kyle.Olivo at noaa.gov>, "Drach, Bob" <
Drach1 at llnl.gov>


 Dear Aparna,

You need to create a new CMOR table yourself, patterned after the standard
ones.

On 4/12/11 11:08 AM, Aparna Radhakrishnan wrote:

Hi Charles and Karl,

I understand that we're welcome :) to report additional variables for
AR5. In that case, how does CMOR identify those variables? - Should we
notify you the list of such variables and corresponding
realms,dimensions etc to form the MIP tables, or can we create one
ourselves?

So, the DRS in which the "unsolicited" variables would appear like the
following ?  Also, how should the global attribute "product"/ (and the
one in DRS)look like in such cases?

 In your new CMOR table you should set product to "unsolicited".

../CMIP5/product?/GFDL-ESM2M/historical/mon/ocean/intpbp/r1i1p1/intpbp_OmonExtras_GFDL-ESM2M_historical_r1i1p1_186101-186512.nc


this looks o.k.  [By the way, be careful to avoid use of "-" in the
variable name since folks like to use these names in their Fortran codes.]

 I think drslib gets lost while transforming the DRS paths for the
"non-requested" variables since it relies on the MIP tables as well.

 Bob is modifying the publisher so that if a table name or a variable name
is unrecognized, then  the output gets placed in "unsolicited", so I think
we'll be o.k.

Best regards,
Karl

Please advise.

Thanks,

Aparna




On Fri, Feb 24, 2012 at 12:44 PM, Karl Taylor <taylor13 at llnl.gov> wrote:

>  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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/go-essp-tech/attachments/20120224/334abc3d/attachment.html