20000508: 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,

I have had a go round with Chad Johnson of SSEC about the modifications
that Owen and I made to the gbtbpds001.2vx files being used by
gribdec.k in the conversion of Specific Humidity (SHUM) grib messages
you got from NCAR to McIDAS GRID files.

I asked Chad whether he thought that changing the scale factors in
gbtbpds001.2vx was the correct way to "solve" the decoding problem.  He
said that he did _not_ think so.  Instead, he ventured that the unit of
the grid stored in the McIDAS GRID file should be KGKG instead of
GPKG.

Chad also asked if 2 digits of precision was enough in the SHUM values
to which I said no (following Owen's recommendations).

Chad's comments indicated that the scale factor number in
gbtbpds001.2vx should be the precision of the values decoded from the
grib messages and stored in McIDAS GRID files.  This follows my
original thinking.  What it does not explain, however, is how increasing
this number from 2 to 5 changed the values of the field by a factor of
1000.

In order to get to the bottom of what is _really_ going on, I promised
Chad that I would run a couple of more tests on the data that you are
looking at.  The easiest way for me to do this is to get the mccode
login and be reminded of the location of the input grib and output GRID
files.  Can you provide me these?  What I will do is:

o change the scale factor in gbtbpds001.2vx back to 2
o change the output unit to KGKG
o verify that the decoded values look correct

I will then experiment (again) with changing the scale factor and see
if it can be made to simply change the precision of the values being
decoded, and report my findings back to Chad.

Thanks in advance for the access information...

By the way, on the "bad news" front: Chad is leaving SSEC for greener
pastures at the end of this month.  This leaves a _big_ hole in their
XCD development/support group (which was Chad) and in things related to
the LDM (like the IDD ingection of NOAAPORT TG (conventional and model
output) data AND the Unidata-Wisconsin datastream products).  You
probably saw the SSEC job announcement that we forwarded to our
community last week.  This is for Chad's replacement.

Tom