This is what I have, which appears to be working fine (although I guess
I am missing some grids if there are more than 29000):
! GFS grids
007 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