[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: problems with NUWG conventions (fwd)


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

---------- Forwarded message ----------
Date: Fri, 17 Dec 1999 10:49:04 -0700
From: Russ Rew <address@hidden>
To: John Caron <address@hidden>
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