[GEMPAK #DNO-406029]: dcgrib2 accuracy and dcgrib not working with latest gdpoint

David,

The dcgrib program unpacks all GRIB messages (in the old gribtonc code), and 
then
depending on whether you want to store the data as "PACKED", will repack the 
data.
Here the number of bits needed to store the data is re-computed, taking in to
account that the missing data value is not -9999, and not within the range of 
data
expresed by the scale/offset/precision of the original grib data. 

The dcgrib2 program is using the nagrib guts (so you should be able to verify 
that
the same behavior you see in dcgrib2 also exists in nagrib- which it does by my 
tests
as the routine in question is GB_GUBD), which tries to avoid unpacking the grib 
if it 
doesn't have to- and just store the data block of the grid internally in the 
GEMPAK file. 
In this case of the NAM104 data though, the GRIB does use a bit mask section, 
so the data 
is unpacked, expanded according to the missing value bit mask, and the missing 
value is 
being replaced by the -.01 value as specified in the wmogribx.tbl file.

Now the data must be repacked for filing. When -9999.00 is the missing value,
the number of bits is increased by one (in GB_GUBD) and the max value is then 
the -9999 flag.
The problem lies in the fact that the missing value is not -9999, and not 
within the range of
data being expressed in the original GRIB scale/offset/precision. The new data 
range is computed,
but the number of packing bits is still the same as was in the GRIB data- that 
is your
cause for the loss in accuracy / precision in data representation.

The immediate change should be to replace -0.01 in the $GEMTBL/grid/ tables 
with the
value 0. That avoids this precision problem as "0" is in the valid range of 
precip data. 
Also, as you see in your data output, GEMPAK has to calculate the precipitation 
accumulations from
the P03M, P06M, P09M and P12M, so avoiding that -0.01 value will prevent the 
value from
showing an unexpected decrease. I'll ask NCEP regarding GB_GUBD as to why -.01 
was
used (I suspect for contouring needs at one time).

Since these accumulations rely on grid point math for intermediate times, the 
missing
value should not be -9999.00 since it would flag the point as missing, rather 
than
no accumulation- which would eliminate the point from any calculations.

As for the help screen documentation of "-m", that is the boiler plate DECODER 
OPTIONS
section from $GEMHLP/hlp/decode.hlp that is tacked on to all dc program help.
I've overloaded the meaning of -m in the dcgrib2 decoder according to the lines 
above the
decoder options:
-    Valid command line options for DCGRIB2 are:
-  
-        -v N, -m maxgrids, -d logfile, -t timeout, -h show help, -e PARM=value
-
-    Other DC decoder options are ignored.

I could use another letter, or bypass the GEMPAK help otherwise.

Steve Chiswell
Unidata User Support






Ticket Details
===================
Ticket ID: DNO-406029
Department: Support GEMPAK
Priority: Normal
Status: Closed