[CF-metadata] [CF Metadata] Question about ancillary variables/formula terms variables

Karl Taylor taylor13 at llnl.gov
Tue Dec 22 10:31:06 MST 2015


Thanks, Jim.

Glad that my edit "find" skills haven't deteriorated too much.

best,
Karl

On 12/22/15 9:10 AM, Jim Biard wrote:
> Karl,
>
> This is not in CF. There is a statement that many assume that bounds 
> are at the midpoints between coordinate values, but it then points out 
> that this is not a convention. That's as close as it gets. If it was 
> there in the past it is gone now.
>
> Grace and peace,
>
> Jim
>
> On 12/22/15 12:07 PM, Karl Taylor wrote:
>> Hi John,
>>
>> this is a bit of a tangent, but you state:
>> "Another possible use case is to represent contiguous bounds, where 
>> lower_bounds(i+1) == upper_bounds(i), then one only needs n+1 values 
>> instead of 2*n."
>>
>> I seem to recall this option in CF, but recently I was reviewing the 
>> bounds specification, and I can't see where this is allowed.  Was it 
>> in the original standard and subsequently removed?  Or am I just 
>> unable to fine where it says you don't need the 2nd dimension on 
>> bounds in this case?
>>
>> best regards,
>> Karl
>>
>> On 12/22/15 8:39 AM, John Caron wrote:
>>> Hi David:
>>>
>>> At the risk of giving more useful answers to the wrong question, i 
>>> will say that we could do something other than require ancillary or 
>>> coordinate variables to only have dimensions that the parent 
>>> variable has. There just must be a simple and explicit rule for 
>>> mapping between parent and child dimension.
>>>
>>> We went down that path with DSG, in order to efficiently store 
>>> ragged arrays. Another possible use case is to represent contiguous 
>>> bounds, where lower_bounds(i+1) == upper_bounds(i), then one only 
>>> needs n+1 values instead of 2*n.
>>>
>>> Anyway, i think the rule of only allowing dimensions that are in the 
>>> parent is a good one, but for compelling use cases, we could also 
>>> allow "simple and explicit" alternatives.
>>>
>>> regards,
>>> John
>>>
>>> On Tue, Dec 22, 2015 at 4:07 AM, David Hassell 
>>> <d.c.hassell at reading.ac.uk <mailto:d.c.hassell at reading.ac.uk>> wrote:
>>>
>>>     Hello all,
>>>
>>>     Many thanks for the replies. It seems there is only support for the
>>>     case that ancillary variable dimensions must be a subset of their
>>>     parent variable dimensions (treating scalar coordinate variables
>>>     like
>>>     size 1 coordinate variables for the sake of a snappier sentence
>>>     - oh,
>>>     that's blown it).
>>>
>>>     This reminded of an old thread about this that Mark started
>>>     (http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2013/056162.html).
>>>     In
>>>     this thread Jim convincingly argues for an ancillary variable which
>>>     can have size-greater-than-one dimensions which the parent variable
>>>     does not span
>>>     (http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2013/056215.html):
>>>
>>>       "As an example, let's say that I have a variable a[X,Y,T], which
>>>        contains the total energy deposited per day into the
>>>     atmosphere by
>>>        charged particles (from the solar wind & Van Allen belts) on a
>>>        lon/lat grid as a function of time.  (Something I used to work on
>>>        many years ago.)  Let's then say that I have another variable,
>>>        b[X,Y,Z], which represents the model atmosphere density
>>>     profile on
>>>        the same lon/lat grid as a function of altitude. This density
>>>        profile was used in the calculation of the energy deposition
>>>     values
>>>        stored in variable a.  Variable b is clearly valid as an
>>>     ancillary
>>>        variable for a, isn't it?"
>>>
>>>     Mark raised a defect ticket (#98) about this, but withdrew it in
>>>     light
>>>     of the lack of supprt from the mailing list discussion.
>>>
>>>     However, variable b in Jim's example seems to me to be storing
>>>     "sub-grid scale information", so if we are to allow that we
>>>     perhaps we
>>>     ought to allow coordinate variables which sub-grid values and
>>>     which do
>>>     not span their any of their variable dimensions. For example, we
>>>     might
>>>     want to store the longitude coordinates which contributed to a zonal
>>>     mean. The size 1 dimension case I originally raised is merely a
>>>     special case of this, I feel.
>>>
>>>     But I do not think that there is any appetite for this at this time,
>>>     and certainly not from me. John - your comment here was actually
>>>     very
>>>     useful!
>>>
>>>     So, I now think that ancillary variable dimensions should be a
>>>     subset
>>>     of their asssociated data variable dimensions (which includes the
>>>     possibility of ancillary variables have no dimensions). Perhaps, in
>>>     the new year, ticket #98 could be reopened as an enhancement ...
>>>
>>>     All the best,
>>>
>>>     David
>>>
>>>
>>>     ---- Original message from Karl Taylor (01PM 21 Dec 15)
>>>
>>>     > Date: Mon, 21 Dec 2015 13:59:33 -0800
>>>     > From: Karl Taylor <taylor13 at llnl.gov <mailto:taylor13 at llnl.gov>>
>>>     > To: cf-metadata at cgd.ucar.edu <mailto:cf-metadata at cgd.ucar.edu>
>>>     > Subject: Re: [CF-metadata] [CF Metadata] Question about ancillary
>>>     >  variables/formula terms variables
>>>     > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0)
>>>     >  Gecko/20100101 Thunderbird/38.4.0
>>>     >
>>>     > Hi David,
>>>     >
>>>     > I can't think of anyone needing these constructs, although
>>>     there are
>>>     > cases when both the "parent" and ancillary or formula_terms
>>>     variable
>>>     > might *both* have a scalar dimension.
>>>     >
>>>     > Karl
>>>     >
>>>     > On 12/21/15 7:41 AM, David Hassell wrote:
>>>     > >Hello,
>>>     > >
>>>     > >I was wondering if anyone has ever had use for an ancillary
>>>     variable
>>>     > >(or data variable pointed to from a formula_terms attribute),
>>>     having a
>>>     > >size 1 dimension which the "parent" field does *not* have. The
>>>     > >convention do not say anything about this.
>>>     > >
>>>     > >For example:
>>>     > >
>>>     > >   dimensions:
>>>     > >     t = 1;
>>>     > >     x = 96;
>>>     > >     y = 73;
>>>     > >   variables:
>>>     > >     float q(x, y) ;
>>>     > >       q:standard_name = "specific_humidity" ;
>>>     > >       q:units = "g/g" ;
>>>     > >       q:ancillary_variables = "q_error_limit" ;
>>>     > >     float q_error_limit(t, x, y)
>>>     > >       q_error_limit:standard_name = "specific_humidity
>>>     standard_error" ;
>>>     > >       q_error_limit:units = "g/g" ;
>>>     > >Similary for a scalar coordinate variable, which is logically
>>>     > >equivalent to the size 1 dimension case (this time shown on a
>>>     formula
>>>     > >terms variable):
>>>     > >   dimensions:
>>>     > >     x = 96;
>>>     > >     y = 73;
>>>     > >     z = 19;
>>>     > >   variables:
>>>     > >     float q(z, x, y) ;
>>>     > >       q:standard_name = "specific_humidity" ;
>>>     > >       q:units = "g/g" ;
>>>     > >     float z(z):
>>>     > >       z:standard_name = "atmosphere_hybrid_height_coordinate";
>>>     > >       z.formula_terms = "a: var1 b: var2 orog: var3"
>>>     > >
>>>     > >     float var3(x, y):
>>>     > >       time:coordinates = "time";
>>>     > >
>>>     > >     float time:
>>>     > >       time:standard_name = "time";
>>>     > >       time:units = "days since 2000-12-1";
>>>     > >
>>>     > >Thanks for your help,
>>>     > >
>>>     > >All the best,
>>>     > >
>>>     > >David
>>>     > >
>>>     > >
>>>     > >--
>>>     > >David Hassell
>>>     > >National Centre for Atmospheric Science (NCAS)
>>>     > >Department of Meteorology, University of Reading,
>>>     > >Earley Gate, PO Box 243,
>>>     > >Reading RG6 6BB, U.K.
>>>     > >
>>>     > >Tel   : +44 118 3785613
>>>     > >E-mail: d.c.hassell at reading.ac.uk
>>>     <mailto:d.c.hassell at reading.ac.uk>
>>>     > >_______________________________________________
>>>     > >CF-metadata mailing list
>>>     > >CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
>>>     > >http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>>     >
>>>     > _______________________________________________
>>>     > CF-metadata mailing list
>>>     > CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
>>>     > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>>
>>>
>>>     --
>>>     David Hassell
>>>     National Centre for Atmospheric Science (NCAS)
>>>     Department of Meteorology, University of Reading,
>>>     Earley Gate, PO Box 243,
>>>     Reading RG6 6BB, U.K.
>>>
>>>     Tel   : +44 118 3785613 <tel:%2B44%20118%203785613>
>>>     E-mail: d.c.hassell at reading.ac.uk <mailto:d.c.hassell at reading.ac.uk>
>>>     _______________________________________________
>>>     CF-metadata mailing list
>>>     CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
>>>     http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> CF-metadata mailing list
>>> CF-metadata at cgd.ucar.edu
>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>
>>
>>
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
> -- 
> CICS-NC <http://www.cicsnc.org/> Visit us on
> Facebook <http://www.facebook.com/cicsnc> 	*Jim Biard*
> *Research Scholar*
> Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
> North Carolina State University <http://ncsu.edu/>
> NOAA National Centers for Environmental Information 
> <http://ncdc.noaa.gov/>
> /formerly NOAA’s National Climatic Data Center/
> 151 Patton Ave, Asheville, NC 28801
> e: jbiard at cicsnc.org <mailto:jbiard at cicsnc.org>
> o: +1 828 271 4900
>
> /Connect with us on Facebook for climate 
> <https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics 
> <https://www.facebook.com/NOAANCEIoceangeo> information, and follow us 
> on Twitter at @NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> 
> and @NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. /
>
>
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20151222/5d624e3f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 15784 bytes
Desc: not available
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20151222/5d624e3f/attachment-0001.png>


More information about the CF-metadata mailing list