[GEMPAK #DJN-782698]: RAP decode error

Give me some time today to compile the CONDUIT RAP headers that I have 
documented.  the CONDUIT file docs on our website need updating to reflect the 
RUC/RAP transition and correct some GFS header info as well.  

I will send back a pattern action for the 20km RAP after testing on a couple of 
systems here.

-Michael


> 
> On Feb 22, 2013, at 10:47 AM, Unidata GEMPAK Support wrote:
> 
> > If there are problems both with dcgrib2 handling the RAP and NSHARP 
> > displaying the 20km then it's almost certainly a grib table issue.
> >
> > the DM 0 error reads as "normal return" in the source.  how did you 
> > theorize that it is due to the # grids per file value being too low?
> 
> http://www.unidata.ucar.edu/support/help/MailArchives/gempak/msg02830.html
> "The [DM 0] error means that the maximum number of grids allowed in a 
> particular file needs to be increased."
> 
> >
> > if I understand, you're having problems with the RAP on a 6.2.0 CentOS 
> > 64-bit machine and on a 6.8.0 install as well?  is this a different 
> > machine, and was 6.8.0 installed from source or binary?
> 
> Geez.  I've been all over the map trying to figure this one out.  I started 
> with problems with Gempak 6.2.0, then installed 6.8.0, both on centos 5.8 
> 64-bit and ldm 6.9.2.  Then installed on separate 32 bit hardware centos 6.2, 
> ldm 6.11.3, and Gempak 6.8.0.
> 
> I'd like to start over, at least regarding RAP decoding, with a working pqact 
> entry and any relevant $GEMTBL entries.
> What combo of these is supposed to generate workable .gem files for the 40km 
> and 20km RAP models?
> 
> Donna Cote forwarded my private email to her to the gembud list today asking 
> for the above.  Response was to review:
> http://www.unidata.ucar.edu/mailing_lists/archives/conduit/2012/msg00004.htm
> and go get the latest tar-up of the GEMTBL tree.
> 
> As to the latter, I don't understand a couple items about the RAP ERE in Tom 
> Yoksas' discussion
> New CONDUIT RAP product:
> 
> Feb 28 18:04:19 notifyme[2201] INFO:    21645 20120228180356.764 CONDUIT 000
> data/nccf/com/rap/para/rap.20120228/rap.t12z.awp252pgrbf00.grib2
> !grib2/ncep/RUC2/#000/201202281200F000/HGHT/1000 hPa PRES! 000000
> # This one will match RAP products
> CONDUIT ^data/nccf/com/rap/prod/rapa.(........)/rap.t(..)z.bgrb20.*#000
> There appears to be no 'prod/rapa' character sequence in the product.  
> Neither is there a 'brgb20' associated with the displayed RAP product.
> 
> And BTW, I've forgotten what the '#' means in EREs.
> 
> I would think that 'awp252' is referencing a product from the 20km 252 grid, 
> as the 'awp236' presumably represents the 40km 105 grid.  No?
> 
> Wouldn't it be better to decode per those REs?
> 
> -Neil
> 
> >
> >
> > -Michael
> >
> >> ===
> >> centos 5.8 x86_64
> >> ldm 6.9.2
> >> gempak 6.2.0 with latest tables
> >> ===
> >>
> >> Getting the following in log file:
> >> [30898] 130215/1738[DECODE_GRIB2 -11] S03M [130215/2200F018] 0:-1 NONE 301 
> >> 225
> >> [30898] 130215/1738[DM 0]
> >> [30898] 130215/1738[DECODE_GRIB2 -11] C03M [130215/2200F018] 0:-1 NONE 301 
> >> 225
> >> [30898] 130215/1738[DM 0]
> >> [30898] 130215/1738[DECODE_GRIB2 -11] SWEM03 [130215/2200F018] 0:-1 NONE 
> >> 301 225
> >> …
> >>
> >> using this pqact entry:
> >>
> >> CONDUIT nccf/com/rap.*grib2
> >> PIPE    /unidata/ldm/decoders/dcgrib2 -v 1 -m 15000 -d 
> >> data/gempak/logs/dcgrib2_RAP.log
> >> -e GEMTBL=/unidata/GEMPAK6.2.0/gempak/tables
> >> data/gempak/model/ruc/YYYYMMDDHH_ruc.gem
> >>
> >> I can't find a description of the 'DECODE_GRIB2 -11 code'.
> >>
> >> -Neil
> >>
> >>
> >> ---
> >> Neil Smith  address@hidden   979.845.6272
> >> Senior IT Specialist, Atmospheric Sciences, TAMU
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> > Ticket Details
> > ===================
> > Ticket ID: DJN-782698
> > Department: Support GEMPAK
> > Priority: High
> > Status: Open
> >
> 
> 
> 


Ticket Details
===================
Ticket ID: DJN-782698
Department: Support GEMPAK
Priority: High
Status: Open