Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Kevin, The most recent version of dcgrib2 (5.9.3) will store the GRIB2 data in the grid file without unpacking the data block, making the GEMPAK file much smaller, and the decoding process much faster. The older GEMPAK distributions will not be able to read those decoded files however, since they do not know how to unpack the GRIB2 data block, so if you use the 5.9.3 decoder, you would want to upgrade the other programs as well, or recompile the dcgrib2 program from 5.9.3 to use the previous packing method for the data- but you may find that unpacking and repacking the data in realtime is quite a load on the LDM pqact processing (otherwise, you can use nagrib2 outside of the LDM which will be compatible with the previous versions). I'll add a command line flag to the 5.9.4 dcgrib2 to allow you to select the storage method for backward compatibility. Steve Chiswell Unidata User Support On Tue, 2006-10-10 at 01:24 -0600, Kevin R. Tyle wrote:
Hi Steve, Thanks for the updated files. I can now get it to work using the GEMPAK5.9.3 version of dcgrib2 using the corrected tables. However, even with the updated tables, versions 5.9.1 and 5.7.4 of dcgrib2 still do not decode. Perhaps I shall just recompile dcgrib2 for use in these two distributions (which are still in operational use here) unless you have another idea. Thanks, Kevin
gembud archives: