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 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/ >
gembud archives: