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
<[email protected] <mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>>
> To: [email protected] <mailto:[email protected]>
> 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: [email protected]
<mailto:[email protected]>
> >_______________________________________________
> >CF-metadata mailing list
> >[email protected] <mailto:[email protected]>
> >http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
> _______________________________________________
> CF-metadata mailing list
> [email protected] <mailto:[email protected]>
> 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: [email protected] <mailto:[email protected]>
_______________________________________________
CF-metadata mailing list
[email protected] <mailto:[email protected]>
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
