Re: [gembud] pqact for gfs 1deg F000-F192

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

  • 2014 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the gembud archives: