Thanks for all responses so far.
James, those are good pointers, especially Michael’s suggestion in the latest
posting, changing:
007 x 077,81,96 703 data/gempak/model/gfs/YYYYMMDDHH_gfs703.gem 29000
to
007 x 077,81,96 703 data/gempak/model/gfs/YYYYMMDDHH_gfs003.gem 29000
But looking at the current GEMPAK7 distro (downloaded Sept 2014) gribkey.tbl,
there is the following in the latter part of the gfs section:
007 x 077,81,96 044 data/gempak/model/gfs/YYYYMMDDHH_thin.gem 2000
007 x 077,81,96 002 data/gempak/model/gfs/YYYYMMDDHH_gfs@@@.gem 9000
007 x 077,81,96 003 data/gempak/model/gfs/YYYYMMDDHH_gfs@@@.gem 29000
007 x 077,81,96 004 data/gempak/model/gfs0.5deg/YYYYMMDDHHfFFF_gfs.gem
29000
007 x 077,81,96 @@@ data/gempak/model/gfs/YYYYMMDDHH_gfs@@@.gem 10000
I find it interesting that the decoded gfs703.gem files I’m getting are in fact
limited to 10000 grids, which only goes to F087.
If that’s the only table match that grid 703 can have, then dcgrib2 is only
going to decode that number. One can find that the
motherlode.ucar.edu/decoded/gempak/gfs/*gfs703.gem are also of 10000 grids and
F087.
If Michael’s suggestion is implemented - forcing the model 703 to be written as
*gfs003.gem but with 29000 grid allocation, then might that also be satisfied
with:
007 x 077,81,96 @@@ data/gempak/model/gfs/YYYYMMDDHH_gfs@@@.gem 29000
Watching notifyme for CONDUIT and “prod/gfs”, and additionally the log of the
pqact for "prod/gfs.*pgrb[^2]”
shows that the grids out to F192 were indeed arriving in queue and piped thru
dcgrib2. The log file never stated what file was opened and never showed a
file closing. Is that what happens when a decode action is not allocated a
number of grids commensurate with the product grid count?
-Neil
On Sep 11, 2014, at 10:07 AM, James Murakami <tenki@xxxxxxxxxxxxxx> wrote:
> Hi Neil,
>
> There are two references I remember about this problem. The latest solution
> is below(changes to $GEMTBL/grid/gribkey.tbl):
>
> http://www.unidata.ucar.edu/support/help/MailArchives/gempak/msg06418.html
>
>
> The older solution involves amending the $GEMTBL/grid/grdnav.tbl:
>
> http://www.unidata.ucar.edu/support/help/MailArchives/gempak/msg05419.html
>
>
> James
> ----------------------------------------------
> James Murakami
> Staff Meteorologist/Student Affairs
> Department of Atmospheric and Oceanic Sciences
> University of California, Los Angeles
> 405 Hilgard Ave.
> Los Angeles, CA 90095-1565
>
>
> e-mail: tenki@xxxxxxxxxxxxxx
> telephone: 310-825-2418
> Fax: 310-206-5219
> ----------------------------------------------
> On 09/10/2014 04:41 PM, Neil Smith wrote:
>> Hi Donna,
>> I’ll set up a notifyme. But gotta wait till about midnight for the 00 run.
>> And my pqact looks exactly like Michael’s.
>> This is the second (VM) ldm ingester I’ve set up thinking I’ve messed
>> something up somewhere.
>>
>> My old standby ldm 6.9.2 and GEMPAK6.8.0 seems to saving the gfs003.gem but
>> not the gfs703.gem with the very same regex.
>>
>> On Sep 10, 2014, at 6:14 PM, Donna Cote <d-cote@xxxxxxxx> wrote:
>>
>>> Have you used LDM`s notify me command to see what gfs files you are getting
>>> in your queue?
>>>
>>> Oh and does your ldmd.conf file have a regex other than ".*" ?
>>>
>>> On Sep 10, 2014 5:52 PM, "Neil Smith" <neils@xxxxxxxx> wrote:
>>> Thanks Michael.
>>> Thing is, I’m not getting the gfs003.gem file from the CONDUIT feed. But I
>>> am getting the gfs703.gem file — which did or did not replace the -F192
>>> gfs003
>>> product in CONDUIT? And using that very ERE.
>>>
>>> Using:
>>> ldm 6.12.6, GEMPAK7
>>>
>>> On Sep 10, 2014, at 5:42 PM, Michael James <mjames@xxxxxxxx> wrote:
>>>
>>>> Hi Neil,
>>>>
>>>> CONDUIT prod/gfs.*pgrb[^2]
>>>>
>>>> PIPE dcgrib2 -d data/gempak/logs/dcgrib2_CONDUITgfs.log
>>>>
>>>> -e GEMTBL=/home/gempak/NAWIPS/gempak/tables
>>>>
>>>>
>>>> The file $GEMTBL/grid/gribkey.tbl determines how the GEMPAK grid files are
>>>> written, the last for the 0.5 degree split out by forecast hour.
>>>>
>>>> 007 x 077,81,96 002 data/gempak/model/gfs/YYYYMMDDHH_gfs@@@.gem
>>>> 9000
>>>>
>>>> 007 x 077,81,96 003 data/gempak/model/gfs/YYYYMMDDHH_gfs003.gem
>>>> 29000
>>>>
>>>> 007 x 077,81,96 004
>>>> data/gempak/model/gfs0.5deg/YYYYMMDDHHfFFF_gfs.gem 29000
>>>>
>>>>
>>>> Michael James
>>>> Unidata Program Center
>>>> Boulder, CO
>>>>
>>>> On Wed, Sep 10, 2014 at 4:31 PM, Neil Smith <neils@xxxxxxxx> wrote:
>>>> What is a pqact entry for the gfs 1deg F000-F192 decoded with dcgrib2?
>>>>
>>>> I’ve succeeded in thoroughly confusing myself and now I don’t know which
>>>> way is up.
>>>>
>>>> -Neil
>>>>
>>>> _______________________________________________
>>>> gembud mailing list
>>>> gembud@xxxxxxxxxxxxxxxx
>>>> For list information or to unsubscribe, visit:
>>>> http://www.unidata.ucar.edu/mailing_lists/
>>>>
>>>>
>>>> _______________________________________________
>>>> gembud mailing list
>>>> gembud@xxxxxxxxxxxxxxxx
>>>> For list information or to unsubscribe, visit:
>>>> http://www.unidata.ucar.edu/mailing_lists/
>>>
>>>
>>> _______________________________________________
>>> gembud mailing list
>>> gembud@xxxxxxxxxxxxxxxx
>>> For list information or to unsubscribe, visit:
>>> http://www.unidata.ucar.edu/mailing_lists/
>>
>>
>>
>> _______________________________________________
>> gembud mailing list
>> gembud@xxxxxxxxxxxxxxxx
>> For list information or to unsubscribe, visit:
>> http://www.unidata.ucar.edu/mailing_lists/
>
