⇐ ⇒

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

From: Jennifer M. Adams <jma>
Date: Wed, 1 Nov 2006 09:50:13 -0500

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://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20061101/880ba984/attachment-0002.html>
Received on Wed Nov 01 2006 - 07:50:13 GMT

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

⇐ ⇒