[GEMPAK #GQU-639440]: NAM products not decoding

Hi Ted,

The NAM 12km in GEMPAK 7.4.1 is being split by forecast hour: the entry in 
gribkey.tbl is 

007   x   084,085   218    data/gempak/model/nam12km/YYYYMMDDHHfFFF_nam@@@.gem  
1000


and the gem files should exist in $MODEL/nam12km/

In datatype.tbl there are the following aliases available:

NAM12        $MODEL/nam12km            YYYYMMDDHHfFFF_nam218.gem                
        CAT_GRD  SCAT_FCT   -1     -1     -1      OFF/0/0
NAM218       $MODEL/nam12km            YYYYMMDDHHfFFF_nam218.gem                
        CAT_GRD  SCAT_FCT   -1     -1     -1      OFF/0/0
ETA218       $MODEL/nam12km            YYYYMMDDHHfFFF_nam218.gem                
        CAT_GRD  SCAT_FCT   -1     -1     -1      OFF/0/0
MESO         $MODEL/nam12km            YYYYMMDDHHfFFF_nam218.gem                
        CAT_GRD  SCAT_FCT   -1     -1     -1      OFF/0/0

So let's check that these are the table entries you have, check if files exist 
in that directory, and check that the aliases work in GD programs. 

And there's no reason to be concerned by the dcgrib2 log messages like "Could 
not determine parameter name 0 3 5 0 [0]" unless you see a large number of 
them.  Most of these parameters are decoded correctly anyway, but the errors 
messages still show up because how GEMPAK checks grib file locations. 



> Cannot seem to decode NAM forecast data (0,6,12,18,24,30,36,42,48,54, &
> 60 hours) from LDM.   I believe all the relevant into is below.
> 
> Key components are:
> 
> OS:                          CentOS Linux release 7.4.1708
> LDM version:           6.13.5
> GEMPAK:                 7.4.1
> 
> 
> I believe the key lines in the LDM config (which we have compared to
> https://github.com/Unidata/gempak/blob/master/ldm/etc/templates/pqact.gempak_decoders_grid)
> are as follows:
> 
> 
> # NAM #218 12km grid CONUS
> #NGRID|CONDUIT  (^[LM].B... KWBE|prod/nam.*awip12)
> CONDUIT (^[LM].B... KWBE|prod/nam.*awip12)
>         PIPE    decoders/dcgrib2 -d data/gempak/logs/dcgrib2_NAM218.log
>                 -e GEMTBL=/usr/local/gempak/CURRENT/gempak/tables
> 
> As far as I can tell, this looks right.   But we are getting entries in
> the log that say things like:
> 
> .
> .
> .
> [77922] 171205/1443[GB -1]  No GRIB record was found.
> [77922] 171205/1443[DECODE_GRIB2 -34] Could not determine parameter name
> 0 3 5 0 [0]
> [77922] 171205/1443[GB -1]  No GRIB record was found.
> [77922] 171205/1443[DECODE_GRIB2 -34] Could not determine parameter name
> 0 3 5 0 [0]
> [77922] 171205/1453[DC 5]  Normal termination.
> [77922] 171205/1453[DC 2]  Number of bulletins read and processed: 14920
> [77922] 171205/1453[DC 6]  Shutting down.
> 
> It seems to have been working fine prior to upgrading to GEMPAK 7.4.1
> from GEMPAK7.    Since we are not able to get the data we cannot
> generate maps/analyses from no data.
> 
> Any advice/assistance greatly appreciated.
> 
> Ted
> 
> --
> *Ted Wisniewski*
> Director of Technology Services
> Information Technology Services
> Plymouth State University
> 
> There is no problem that cannot be made more difficult by overthinking it.
> 
> 


Ticket Details
===================
Ticket ID: GQU-639440
Department: Support GEMPAK
Priority: Normal
Status: Open
===================
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata 
inquiry tracking system and then made publicly available through the web.  If 
you do not want to have your interactions made available in this way, you must 
let us know in each email you send to us.