[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20000308: NOGAPS on NCEP FTP server and dcgrib

>From: Robert Mullenax <address@hidden>
>Organization: .
>Keywords: 200003080811.BAA16071

>I would be curious to look at the UKMET and NOGAPS
>model data that is available on the NCEP server.
>Will dcgrib decode these models?  I am currently 
>using a cron job to retrieve and decode the AVN 1x1 grid
>data from the FTP server.
>
>I know that there has been some talk of the UKMET coming in on NOAAport
>but I don't think I want to turn that on yet as I am
>a little short on disk space.
>
>Thanks,
>Robert Mullenax
>

Robert,

Dcgrib has no trouble decoding nogaps, ukmet, or the GEM model from CMS.

The ukmet on NOAAport uses the same thinned grids as the AVN, so I added
the definition in the pl15 distribution to define the ukm composite grid.
The pqact.conf pattern would be: 
HRS     ^H.[I-P]... EGRR
you would specify the thickened resolution the same as for the AVN thinned 
grids,
so you can control the disk space usage the resolution of the output grid,
eg: -q"lin,dlat=1.25,dlon=1.25", -q"lin,dlat=2.5,dlon=2.5", 
-q"lin,dlat=5,dlon=5".
Storing the grids at 1.25x1.25 resolution gives more detail, but uses more
disk space.

The nogaps grids on the NCEP server are grid #240, and dcgrib will use the GDS
block to create the appropriate grid file which turns out to be:
 GRID FILE: 2000030800_nogaps240.gem                                            
    

 GRID NAVIGATION: 
     PROJECTION:          CED                 
     GRID SIZE:          360 181
     LL CORNER:             -90.00      0.00
     UR CORNER:              90.00     -1.00

The GEM model which we will soon be able to deliver by the IDD is a regional
model, so probably not of interest to you in this context.

The primary thing to realize is that dcgrib relies on the $GEMTBL/grid
tables. The $GEMTBL/grid/cntrgrib1.tbl file defines the modeling centers.
The FNOC #58, CMS #54  and UKMO #74. Dcgrib will open the
wmogribx.tbl file which contains the parameter definitions for 1-127, then
will look to open the fnocgribx.tbl, ukmogrib.tbl etc depending on
which center created the file to see if there are locally defined
parameters 128-255 (ncep has lots of locally defined parameters in 
ncepgribx.tbl).
The grib version defined in the bulletin will be 1,2,3 128 etc. so
the table will be named like fnocgrib2.tbl. Dcgrib will output the names
of the tables it is looking for in the logs:

cat nogaps.t00z.GRB00 | dcgrib -v -d - PACK YYYYMMDDHH_nogaps@@@.gem
Mar 08 16:57:47 dcgrib[856642]: Starting Up
Mar 08 16:57:48 dcgrib[856642]: Using gds block for projection id:         240
Mar 08 16:57:48 dcgrib[856642]: Opened 2000030800_nogaps240.gem 58 240
 Changing center table to cntrgrib1.tbl
 Changing vertical coord table to vcrdgrib1.tbl
 Changing WMO parameter table to wmogrib2.tbl
 Changing center parameter table to fnocgrib2.tbl
 [NA -1]  The table fnocgrib2.tbl cannot be opened.
Mar 08 16:57:48 dcgrib[856642]: read grib tables 0 58 1 2
Mar 08 16:57:48 dcgrib[856642]: 1    OK -- 000308/0000     Grid ID  240   2 102 
  0   0

The NA -1 error above means that the table fnocgrib2.tbl doesn't exist in the
$GEMTBL/grid directory. If there were locally defined parameters 128-255 for 
nogaps,
you would have to create that table. The information following the grid is 240 
is
the parameter number, vertical coordinate (found in vcrdgrib1.tbl) and the
2 octets for the level. In running through the 0hr forecast, all of the
parameters are less than #128, so they appear to be using the wmo standards.
As long as they do that, you won't have to create a center specific table.
The main point here is that dcgrib will run without finding the table...
but you will get blank parameter names in your decoded file.

I hope this gives you the information to decode these and other grids
you can get in places other than the IDD. 

Steve CHiswell