NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
> 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.
gembud
archives: