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.
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.
Thanks, Michael — that wasn’t as painful as I thought it would be. Much appreciated. Russ > On Sep 25, 2017, at 12:36 PM, gembud-request@xxxxxxxxxxxxxxxx wrote: > > Send gembud mailing list submissions to > gembud@xxxxxxxxxxxxxxxx > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.unidata.ucar.edu/mailman/listinfo/gembud > or, via email, send a message with subject or body 'help' to > gembud-request@xxxxxxxxxxxxxxxx > > You can reach the person managing the list at > gembud-owner@xxxxxxxxxxxxxxxx > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of gembud digest..." > > > Today's Topics: > > 1. Re: dcgrib2 maxgrids (Victor Gensini) > 2. Re: dcgrib2 maxgrids (Michael James) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 25 Sep 2017 13:03:34 -0500 > From: Victor Gensini <vgensini@xxxxxxxxx> > To: Russ Schumacher <russ.schumacher@xxxxxxxxxxxxx> > Cc: gembud <gembud@xxxxxxxxxxxxxxxx> > Subject: Re: [gembud] dcgrib2 maxgrids > Message-ID: > <CAMdGc_J3LjN-+2NOeyCPLfe0ihDfju_cKpKy69rwFtUpuXxvcA@xxxxxxxxxxxxxx> > Content-Type: text/plain; charset="utf-8" > > Gotcha, Russ! > > I thought I was missing a bunch of NAM grids ;-) > > 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. > > vg > > On Mon, Sep 25, 2017 at 11:35 AM, Russ Schumacher < > russ.schumacher@xxxxxxxxxxxxx> wrote: > >> Thanks, Victor. Changing the value in gribkey.tbl doesn?t help here (it >> was set to a lower number than 32K anyway), and I was just showing this as >> an example?I don?t actually need 100000 grids, and this was only decoding a >> single grib2 file. The issue is that in reality, the full set of the >> NAM212 requires more than 32K grids after the upgrade, and the default >> configuration remains to send all of the grids to a single .gem file (which >> would be preferable to keep if possible to avoid needing to change lots of >> other configurations.) >> >> Russ >> >> >> >> On Sep 25, 2017, at 10:30 AM, Victor Gensini <vgensini@xxxxxxxxx> wrote: >> >> Hi Russ, >> >> What is the max-grid(s) entry in your $GEMTBL/grid/gibkey.tbl file for the >> NAM? Also, do you really need to decode 100,000 grids in one file? I >> believe GEMPAK limits total to 32,000 and I only see 658 grids in the file >> you posted. If you really need to be able to decode 100,000 grids in one >> file, my guess is that you will have to split up the files. >> >> Best, >> >> Victor Gensini >> >> On Mon, Sep 25, 2017 at 11:13 AM, Russ Schumacher < >> russ.schumacher@xxxxxxxxxxxxx> wrote: >> >>> Hi gembud, >>> >>> We recently upgraded to GEMPAK7.4.1 on our machine running LDM, mainly to >>> alleviate the issue where the files being created for the NAM didn?t have a >>> large enough maximum number of grids to accommodate all of the fields since >>> the NAM upgrade last spring. The release notes mention this fix in 7.4.1. >>> However, I seem to still be encountering the same problem, namely that the >>> file is only getting created with a maximum # of grids of 31999 regardless >>> of what number is set in the call to dcgrib2. Just as an example when >>> running from the command line?I set ?-m 100000? but still end up with a >>> maximum number of grids in file of 31999. Is there something else we need >>> to do to allow for the larger # of grids? >>> >>> Thanks! >>> Russ >>> >>> >>> >>> >>> >>> >>> [rschumac@argun ~]$ dcgrib2 -v 1 -m 100000 -e GEMTBL=$GEMTBL >>> YYYYMMDDHH_nam212_gem7.gem < /ldm-data/model_grib/nam/20170925/nam212. >>> 2017092512 <(201)%20709-2512>_f84.grb2 >>> Opening WMO Originating Center Table wmocenter.tbl... >>> Opening WMO GRIB2 Parameter Table g2varswmo2.tbl... >>> Opening WMO GRIB2 Vertical Coordinate Table g2vcrdwmo2.tbl... >>> Opening Local GRIB2 Parameter Table g2varsncep1.tbl... >>> Opening Local GRIB2 Vertical Coordinate Table g2vcrdncep1.tbl... >>> [rschumac@argun ~]$ gdinfo >>> GDFILE Grid file 2017092512 >>> <(201)%20709-2512>_nam212_gem7.gem >>> LSTALL Full list flag YES >>> OUTPUT Output device/filename T >>> GDATTIM Grid date/time LAST >>> GLEVEL Grid level 500 >>> GVCORD Grid vertical coordinate PRES >>> GFUNC Scalar grid TMPC >>> Parameters requested: GDFILE,LSTALL,OUTPUT,GDATTIM,GLEVEL,GVCORD,GFUNC. >>> GEMPAK-GDINFO>r >>> >>> GRID FILE: 2017092512 <(201)%20709-2512>_nam212_gem7.gem >>> >>> GRID NAVIGATION: >>> PROJECTION: LCC >>> ANGLES: 25.0 -95.0 25.0 >>> GRID SIZE: 185 129 >>> LL CORNER: 12.1900 -133.4590 >>> UR CORNER: 57.2893 -49.3860 >>> >>> GRID ANALYSIS BLOCK: >>> UNKNOWN ANALYSIS TYPE >>> >>> Number of grids in file: 658 >>> >>> Maximum number of grids in file: 31999 >>> >>> [GDU 2] Did not find any matching grids. >>> Parameters requested: GDFILE,LSTALL,OUTPUT,GDATTIM,GLEVEL,GVCORD,GFUNC. >>> GEMPAK-GDINFO> >>> >>> >>> >>> -- >>> Russ S. Schumacher >>> Associate Professor >>> Department of Atmospheric Science >>> Colorado State University >>> e-mail: russ.schumacher@xxxxxxxxxxxxx >>> phone: 970.491.8084 <(970)%20491-8084> >>> web: http://www.atmos.colostate.edu/faculty/schumacher.php >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> NOTE: All exchanges posted to Unidata maintained email lists are >>> recorded in the Unidata inquiry tracking system and made publicly >>> available through the web. Users who post to any of the lists we >>> maintain are reminded to remove any personal information that they >>> do not want to be made public. >>> >>> >>> gembud mailing list >>> gembud@xxxxxxxxxxxxxxxx >>> For list information or to unsubscribe, visit: >>> http://www.unidata.ucar.edu/mailing_lists/ >>> >> >> >> >> >> -- >> Russ S. Schumacher >> Associate Professor >> Department of Atmospheric Science >> Colorado State University >> e-mail: russ.schumacher@xxxxxxxxxxxxx >> phone: 970.491.8084 <(970)%20491-8084> >> web: http://www.atmos.colostate.edu/faculty/schumacher.php >> >> >> >> >> >> >> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://mailman.unidata.ucar.edu/mailing_lists/archives/gembud/attachments/20170925/105666e2/attachment.html> > > ------------------------------ > > Message: 2 > Date: Mon, 25 Sep 2017 12:36:14 -0600 > From: Michael James <mjames@xxxxxxxx> > To: "gembud@xxxxxxxxxxxxxxxx" <gembud@xxxxxxxxxxxxxxxx> > Subject: Re: [gembud] dcgrib2 maxgrids > Message-ID: > <CAJtNOJvsEjkeBEDRn-ZvF6hwo01pDzx64xxNZ_9zjHjN1qyHTA@xxxxxxxxxxxxxx> > Content-Type: text/plain; charset="utf-8" > >> 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. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://mailman.unidata.ucar.edu/mailing_lists/archives/gembud/attachments/20170925/08320138/attachment.html> > > ------------------------------ > > _______________________________________________ > NOTE: All exchanges posted to Unidata maintained email lists are > recorded in the Unidata inquiry tracking system and made publicly > available through the web. Users who post to any of the lists we > maintain are reminded to remove any personal information that they > do not want to be made public. > > > gembud mailing list > gembud@xxxxxxxxxxxxxxxx > For list information or to unsubscribe, visit: > http://www.unidata.ucar.edu/mailing_lists/ > > End of gembud Digest, Vol 100, Issue 4 > ************************************** -- Russ S. Schumacher Associate Professor Department of Atmospheric Science Colorado State University e-mail: russ.schumacher@xxxxxxxxxxxxx phone: 970.491.8084 web: http://www.atmos.colostate.edu/faculty/schumacher.php
gembud archives: