Re: Grid netCDF Conventions

Hi Peggy,

I think you have summed up the Gridded NUWG work well. There are a few
explanations (and an excuse or two) that I should add:

>1) Jeff uses an attribute called "z_dim" to describe the vertical 
>coordinate for each variable.  I think the reasoning behind this
>was to support hybrid levels (?):
>
>       float cp(record, z, x, y);
>            cp:record_dim = "valtime, reftime";
>            cp:_Navigation_var = "nav";
>            cp:z_dim = "vpt, p";
>            cp:long_name = "condensation pressure";
>            cp:units = "pascals";
>            cp:valid_range = 100.f, 600.f;
>            cp:_FillValue = -9999.f;
>
>The Unidata CDL's have implemented a different philosophy in order
>to support multiple vertical coordinates in the same data file:
>
>    float   RH(record, level, y, x) ;
>                RH:long_name = "relative humidity" ;
>                RH:units = "percent" ;
>                RH:valid_range = -10.f, 110.f ;
>                RH:_FillValue = -9999.f ;
>                RH:navigation_dim = "nav" ;
>
>    float   v-bndry(record, bndry, y, x) ;
>                v-bndry:long_name = "v-component of wind in boundary layer" ;
>                v-bndry:units = "meters/second" ;
>                v-bndry:valid_range =  -200.f, 200.f ;
>                v-bndry:_FillValue = -9999.f ;
>                v-bndry:navigation_dim = "nav" ;
>
>"level" is a variable containing pressure levels, and "bndry" is an index
>into two varibles, bndry_bot and bndry_top.  (Please see the Unidata RUC CDL
>for details).
>
Apples .vs. oranges comparison here.

Your technique works for RUC that has been interpolated to isobaric
levels. We do the same thing with isobaric levels. I remember this as the
convention for fixed levels. 

It doesn't work for Hybrid-B levels used within FSL. Hybrid-B was a "worst 
case" scenerio where the vertical dimension was dependent on the values of 
other model variables. When we were working on the conventions I presented 
Hybrid-B as an example of using attributes to describe the meaning (or
interpretation) of a dimension.

I don't think that NMC will be distributing RUC Hybrid-B data operationally
for some time. At least I haven't heard of any plans to do that. Some of the 
folks at FSL use Hybrid-B RUC received from NMC but that is a different
animal (or fruit) from the AWIPS RUC that Unidata is storing (use Peggy's
CDL for AWIPS RUC).

>2) There is a significant difference between Jeff's CDL and Unidata's
>CDL represents the navigation information.  I think I remember the 
>NUWG group deciding on a using a suite of navigation variables, rather
>than one "nav" variable with lots of attributes.  Jeff, do you remember
>differently?

As I recall it there was considerable philosophical evolution occuring
in relation to grid navigation while we were meeting. I think your
"multiple variable" approach was the one we finally developed a consensus
on.

Unfortunately, I was developing gridded netCDF storage programs to meet
some tight deadlines. I developed some software philosophy during an 
intermediate evolutionary phase. My "missing link" navigation should be
corrected. With the best intentions of going back and fixing things 
later... here we are. I like your technique better. I think it is the 
conventional method that we agreed upon.

>All interested parties should take a look at both 
>representations.  (Note that the current GEMPAK-netCDF requires
>a varible that contains a unique "GRIB-1 catalogued grid number".
>The name of the variable, grid_number in our CDL, can be anything,
>but I must have some number to index into my table of grid navigations.)
>
>Is it time to all get together and discuss these final issues?
>
Soon I hope. It's long overdue.

>Also, is it time to start thinking about a set of conventions for
>satellite or radar data?
>
We do need to get moving again.

Best regards,

Jeff