20000511: gribdec.k not properly decoding specific humidty in NCAR grib files (cont.)

>From: "Jennie L. Moody" <address@hidden>
>Organization: UVa
>Keywords: 200004270006.e3R06rG00226 McIDAS-X -XCD gribdec.k gbtbpds001.2vx

Owen and Jennie,

Here is some closure on the gribdec.k decode of SHUM values from NCAR
grib messages:

>From address@hidden Wed May 10 15:47:17 2000
>Subject: Re: 20000508: XCD decoding of specific humidity from NCAR grib files 
>(cont.)

>Tom,

>Yep....your right. In Mcmkmcgrid.c, the scale factor in the grid header
>is always set to 2. Yet...each grid point is scaled by the factor
>defined in gbtbpds001.2vx. My first reaction was 'this is unbelievably
>wrong'. If one is going to scale the grid point by one factor one
>should store that scale factor in the McIDAS grid header.
>Right?...Wrong. If you look at the gbtbpds001.2vx files, you will
>notice that most of the scale values are set to '2'. But if you look at
>the pressure fields and the absolute vorticity fields, these are set
>differently. Let's focus on the pressure field. The unit as stored in
>the McIDAS grid file is millibars and the scale factor is set to 0 - no
>scaling. This seems odd, but if you look at Office Note 388, this
>parameter is stored in the GRIB file as 'Pa'. This effectively presents
>the raw GRIB value, which is in 'Pa' as 'hPa'. 'hPa' is equal to 'MB'
>and 'MB' is the unit stored in the McIDAS grid header. The raw 'Pa'
>value is not scaled in the grid file, but the client divides the value
>by 100 (scale factor 2) to get MB. Yuck!!!

>I would love to store the values in the McIDAS grid files in their
>original units, then scale them appropriately to save the precision
>necessary.  Unfortunately nothing is ever that easy in McIDAS. For
>example, if I stored the pressure field in 'Pa', this would require
>everybody to add the UNIT=MB clause to every GRDDISP pressure field
>request to plot MB. Otherwise they would see pressure contour lines
>like 100400 Pa rather than 1004 hPa or MB.

 >> The only reason that leaving the output unit as GPKG and changing the
 >> scale factor from 2 to 5 (i.e,, 10**2 to 10**5) worked for us is that
 >> we were exploiting an apparent bug in dmgrid.k/gribdec.k that does not
 >> write the gbtbpds001.2vx scale factor to the output grid header.

>Based on the above observation I don't think we have no choice. It
>looks like the decoder was designed this way. I retract my previous
>suggestion and suggest you keep the unit as GPKG and change the scale
>factor from 2 to 5. At the time, I didn't realize the decoder always
>stored a scale factor of 2 in the grid header, and apparently for a
>reason.

>I may not have explained myself very well. If you are confused, give me
>a call.

>-Chad

So, it looks like Owen and I did the exact right thing given the design
of the McIDAS grib decoder (gribdec.k and dmgrid.k run the same code
so they are equivalent).  I would say, however, that the decoder needs
to be modified so that the number of significant digits can be specified
independently in the gbtbpds001.2vx files.  I am afraid that this has no
chance of being even considered given that Chad is leaving SSEC at the
end of the month.

Just thought that you would want to know...

Tom