[CF-metadata] CF and multi-forecast system ensemble data

[Jennifer M. Adams]

Hi, Everyone --
The discussion of ensemble metadata is extremely topical for our tiny  
team of GrADS/GDS developers at COLA. We are adding a fifth dimension  
to the the GrADS gridded data model in order to treat a group of  
ensembles (realizations) as a single data set. Conceptually, it's not  
a big leap forward, you slice and dice and average over the E  
dimension the same way you would over X, Y, Z, or T. The time axis  
will remain a linear, 1-dimensional coordinate -- forecast times that  
are expressed as an offset from an initial time will be handled  
through expression evaluation, resolving to an absolute time before  
the I/O request. A complete 5D data set could be a single file, but  
more likely will be an aggregation of files, with aggregation  
supported over T (as it is in the current version of GrADS) and E,  
but not X, Y, or Z. All ensemble members must share a common grid,  
although individual members may have different start times and  
lengths. Ensembles are identified with consecutive integers beginning  
with 1, but may also be given names.

The tricky part is when we plop that 5D data set (GrADS descriptor  
file and multiple data files) behind GDS and serve it as a CF- 
compliant NetCDF file to the world of OPeNDAP clients. Of course, our  
primary concern is that GrADS will work as a client, which means  
we're using NetCDF version 3 (and 2). The ensemble metadata that  
GrADS requires (index, name, start time, length, and maybe weight)  
must be presented in a NetCDF context in such a way that GrADS can  
get it back into its internal data structures the same way it does  
when it parses a descriptor file. As Bryan pointed out, the E axis is  
a "special" dimension that requires extra attributes over and above  
what's traditionally presented with coordinate dimensions. A 15- 
character 'name' obviously won't be adequate to completely describe  
all the characteristics of an ensemble member.  However, I don't  
believe this problem is as tricky as all the email it has generated  
would lead us to believe.

Jennifer

--
Jennifer M. Adams
IGES/COLA
4041 Powder Mill Road, Suite 302
Beltsville, MD 20705
jma at cola.iges.org



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.cgd.ucar.edu/pipermail/cf-metadata/attachments/20061101/880ba984/attachment.html