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

20050426: Converting CPTEC ETA grib to GEMPAK

Guilherme,

Your dcgrib2.log file shows error messages of the type [DCGRIB 3].
Each of these lines shows the parameter number that could not be found 
in your parameter tables. The problem I believe lies in how you have
named your parameter tables.

examples of the missing parameter numbers that are in the log message
are:
135, 136, 140, 146, 149 etc.

All of these parameters are listed in your cptec.table, and are
in your cptecgrib254.tbl- which means that the parameter should be found
if the table number in the GRIB pds octet #4 is "254".

Your other table, cptecgrib1.tbl would be used if the table number
specified in your GRIB pds block is "1". This table only has parameters
1-127, so the identified missing parameter numbers above will not be
found.

What is the table version number your data uses?
If you don't know, you can run dcgrib2 with "-v 4" and you should see a
line such as:
PDS byte      4 (pds.version)     =
that will tell you what table is expected to be open

Also, when you run the decoder using "-v 4", you will see the names of
the tables that the decoder is opening to find the parameters, such as:

 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 ncepgrib2.tbl
[9360785] 050426/1355[DCGRIB 0] grib tables [cntr 7 edtn 1 vers 2]




The cntrgrib1.tbl will be that table that is opeed to translate the
model center defined by PDS octet #5, eg:
PDS byte      5 (pds.center)      = 
The number that is found in octet 5 is used to determine what model
center created the GRIB. I'm
assuming that your GRID data will define this center to be "46".
Then, in cntrgrib1.tbl you will have "cptec" defined as the string
to use when opening the center parameter table for parameter numbers
128-255.

In the example above, for an NCEP GRIB, you see that center #7 is ncep,
and the table version number is 2, so the tables that are opened are
wmogrib2.tbl for parameters 1-127, and ncepgrib2.tbl for 128-255.

If you still have trouble, please send me the complete log output
for dcgrib2 using the "-v 4" logging level, including the
output that is written to the screen.

Steve Chiswell
Unidata User Support



n Mon, 2005-04-25 at 00:13, Guilherme O. Chagas wrote:
> Steve, 
> 
> I've been working with CPTEC, configuring and creating Gempak tables to allow
> the conversion of CPTEC ETA model to gem files, focused on IDD live feeds.
> I've successfully converted the grib file, and implemented the CPTEC ETA model
> on NMAP, allowing the user to visualize the model output. However, many of the
> variables present in the original grib cant be seen on NMAP, even though some
> can be displayed perfectly. The dcgrib2 conversion log shows some information
> that might be errors  Im not sure -, what might indicate a wrong
> configuration on the conversion table. Can you point out what could be causing
> such problem? Im sending the cptec tables (cptecgrib254.tbl & cptecgrib1.tbl)
> generated to dcgrib2, the original grib table (cptec.table) and dcgrib2 log
> (dcgrib2.log) attached. 
> 
> Best Regards,
> ___________________________
>         Guilherme O. Chagas
>                 address@hidden
>