[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GEMPAK #PUL-762311]: dcgrib2 problem

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.

  • Subject: [GEMPAK #PUL-762311]: dcgrib2 problem
  • Date: Wed, 19 Jul 2006 09:58:44 -0600
Brian,

I redownloaded your file and ran:
% cat wrfprs_ruc13_03.tm00 | dcgrib2 -v 1 -d - YYYYMMDDHH_fsl.gem
There was one grid in your grib file for April 23, 2006 (aka surface hght). That
was the very last grib product in your file (either your output was appended at
that point, or your last product was coded for that date/time incorrectly).
That information comes from the PDS block of the GRIB product.

If you decoded your data to a single file, then GDATTIM=last will find that 
April 23
date as the most recent in the file since it is later than the 2005 date.

If you use the file name templates as I did above, you will get 2 output files:

2005072112_fsl.gem  2006042312_fsl.gem

Now, using gdattim=last on the 2005072112_fsl.gem will July 21, 2005 f003 data.

Basically, the decoder is behaving properly, as is gdinfo. You just need to 
identify the source
of your April 23, 2006 grid.

Steve Chiswell
Unidata User SUpport


> Hi Steve,
> 
> I think I've narrowed the problem down to the setting of GDATTIM.
> Previously, I was using GDATTIM=last, and for some reason, GEMPAK
> thinks the file is from April 23, 2006 (from one line that is
> displayed using
> GDINFO).  The file is really from July 21, 2005, and when I set
> GDATTIM=050721/1200F003, then I can see all the fields when I use
> GDINFO.
> 
> Can you tell me what exactly GEMPAK looks at for the date and time
> when GDATTIM=last?
> 
> Brian
> 
> On Jul 17, 2006, at 3:02 PM, Unidata GEMPAK Support wrote:
> 
> > Brian,
> >
> > This grid size (151,987) is well within the 750,000 defined size.
> > The data in the file posted below is grib1, with 330 fields for
> > 2005072112F003. I was able to decode it both with dcgrib2 as well
> > as nagrib.
> > Have you tried nagrib?
> >
> > I don't know what trouble you are having, so can't give you any
> > other advice at this time.
> >
> > Steve Chiswell
> > Unidata User Support
> >
> >
> >> Hi Steve!
> >>
> >> I tried to use dcgrib2 on a grib file for a RUC 13 km output file and
> >> it doesn't seem to be working properly.  Perhaps it is the grid size
> >> (451 X 337)?  I'm not sure.  I have an example file that can be
> >> downloaded to test in http://www-frd.fsl.noaa.gov/mab/jamison/test/ .
> >>
> >> Would it be possible to get  a newer version of dcgrib2 that can
> >> decode this file?
> >>
> >> Please let me know.  Thanks!
> >>
> >>
> >> Brian Jamison
> >>
> >>
> >>
> >>
> >> Hi Steve!
> >>
> >> I tried to use dcgrib2 on a grib file for a RUC 13 km output file and
> >> it doesn't seem to be working properly.  Perhaps it is the grid size
> >> (451 X 337)?  I'm not sure.  I have an example file that can be
> >> downloaded to test in http://www-frd.fsl.noaa.gov/mab/jamison/test/ .
> >>
> >> Would it be possible to get  a newer version of dcgrib2 that can
> >> decode this file?
> >>
> >> Please let me know.  Thanks!
> >>
> >>
> >> Brian Jamison
> >>
> >>
> >>
> >>
> >
> >
> > Ticket Details
> > ===================
> > Ticket ID: PUL-762311
> > Department: Support GEMPAK
> > Priority: Normal
> > Status: Closed
> >
> 
> 


Ticket Details
===================
Ticket ID: PUL-762311
Department: Support GEMPAK
Priority: Normal
Status: Closed