[GEMPAK #PUL-762311]: dcgrib2 problem

> Steve,
> 
> Thank you so much for your detective work!  I forwarded your message
> to the person doing the post-processing that creates the GRIB files, and
> the surface elevation field was added after the other fields were
> processed
> (the idea being that computation time is faster by adding the field,
> in that
> it is unchanging).

They should still change the PDS in the file to set the correct date
in the grib message even if the data in the grid doesn't change.
That would be a couple of bytes to write.


> 
> I was able to split the output into two files as you suggested.  I
> tried to
> use this file separately in GDCROSS to plot the terrain, but I can't
> seem to get it to work.  Is it possible to use this surface elevation
> file
> in GDCROSS, even though it contains only one level?

You can use GDDAIG to create a new surface hght grid with the correct time
from the other file. You can simply set:
GFUNC  = hght
GVCORD = none
GLEVEL = 0
GDATTIM = 060423/1200f000

and then give the appropriate time for your other data in GRDNAM such as:
GRDNAM = hght^050721/1200F003

Set GDOUTF for your July 2005 file and GDFILE for your input file.

Steve Chiswell
Unidata User Support


> 
> Brian
> 
> 
> On Jul 19, 2006, at 9:58 AM, Unidata GEMPAK Support wrote:
> 
> > 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
> >
> 
> 


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