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>
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>
> > To: 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
> > >_______________________________________________
> > >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
>
>
> --
> 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
> _______________________________________________
> 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/53f729ed/attachment.html>
Received on Tue Dec 22 2015 - 09:39:26 GMT
