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.
