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 _at_NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and
_at_NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. /
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20151222/2c22452e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CicsLogoTiny.png
Type: image/png
Size: 15784 bytes
Desc: not available
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20151222/2c22452e/attachment-0001.png>
Received on Tue Dec 22 2015 - 10:10:43 GMT
