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
Received on Tue Dec 22 2015 - 04:07:10 GMT
