Re: [gembud] dcgrib2 maxgrids

> Our GEMPAK solution was to break up each forecast hour into an additional
> file.
>
> From gribkey.tbl:
> ! NAM
> 007   x   084,085   104    data/gempak/model/nam/YYYYMMDDHHfFFF_nam@@@.gem
>   18000
> 007   x   084,085   212    data/gempak/model/nam/YYYYMMDDHHfFFF_nam@@@.gem
>   24000
>
> I know this isn't what you want to hear, but maybe the other GEMPAK gurus
> out there can point to a different solution.
>


This is my recommendation as well. For 7.4.1 I attempted to update the max
# of grids for each on the IDD, and for large models separated .gem files
by forecast hour like above (with fFFF in the filename).  But I missed the
NAM40 (212) because my LDM was pulling it from HDS rather than CONDUIT.

I would recommend updating gribkey.tbl with the above, and  update
$GEMTBL/config/datatype.tbl

from

NAM40        $MODEL/nam                YYYYMMDDHH_nam212.gem
NAM212       $MODEL/nam                YYYYMMDDHH_nam212.gem
ETA212       $MODEL/nam                YYYYMMDDHH_nam212.gem

to
NAM40        $MODEL/nam                YYYYMMDDHHfFFF_nam212.gem
NAM212       $MODEL/nam                YYYYMMDDHHfFFF_nam212.gem
ETA212       $MODEL/nam                YYYYMMDDHHfFFF_nam212.gem

I'll have these changes in the next GEMPAK release.

---


As for the 31999 limit, it's defined in $GEMPAK/include/ as MMHDRS


in GEMPRM.PRM

PARAMETER       ( MMHDRS = LLSTFL + LLMXTM )
where

PARAMETER       ( LLSTFL =  30000   )
C! Max # stations in file
PARAMETER       ( LLMXTM =  2000   )
C! Max # times/dataset


in gemprm.h

#define MMHDRS  ( LLSTFL + LLMXTM ) /* Maximum # of headers */h

#define LLSTFL          (   30000 )     /* Max # stations in file */

#define LLSTHL          (      20 )     /* Max header size */


But of course any definition changes in $GEMPAK/includes/ requires a
rebuild of all libraries and binaries.