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.
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