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.
! GFS grids007 x 077,81,96 037 data/gempak/model/gfs/YYYYMMDDHH_thin.gem 2000 007 x 077,81,96 038 data/gempak/model/gfs/YYYYMMDDHH_thin.gem 2000 007 x 077,81,96 039 data/gempak/model/gfs/YYYYMMDDHH_thin.gem 2000 007 x 077,81,96 040 data/gempak/model/gfs/YYYYMMDDHH_thin.gem 2000 007 x 077,81,96 041 data/gempak/model/gfs/YYYYMMDDHH_thin.gem 2000 007 x 077,81,96 042 data/gempak/model/gfs/YYYYMMDDHH_thin.gem 2000 007 x 077,81,96 043 data/gempak/model/gfs/YYYYMMDDHH_thin.gem 2000 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
This is from a recent version of GEMPAK. For 6Z today, the resulting files in the /gfs directory are: -rw-rw-r-- 1 2000 2000 40285176 Jan 15 05:59 15011506_gfs002.gem -rw-rw-r-- 1 2000 2000 251991032 Jan 15 06:05 15011506_gfs003.gem -rw-rw-r-- 1 2000 2000 287429632 Jan 15 05:55 15011506_gfs160.gem -rw-rw-r-- 1 2000 2000 138518528 Jan 15 05:55 15011506_gfs161.gem -rw-rw-r-- 1 2000 2000 71750144 Jan 15 05:55 15011506_gfs211.gem -rw-rw-r-- 1 2000 2000 237683712 Jan 15 05:56 15011506_gfs212.gem -rw-rw-r-- 1 2000 2000 963998208 Jan 15 05:56 15011506_gfs254.gem -rw-rw-r-- 1 2000 2000 59618816 Jan 15 05:20 15011506_thin.gem 15011506_gfs003.gem is the one-degree file. Cheers, Steve On 01/15/2015 12:01 AM, 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
-- Steve Decker, Teaching Instructor Department of Environmental Sciences Phone: (848) 932-5750 Rutgers University Fax: (732) 932-8644 14 College Farm Rd Email: decker@xxxxxxxxxxxxxxxxxx New Brunswick, NJ 08901-8551
gembud
archives: