This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
=============================================================================== 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