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.
Tom, I'm not sure why the -h and -d options would not work on your system, but my build -h will print the man file, which is also located at http://www.unidata.ucar.edu/cgi-bin/gempak/manual/decoders_index?dcgrib2 while -d allows you to write to a log file. To use specific table path use the "-e GEMTBL=path" option, otherwise, the following tables files are expected to be found: $GEMTBL/grid/cntrgrib[X].tbl $GEMTBL/grid/vcrdgrib[X].tbl $GEMTBL/grid/wmogrib[X].tbl $GEMTBL/grid/[CENTER]grib[X].tbl $GEMTBL/grid/dcgrib.tbl $GEMTBL/grid/gribkey.tbl Michael James Unidata User Support > Thanks! dcgrib2 works fine. > > I notice that dcgrib2 doesn't have a '-h' option (to print help info), > and it appears that dcgrib2, unlike dcgrib, does not support the -d, -g, > -m, and other command-line options. Because we will be triggering > various dcgrib2 conversions simultaneously on multiple threads, it is > important for us to be able to control such params as the output directory. > > Can you tell me what command-line options are supported by dcgrib2? > > Thanks, > Tom Margolis > > Hi Tom, > > > > I've been able to reproduce the truncated gem files using my own build of > > dcgrib (fedora 9 system here). It seems to be a problem with the date/time > > not being written correctly. Rather than offering a solution involving a > > specific build of dcgrib for your system, I'm going to suggest you try > > dcgrib2 instead of dcgrib, log the output, and check the gem file with > > gdinfo. > > > > dcgrib2 -d gem.log out_dcgrib2.gem < in.grb > > > > Please let me know if you have any more questions about this. > > > > Best, > > > > Michael James > > Unidata User Support > > > > > > > >> Hello, > >> > >> Tim Alberta at COMET pointed me your way - perhaps you can shed some > >> light on a problem I'm having with GEMPAK's dcgrib (grib1 -> gempak) > >> converter. > >> > >> Tim provided me with a version of dcgrib built on a Fedora Core system. > >> This produces GEMPAK files (from grib1 files) which are correctly > >> rendered in IDV. However, we need to run dcgrib on a RedHat system - and > >> one of the required Fedora Core libraries (libg2c.so.0) is obsolete and > >> is no longer used on RedHat systems. So we switched to the current > >> gempak/RedHat 64-bit version of dcgrib. > >> > >> When I run the RedHat version of dcgrib - pointing to the same grib1 > >> file, using the same arguments and tables, and so forth - it produces a > >> GEMPAK file which cannot be read by IDV: IDV throws an error. The > >> verbose debugging logs generated by both versions of dcgrib are > >> identical - so the logs don't help. Oddly, the unreadable GEMPAK file > >> produced by RedHat dcgrib is a fraction of the size of the readable file > >> produced by Fedora dcgrib. > >> > >> Attached: > >> in.grb: the input grib file that was converted to gempak on both the > >> Fedora Core and the Redhat systems. > >> out_fedora.gem: the output gempak file, generated on the Fedora Core > >> system, which displays correctly in IDV. > >> out_redhat.gem: the output gempak file, generated on the Redhat > >> system, which is unreadable by IDV. > >> gem.log: the log file generated by dcgrib > >> > >> Command used: > >> /path/to/dcgrib -x -v -d gem.log -m 29999 -g /path/to/grib/tables > >> [output file name].gem < in.grb > >> > >> Thanks, > >> Tom Margolis > >> UCAR > >> > >> > >> > > > > > > Ticket Details > > =================== > > Ticket ID: JZS-437384 > > Department: Support GEMPAK > > Priority: Normal > > Status: Open > > > > Ticket Details =================== Ticket ID: JZS-437384 Department: Support GEMPAK Priority: Normal Status: Open