⇐ ⇒

[CF-metadata] ensemble dimension

From: Jennifer Adams <jma>
Date: Tue, 16 Mar 2010 14:36:03 -0400

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20100316/dbc32b62/attachment-0002.html>
Received on Tue Mar 16 2010 - 12:36:03 GMT

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:41 BST

⇐ ⇒