Paco, et al.,
The sample netcdf file is extremely informative. From a developer's
point of view, it's helpful to see how users would want to exploit
the 5th dimension capability. The variables experiment_ID, source,
originating_center, and number are exactly the way I would want them
to be: arrays of strings that provide meaningful metadata for each
ensemble member, but that don't add dimensions to the data variable.
I would rearrange the time metadata in your file like this:
1. The absolute time axis ("time") has to span all the ensemble
members -- thus it should have 18 time steps, beginning 1feb2000,
incremented by 1 month. I know this leads to a lot of missing data,
but in the GrADS/GDS environment, time is incompressible and the 18
members must all fit into the 5D grid. I noted that you didn't
actually provide any axis values for your "time" dimension, but if
that is the dimension for your data variable, it ought to be
explicitly defined.
2. The variable you call "reftime" is what we think of as the initial
time of each ensemble -- exact naming of this to be determined by CF
consensus. This variable should have dimension "ensemble" not "time"
with the first 9 values referring to 1feb2000 and the 2nd 9 values
referring to 1feb2001.
3. A new variable, called something like "ensemble_length" (once
again, I defer to CF lexicon) has dimension "ensemble" and gives the
number of time steps in each ensemble, in this case all elements will
have a value of 6.
4. I'm not sure what the variable time_bnd is used for.
Jennifer
On Nov 1, 2006, at 12:44 PM, Francisco Doblas-Reyes wrote:
> 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
> _______________________________________
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
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/d581053b/attachment-0002.html>
Received on Wed Nov 01 2006 - 13:54:20 GMT
