This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
--- 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 ---