Re: problems with NUWG conventions (fwd)

• To: bit-bucket <bit-bucket@xxxxxxxxxxxxxxxx>
• Subject: Re: problems with NUWG conventions (fwd)
• From: Robb Kambic <rkambic@xxxxxxxxxxxxxxxx>
• Date: Fri, 17 Dec 1999 10:58:26 -0700 (MST)

==============================================================================
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>

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

 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

 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

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 */

 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