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.
Hello gembuds, Thanks to Steve Chiswell's suggestions about editing $GEMTBL/grid/grdnav.tbl AND $GEMTBL/grid/gribkey.tbl I got that set up for automatic filing of all the GFS grids (and I took out the 703 grid references in both grdnav.tbl and gribkey.tbl). Even after doing that, I was still running into trouble due to the fact that I copied a pqact line out of an email and it used a SPACE and not a TAB between the feedtype and prodID. Once that error was corrected, I issued a "kill -HUP $process_id" to the appropriate process_id for that pqact job, and all started working great. Thanks for your help everyone. David On Wed, Jan 14, 2015 at 09:01:51PM -0800, David Ovens wrote: > Hello Gembuds, > > Most of our scripts are working with the new GFS file names. However, > I am not getting any 1.0 degree GEMPAK files produced, despite having > the GRIB2 files for them. > > This entry from pqact.gempak_decoders_grid > > CONDUIT prod/gfs.*pgrb2 > PIPE decoders/dcgrib2 -d data/gempak/logs/dcgrib2_CONDUITgfs2.log > -e GEMTBL=/home/gempak/NAWIPS/gempak/tables > > I know is attempting to process all resolutions of the grids, and I > get the gfs0.5deg/*gfs.gem files. But I do not get the expected > gfs/YYYYMMDDHH_gfs.gem files. > > Here are the current relevant entries that I have in my > /home/gempak/NAWIPS/gempak/tables/grid/gribkey.tbl table including a > comment about the gfs703.gem that I think is the relevant one: > > !center sub modelid grid Output grid file name max_grids > ! > ! GFS grids > 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 > ! as of 11/8/2007, gfs703.gem file comes from GRIB2 version of 1-degree GFS > from CONDUIT > 007 x 077,81,96 703 data/gempak/model/gfs/YYYYMMDDHH_gfs.gem 29000 > 007 x 077,81,96 @@@ data/gempak/model/gfs/YYYYMMDDHH_gfs@@@.gem 29000 > > Does anyone else have different entries in their gribkey.tbl file that > are allowing them to get a GEMPAK file for the 1.0 degree GFS grids? > > NOTE: I have been able to manually create the file with the new grids > doing this from my conduit/gfs.2015011412 directory: > > foreach i (gfs.t12z.pgrb2.1p00.f*) > dcgrib2 -m 35000 -d ~/logs/test.gfs1p00.log -e GEMTBL=$GEMTBL \ > $GEMDATA/model/gfs/2015011412_gfs.gem < $i > end > > and that put 32,972 grids into the file, so I'll be increasing the > 29000 max value in the table for sure. I just have not been able to > figure out what is wrong with the gribkey.tbl entries. > > Thanks for any help. > > David > -- > David Ovens e-mail: ovens@xxxxxxxxxxxxxxxxxxxx > Research Meteorologist phone: (206) 685-8108 > Dept of Atm. Sciences plan: Real-time MM5 forecasting for the > Box 351640 Pacific Northwest > University of Washington http://www.atmos.washington.edu/mm5rt > Seattle, WA 98195 Weather Graphics and Loops > http://www.atmos.washington.edu/~ovens/loops > > > On Wed, Jan 14, 2015 at 02:04:48PM -0700, Michael James wrote: > > Hello GEMPAK users, > > > > With the update to global GFS file naming today on CONDUIT, I've > > attached a new pqact.gempak_decoders_grid template file. The 1800 UTC > > run for January 14, 2015 is the first run on CONDUIT using the new > > product IDs. > > > > The attached file can also be found online at > > https://github.com/Unidata/gempak/blob/master/ldm/etc/templates/pqact.gempak_decoders_grid > > > > The new template should be put in $NAWIPS/ldm/etc/templates/ and the > > program $NAWIPS/ldm/gen_pqact.csh run again to re-create the LDM pqact > > files, which will then need to be manually copied to the appropriate > > LDM etc directory. > > > > You can also make a quick manual edit: > > > > Old: > > > > # 1.0 degree GFS data > > # 2.5 degree GFS data > > CONDUIT prod/gfs.*pgrb[^2] > > PIPE decoders/dcgrib2 -d data/gempak/logs/dcgrib2_CONDUITgfs.log > > -e GEMTBL=/home/gempak/NAWIPS/gempak/tables > > # > > # 0.5 degree GFS data > > CONDUIT prod/gfs.*pgrb2 > > PIPE decoders/dcgrib2 -d data/gempak/logs/dcgrib2_CONDUITgfs2.log > > -e GEMTBL=/home/gempak/NAWIPS/gempak/tables > > > > New: > > > > # 0.5 degree GFS data - gfs.tCCz.pgrb2.0p50.fFFF > > # 1.0 degree GFS data - gfs.tCCz.pgrb2.1p00.fFFF > > # 2.5 degree GFS data - gfs.tCCz.pgrb2.2p50.fFFF > > CONDUIT prod/gfs.*pgrb2 > > PIPE decoders/dcgrib2 -d data/gempak/logs/dcgrib2_CONDUITgfs.log > > -e GEMTBL=/home/gempak/NAWIPS/gempak/tables > > > > > > Michael James > > Unidata Program Center > > Boulder, CO > > > > _______________________________________________ > > 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/ -- David Ovens e-mail: ovens@xxxxxxxxxxxxxxxxxxxx Research Meteorologist phone: (206) 685-8108 Dept of Atm. Sciences plan: Real-time MM5 forecasting for the Box 351640 Pacific Northwest University of Washington http://www.atmos.washington.edu/mm5rt Seattle, WA 98195 Weather Graphics and Loops http://www.atmos.washington.edu/~ovens/loops
gembud archives: