Jennifer,
I'm glad you find the whole issue easier than what has been expressed in
the recent emails. I can't be that optimistic, but I'm sure it has to do
with my lack of experience ;)
One of the limitations we found with GDS is the restriction to 4
dimensions. As an example to help discuss your point about the 5D data
set, I created a file with five dimensions containing monthly mean
geopotential for two isobaric levels from multi-model ensemble
forecasts. The file contains 9-member 6-month long ensemble (tagged
starting from number 0) forecasts from two different forecast systems
(GloSea, from the Met Office and the ECMWF seasonal forecast system)
initialized on the 1st of February for the years 2000 and 2001. Time is
a 1-dimensional coordinate. The metadata try to comply with some of the
discussions we've recently had. It would be really useful if you (and/or
others) can take a critical look at the file from the perspective of the
dissemination with GDS or TDS. The file (17Mb) is available from
http://www.ecmwf.int/staff/paco_doblas/MM_129_mon.nc
Best regards,
Paco
Jennifer M. Adams wrote:
> 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 <mailto:jma at cola.iges.org>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
________________________________________
Francisco J. Doblas-Reyes
European Centre for Medium-Range
Weather Forecasting (ECMWF)
Shinfield Park, RG2 9AX
Reading, UK
Tel: +44 (0)118 9499 655
Fax: +44 (0)118 9869 450
f.doblas-reyes at ecmwf.int
_______________________________________
Received on Wed Nov 01 2006 - 10:44:23 GMT
