> 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.
