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.
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 >