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