On Mar 16, 2010, at 5:30 PM, John Caron wrote:
> Hi Jennifer, in this instance, how do you know its an ensemble
> dimension, as opposed to say, a wavelength ? is it
>
> ens:long_name = "ensemble member"
>
Grads knows it's an ensemble by the attribute:
ens:grads_dim = "e" ;
I could just as easily look for the axis="E" attribute, since I also
look at the axis attribute to find X, Y, Z, or T.
If the E dimension were used for wavelength, then it would have a
different long name but the same grads_dim='e' attribute.
--Jennifer
> ??
>
> On 3/16/2010 12:36 PM, Jennifer Adams wrote:
>>
>> In the absence of a standard, I have also made some choices about
>> how to handle ensemble metadata with GrADS and the GDS. Below is a
>> shortened example of the ncdump output from a GFS ensemble data set
>> behind GDS. I put the metadata that GrADS needs in customized
>> attributes (e.g. grads_name, grads_dim, etc.) I steered clear of
>> using data or coordinate variables of type 'char', because I feel
>> attributes are the better place for this kind of metadata, and
>> GrADS and the GDS have no interface for handing data variables that
>> are not numeric. I have always assumed it would be necessary to add
>> more metadata to make this data set CF compliant, but in the
>> meanwhile, the ensemble axis is a plain old linear dimension. --
>> Jennifer
>> --
>> Jennifer M. Adams
>> IGES/COLA
>> 4041 Powder Mill Road, Suite 302
>> Calverton, MD 20705
>> jma at cola.iges.org
>>
>>
>>
>> # ncdump -c http://monsoondata.org:9090/dods/gfsens/gfsens.2010031612
>> netcdf gfsens {
>> dimensions:
>> ens = 22 ;
>> lat = 181 ;
>> lev = 7 ;
>> lon = 360 ;
>> time = 31 ;
>> variables:
>> double ens(ens) ;
>> ens:grads_name =
>> "avg
>> ,c00
>> ,p01
>> ,p02
>> ,p03
>> ,p04
>> ,p05,p06,p07,p08,p09,p10,p11,p12,p13,p14,p15,p16,p17,p18,p19,p20" ;
>> ens:grads_length =
>> "31,31,31,31,31,31,31,31,31,31,31,31,31,31,31,31,31,31,31,31,31,31" ;
>> ens:grads_tinit =
>> "1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1" ;
>> ens:avg = "unweighted mean of all members" ;
>> ens:c00 = "unperturbed control forecast" ;
>> ens:p01 = "positively perturbed forecast" ;
>> ens:p02 = "positively perturbed forecast" ;
>> <additional attributes snipped>
>> ens:p19= "positively perturbed forecast" ;
>> ens:p20 = "positively perturbed forecast" ;
>> ens:grads_dim = "e" ;
>> ens:grads_size = "22" ;
>> ens:grads_mapping = "null" ;
>> ens:units = "count" ;
>> ens:long_name = "ensemble member" ;
>> double time(time) ;
>> time:grads_dim = "t" ;
>> time:grads_mapping = "linear" ;
>> time:grads_size = "31" ;
>> time:grads_min = "12z16mar2010" ;
>> time:grads_step = "6hr" ;
>> time:units = "days since 1-1-1 00:00:0.0" ;
>> time:long_name = "time" ;
>> time:minimum = "12z16mar2010" ;
>> time:maximum = "00z24mar2010" ;
>> time:resolution = 0.25f ;
>> <other coordinate variables snipped>
>> float t(ens, time, lev, lat, lon) ;
>> t:_FillValue = -9.99e+33f ;
>> t:missing_value = -9.99e+33f ;
>> t:long_name = "temperature [k] " ;
>> <other variables snipped>
>>
>> data:
>>
>> ens = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17,
>> 18, 19, 20,
>> 21, 22 ;
>>
>> time = 733848.5, 733848.75, 733849, 733849.25, 733849.5,
>> 733849.75, 733850,
>> 733850.25, 733850.5, 733850.75, 733851, 733851.25, 733851.5,
>> 733851.75,
>> 733852, 733852.25, 733852.5, 733852.75, 733853, 733853.25,
>> 733853.5,
>> 733853.75, 733854, 733854.25, 733854.5, 733854.75, 733855,
>> 733855.25,
>> 733855.5, 733855.75, 733856 ;
>>
>> }
>>
>>
>>
>> On Mar 16, 2010, at 1:22 PM, Jonathan Gregory wrote:
>>
>>> Dear John
>>>
>>>> Im not sure if we ever converged on how to write ensemble files.
>>> No, we didn't. If I remember correctly, we couldn't agree on the
>>> relationship
>>> between attributes and coordinates, and that was a sticking-point.
>>> I thought
>>> that we ought to allow multivalued auxiliary coord variables for
>>> ensemble
>>> axes, corresponding to attributes that might be used to describe a
>>> single
>>> model. I would give these standard_names to identify them. Paco
>>> started the
>>> discussion, and in the end he made his own decisions for what to
>>> do for the
>>> ENSEMBLES project (because CF had not concluded), so he might
>>> comment on it.
>>>
>>>> Particularly, how does software recognize the ensemble dimension?
>>> We didn't agree. But at the end of the discussion, Steve also
>>> suggested that
>>> it could be identified by an axis attribute, just as you have. I
>>> like that
>>> idea too. But it could also be given a standard name, like other
>>> coordinate
>>> variables e.g. ensemble_member_identifier. I suppose the values of
>>> this
>>> coord var might be either numeric or strings, though it your
>>> example it is
>>> integer. I haven't looked at the trac ticket to see if we
>>> discussed these
>>> points before.
>>>
>>>> Perhaps we should add :axis = "Ensemble" to the model coordinate
>>>> variable?
>>> I'd suggest lower case, like most CF keywords. The other axis
>>> attributes are
>>> all single letters (X Y Z T) but I don't think it would be a
>>> problem to use
>>> a word.
>>>
>>> Best wishes
>>>
>>> Jonathan
>>> _______________________________________________
>>> 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
>>
>
--
Jennifer M. Adams
IGES/COLA
4041 Powder Mill Road, Suite 302
Calverton, MD 20705
jma at cola.iges.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20100316/5361793d/attachment-0002.html>
Received on Tue Mar 16 2010 - 18:27:11 GMT
