Re: problems with NUWG conventions (fwd)

NOTE: The decoders mailing list is no longer active. The list archives are made available for historical reasons.



==============================================================================
Robb Kambic                                Unidata Program Center
Software Engineer III                      Univ. Corp for Atmospheric Research
rkambic@xxxxxxxxxxxxxxxx                   WWW: http://www.unidata.ucar.edu/
==============================================================================

---------- Forwarded message ----------
Date: Fri, 17 Dec 1999 10:49:04 -0700
From: Russ Rew <russ@xxxxxxxxxxxxxxxx>
To: John Caron <caron@xxxxxxxxxxxxxxxx>
Subject: Re: problems with NUWG conventions
John,

1) the x and y dimensions can be identified using the "nav" attributes,
for example in the ngm-q datasets:
        char x_dim(nav,nav_len);

which is set to the value of "x", meaning that x is the coord variable
for the x dimension.

(as an aside, this would be simpler using  a global attribute, e.g.
        :x_dim = "x"; )

Global attributes were rejected because of the perceived need to
represent multiple navigations in a single dataset, for example if
multiple grids were stored on a moving coordinate system that was
centered on a tropical storm.  In this case, each value of the "nav"
dimension represents a different set of navigation parameters.
A variable that makes use of the second navigation, for example, would
specify this with its navigation attribute, e.g.
 T_trop:navigation="nav[1]";

(or nav(2), using the convention that 0-based indices use "[]" and
1-based indices use "()").

... however in the ecmwf dataset, there is no x_dim attribute, instead
theres an "i_dim" attribute:

Name___________Value_____________________Description
i_dim          lon                 longitude dimension name
j_dim          lat                 latitude dimension name

The use of "x_dim" or "i_dim" is taken directly from the GRIB1
standard, where parameterizations depending on "i" and "j" were used
for simple lat/lon grids, but "x" and "y" were used for projected
grids, e.g. Lambert Conformal.  So in ~ldm/etc/*.cdl, the following
model output use "i" and "j":

 ngm-g, avn-a, avn-x, ecmf, sst-a, sst-t, sno, avn-1.25x1.25, ocean,
 mrf-a, mrf-e

but the following model grids use "x" and "y":

 avn-q, eta, ngm-q, ruc, ruc

3) the problem with the z coordinate is much worse. If you look at the
attached netcdf dump for the ngm-q dataset, you will find 6 different z
coords (fh, level, level_o, level_c, sigma, soillevel) with units
('meters', 'hectopascals', 'hectopascals', 'hectopascals', '', <none>)
respectively.

Although NUWG wouldn't standardize on name conventions, we decided it
would help to use naming conventions for level variables.  There are
48 different kinds of levels defined by GRIB1, see
 file:/upc/share/decoders/src/gribtonc/levels.h

We adopted variable suffixes for these, so for example T_sfc
represents T at the surface.  See

 file:/upc/share/decoders/src/gribtonc/levels.c

for the variable suffixes.
The suffixes are also used as dimension names for the corresponding z
dimensions, when they exist.  So, for example,

 T_lpdg(record, lpdg, y, x)

represents T in the boundary layer, because the lpdg suffix is defined
as:

 /* layer between levels at specif. pressure diffs from ground */

More similar extensions to the NUWG conventions are in
 file:/upc/share/decoders/src/gribtonc/nuwg.h

and

 file:/upc/share/decoders/src/gribtonc/nuwg.c

spelling out specific names for dimensions and variables in our
decoded grids.

You're right, there should be a decoders document specifying all this
clearly.  The bottom line is that the GRIB conventions were used where
there was no good reason to change them.

--Russ


  • 1999 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the decoders archives: