Re: [gembud] CMC decode problem

And should you wonder why my query was about doing what Michael recommends and not getting the desired result, it was because I was adjusting the max grids number in a gribkey.tbl file that belonged to another version of GEMPAK, not the one specified by the GEMTBL environment variable in my pqact.conf.

And yes, I are a Aggie.

-Neil

On 4/7/11 2:54 PM, Michael James wrote:
This problem was resolved off-list, but I wanted to post publicly for others.

Users should update the cmc entry in $GEMTBL/grid/gribkey.tbl to allow more than 1000 grids (set to 20000 in the example below), and confirm the full forecast time range is available in the $MODEL/cmc/YYYYMMDDHH_cmcreg.gem files via GDINFO and file size (should be approx. 29 mb). You can also force max grid size with the dcgrib2 flag "-m 20000" in the pqact entry:

CMC     CMC_reg
PIPE /unidata/ldm/decoders/dcgrib2 -v 1 -m 20000 -d data/gempak/logs/dcgrib2_cmc.log
        -e GEMTBL=/unidata/GEMPAK6.2.0/gempak/tables


Michael James
Unidata



On 04/01/2011 03:26 PM, Neil Smith wrote:
ldm 6.9.2
gempak 6.2.0
Centos 5.5

I'm not getting all of the CMC forecast times written to file. My logging of the decode shows that bulletins out to F048 are being read and processed but gdinfo, garp and nmap2 are showing the output file containing only out to F024.

This pqact entry:
CMC     CMC_reg
PIPE /unidata/ldm/decoders/dcgrib2 -v 1 -d data/gempak/logs/dcgrib2_cmc.log
        -e GEMTBL=/unidata/GEMPAK6.2.0/gempak/tables

and this $GEMTBL/grid/gribkey.tbl entry

054 x 036 @@@ data/gempak/model/cmc/YYYYMMDDHH_cmcreg.gem 20000

The default gribkey.tbl entry goes to 1000 but I've upped it to 10000 and 20000 to see if this was the problem. No change.

Does anyone have suggestions?

-Neil
---
Neil Smith neils@xxxxxxxx <mailto:neils@xxxxxxxx>
Comp. Sys. Mngr., Atmospheric Sciences



--
Neil R. Smith     neils@xxxxxxxx    979-845-6272
Comp Sys Admin, Dept. Atmospheric Sciences, Texas A&M Univ.