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

[GEMPAK #HAT-279589]: Decoding GRIB to GEMPAK

Quang,

You may have a problem with your model center 100 not being defined in the 
GEMPAK grid files.
Your parameter listed below is #32, which is in the WMO defined range, so the 
decoder knows
what to call that parameter, but we should add a center number to
$GEMTBL/grid/cntrgrib1.tbl
for the identifier you are using below.

Looking at:
http://www.nco.ncep.noaa.gov/pmb/docs/on388/table0.html
I see center 100 is Brazzaville. I would have expected you to be using number 
136,
but in either case, add a line such as:
100 Brazzaville, Republic of Congo                                   BRAZ
136 Socialist Republic of Viet Nam (NMC)                             VNC

Your table version for that grid is version 3, so create a file (for BRAZ 
center 100)
$GEMTBL/grid/brazgrib3.tbl, or (136 VNC) $GEMTBL/grid/vncgrib3.tbl:
Use the single "255 missing" line such as in $GEMTBL/grid/fnocgrib2.tbl.

For GRIB decoding, parameters with numbers less than 128 are defined in the WMO
tables $GEMTBL/grid/wmogrib#.tbl (where # is the table version number).
For parameters 128-255, the model center defines its own locat parameters, and 
the
cntrgrib1.tbl file will be used to determine the string to use for the model 
center
as specified by the number in the GRIB PDS block, eg brazgrib#.tbl for center 
100.

At startup of dcgrib2, you should see log messages for opening 4 tables:
cntrgrib1.tbl, the wmo and center specific tables, and the vertical coordinate 
table
$GEMTBL/grid/vcrdgrib1.tbl. Verify that all are being found.

You should be able to decode your grid with:

cat gribfile | dcgrib2 -d - output_file.gem

If that is what you are doing, try adding verbose logging such as:
cat gribfile | dcgrib2 -v 4 -d - output_file.gem

and/or send me a sample of the grib message if you still have problems.

Steve Chiswell
Unidata User Support


> Hi Dr. Steve Chiswell,
> 
> Many thanks for your quick advisor.
> I changed the domain size of the grib file (201x161)
> so that's Ok now.
> {
> rec 1:4:date 2006092116 WIND kpds5=32 kpds6=0 kpds7=0
> levels=(0,0) grid=255  anl:
> WIND=Wind speed [m/s]
> timerange 10 P1 0 P2 0 TimeU 1  nx 201 ny 161 GDS
> grid 0 num_in_ave 0 missing 0
> center 100 subcenter 0 process 255 Table 3
> latlon: lat  -10.000000 to 30.000000 by 0.250000
> nxny 32361
> long 80.000000 to 130.000000 by 0.250000,
> (201 x 161) scan 132 mode 1 bdsgrid 1
> min/max data 0 24.8101  num bits 16  BDS_Ref 0
> DecScale 0 BinScale -11
> }
> 
> Then I tried to use: dcgrib2 file_name ; but it
> does'nt creat the *.gem file.
> (You could see the log file which is attached in this
> email)
> What is the problem now?
> 
> Quang
> 
> --- Unidata GEMPAK Support
> <address@hidden> wrote:
> 
> >
> > Quang,
> >
> > Your dcgrib2 error log message provides the answer:
> > [17780] 060925/1455[DCGRIB -55] Grid too large 1440
> > x 720 [1036800 > 750000]
> >
> > Your grid is 1036800 points, whereas the maximum
> > grid that can be stored is
> > defined at compile time as 750,000 points.
> >
> > However, you must be using an older distribution.
> > The LLMXTG I configured
> > in the 5.9.3 distribution is 1,679,940 points.
> >
> > GEMPAK has 2 parameters, LLMXTG which is the larges
> > grid that can be stored,
> > and LLMXGD which is the maximum number of gridpoints
> > that can be used in
> > grid calculations. The LLMXGD setting in 5.9.3 is
> > 400,000. The IJSKIP
> > parameter allows a grid to be subsampled, or the
> > GAREA can be set to a subarea.
> >
> > LMXTG and LLMXGD can be edited in the source
> > distribution in $GEMPAK/include/MCHPRM.*
> > and gemprm.h.
> >
> > Steve Chiswell
> > Unidata User Support
> >
> >
> >
> > > Dear Dr. Steve,
> > >
> > > My question today is related to the problem of
> > > transfering a GRIB1 file into GEMPAK's format
> > (*.gem)
> > >
> > > I'll show you the output of using dcgrib2.
> > > First, to check the GRIB1 file is Ok, I used wgrib
> > -V
> > > filename and the output is
> > > rec 1:0:date 2006092116 WIND kpds5=32 kpds6=0
> > kpds7=0
> > > levels=(0,0) grid=255 anl:
> > > WIND=Wind speed [m/s]
> > > timerange 10 P1 0 P2 0 TimeU 1 nx 1440 ny 720 GDS
> > > grid 0 num_in_ave 0 missing 0
> > > center 100 subcenter 0 process 255 Table 3
> > > latlon: lat 0.000000 to 90.000000 by 0.250000 nxny
> > > 1036800
> > > long 0.000000 to 360.000000 by 0.250000,
> > > (1440 x 720) scan 21 mode 1 bdsgrid 1
> > > min/max data 0 655.344 num bits 16 BDS_Ref 0
> > > DecScale 0 BinScale -6
> > > Second, I used dcgrib2. The result is it creats
> > files
> > > dcgrib2.log, gemglb.nts and last.nts but not a gem
> > > file.
> > >
> > > So how can I do now?
> > > Many thanks from you.
> > > Quang
> > >
> > > Nguyen Dang Quang
> > > Dept. of Research and Application
> > > Vietnam National Center for Hydrometeorological
> > Forecast
> > > 4 Dang Thai Than, Hanoi, VIETNAM
> > > Tel.:84-4-9330942
> >
> >
> > Ticket Details
> > ===================
> > Ticket ID: HAT-279589
> > Department: Support GEMPAK
> > Priority: Low
> > Status: Closed
> >
> >
> 
> Nguyen Dang Quang
> Dept. of Research and Application
> Vietnam National Center for Hydrometeorological Forecast
> 4 Dang Thai Than, Hanoi, VIETNAM
> Tel.:84-4-9330942
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> 


Ticket Details
===================
Ticket ID: HAT-279589
Department: Support GEMPAK
Priority: Low
Status: Closed