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
