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.
> Hi Steve, > > Yes we are using 5.9.1, running on RedHat Linux. "uname -a" shows > 2.6.9-22.ELsmp for the Linux kernal. > > I put one of our GRIB-2 files out on an exposed web server. Just click > on this link to save it to your local disk: > > http://wems.us.wni.com/2006042815_024.gr2 > > Thanks for your help. By "local use section", are you referring to > Section 2 GRIB-2 data? We don't use the section 2 local use > information. We do use 1 local GRIB table for a couple of parameters > not defined by WMO. > > Best regards, > > Brent > > Brent, I found the problem which is that the second vertical level in the product definition template of your data (eg gfld->ipdtmpl[12]) is contains a value of "0" for missing, while "255" is the expected missing value when a vertical coordinate only have 1 level (eg, in the $GEMTBL/grid/g2vcrdwmo1.tbl table, the second column). So, there are no matching vertical coordinates defined. You can change your generation, or "temporarily" add some entries into the vertical coordinate table util that is resolved. In my previous message, I was referring to the G2 local defined section 2, which your grib poducts all define as being present (with length 3), so if you aren't using that, you should check that out. Steve Chiswell Unidata User Support Ticket Details =================== Ticket ID: KRJ-399065 Department: Support GEMPAK Priority: High Status: Closed