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 <taylo...@llnl.gov> > To: cf-metadata@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.hass...@reading.ac.uk > >_______________________________________________ > >CF-metadata mailing list > >CF-metadata@cgd.ucar.edu > >http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > _______________________________________________ > CF-metadata mailing list > CF-metadata@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.hass...@reading.ac.uk _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
