[GEMPAK #JZS-437384]: Mysterious dcgrib behavior

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