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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20151222/566a3245/attachment-0001.html>
Received on Tue Dec 22 2015 - 10:07:53 GMT
