[Fwd: Re: 20050426: Converting CPTEC ETA grib to GEMPAK]

--- Begin Message ---

• Subject: Re: 20050426: Converting CPTEC ETA grib to GEMPAK
• Date: Wed, 27 Apr 2005 15:48:23 -0200

Steve,
thanks for your help! now it's working fine, I'll pay more attention to the
"tab" from now on!

Best Regards,
___________________________
        Guilherme O. Chagas
                address@hidden

On 27 Apr 2005 11:17:39 -0600, Steve Chiswell wrote
> Guilherme,
> 
> Your table had "tab" characters in it which may be confusing the fortran
> read format for the table in $GEMPAK/source/gemlib/na/nartbl.f.
> 
> I modified your table and have attached it to this message. Can you
> try your decoding again and see if this changes your result.
> Note, that if/when you upgrade to GEMPAK5.8.1 and later,
> tere will be 2 additional columns for that table which specify
> interpolation flags for grids- but this is not an issue here since 
> you said you are running 5.7.1.
> 
> The interface to dcgrib2 is provided in the "dcgrib2 -h" output, and
> otherwise, since it uses the table structure etc of the "nagrib"
> program- you can obtain additional information there. The nagrib program
> is capable of reading grib data from a file, while dcgrib2 was 
> written to allow reading from an input stream as well as do other 
> tasks such as stiching together grids such as the WAFS octets and 
> using file name templates.
> 
> Steve Chiswell
> Unidata User Support
> 
> On Wed, 2005-04-27 at 08:50, Guilherme O. Chagas wrote:
> > Hi Steve,
> > 
> > I've followed your instructions, but it seems like cptec's grib pds octet #4
> > really is 254. I'm sending the dcgrib2 log and the screen output (log-v4.1).
> > By the way, where can I find an extensive documentation about dcgrib?
> > Thanks for your help.
> > 
> > Best Regards,
> > ___________________________
> >         Guilherme O. Chagas
> >                 address@hidden
> > 
> > On 26 Apr 2005 14:03:30 -0600, Steve Chiswell wrote
> > > 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
> > > >

--- End Message ---