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.
Henry,I answered Robert later on stating that I added the grib paramater table for the sample data that was given by url. Just for your information, the tables are added by configuration of center id, sub center id and table version number. The sample data had 7, 138, 130 numbers so the table referenced below will be added for the data. As long as the configurations are unique there's not a problem of adding tables. The data providers are responsible to make sure that their configuration is unique so there are no conflicts. The table format is the NWS ascii parameter table format.
1:PRES:Pressure [Pa]The next release will have your table included, I named it vic_138_v130.tab
RObb... Robert,Just so I don't forget about this issue, I added the table as vic_138_v130.tab under id 7, 138, 130.
The configuration can be changed at a later date. Robb... From: Robb Kambic <address@hidden> To: Robert B. Schmunk <address@hidden> <address@hidden> Subject: Re: [Fwd: Fwd: GRIB files with non-standard GRIBTAB files?] (fwd)ALPINE 2.00 MESSAGE TEXT Folder: sent-mail Message 96 of 104 78% NEW
Robert,Just so I don't forget about this issue, I added the table as vic_138_v130.tab under id 7, 138, 130.
The configuration can be changed at a later date. Robb... On Thu, 23 Jul 2009, Robert B. Schmunk wrote:
On Jul 23, 2009, at 14:30, Robb Kambic wrote: >> This solution is ok but I don't like requiring absolute path names. It
easier to add the table
> to the master list of tables in tablelookup.lst for the package. I have to agree with you. Also, the GSFC people who originally contacted me about the GRIBTAB issue were particuarly concerned aboutusers who wouldn't understand that they'd have to deal with GRIBTAB files to go with the GRIB datasets. However, they have also said they're somewhat new to GRIB themselves (or as they said, "we're more HDF folks") so it may be a while before you hear from Chris L. about adding to the master list. Thanks much for the help, rbs
On Fri, 24 Jul 2009, Fang, Hongliang {Henry}(GSFC-610.2)[R S INFORMATION SYSTEMS INC] wrote:
Dear Robb, We are trying to open some GRIB files with Panoply and IDV, however, we have problems with our
non-standard GRIBTABs. As directed by Robert Schmunk, I'm writing to ask how can we: 1) add our GRIBTABs to the netCDF-Java directory; and 2) how to "register" our GRIBTAB at runtime using Panoply or IDV.
Thank you for your instruction. Henry ________________________________________ From: Lynnes, Christopher S. (GSFC-6102) Sent: Thursday, July 23, 2009 9:09 AM To: Schmunk, Robert B. (GSFC-611.0)[SIGMA SPACE CORP] Cc: Fang, Hongliang {Henry}(GSFC-610.2)[R S INFORMATION SYSTEMS INC].; Vollmer, Bruce E. (GSFC-6102) Subject: Re: GRIB files with non-standard GRIBTAB files? OK, thanks for the info. This process has been very educational for us too (we're more HDF folks)... On Jul 22, 2009, at 8:16 PM, Robert B. Schmunk wrote:Chris, I went ahead and passed the question on to John Caron, who in turn forwarded it onto someone else at Unidata who is involved with the GRIB Decoder code. That is Robb Kamic, address@hidden The GRIB Java Decoder includes a directory full of GRIBTAB files, and Robb indicated that additional GRIBTABs could be added to that directory and included in their distribution "jar". That jar is in turn included in the netCDF-Java distribution and thence in Panoply. You should check with Robb to see what is required to get your GRIBTABs included. Otherwise, it turns out that there is a way to "register" a user's GRIBTAB file at runtime when using the GRIB Decoder. The big hitch with this is that 1) one has to know enough to do this, and 2) it has to be done before any GRIB files are opened. I would guess that this is not an optimal solution if you have users who are unfamiliar with GRIB and expect that all they have to do is open the dataset. (You could have counted me amongst that crowd just a few hours ago.) rbs On Jul 22, 2009, at 16:56, Christopher Lynnes wrote:Well, let us take a more detailed look at the issue, and maybe we'll submit something to support-netcdf-java. On Jul 22, 2009, at 4:21 PM, Robert B. Schmunk wrote:Chris, I think this is something you probably need to bring up with John Caron or the IDV developers at Unidata. I'm using John's netCDF-Java library for all interaction with GRIB and HDF datasets, along with netCDF datasets, and so I have minimal knowledge of how GRIB files are structured and what is expected to be in them. Since IDV is a Unidata product, it's no surprise that that app would have the same problem. I'll try throwing the question to John C. and see what he might say. rbs On Jul 22, 2009, at 15:12, Christopher Lynnes wrote:On Jul 22, 2009, at 3:02 PM, Christopher Lynnes wrote:Robert, We have some GRIB files with non-standard GRIBTABs. The problem is that when we read them in through Panoply, the variable names are wrong (as one would expect), but there is no way for the user to know that they are wrong, esp. users that are unfamiliar with GRIB. Any ideas?To amplify, we're wondering if octet 12 could be inspected for the Table Version number, and if other than 2, maybe just display the parameter index number instead of trying to look the name up. Or is this something that needs to be addressed to the netcdf library developers?Also, any idea on whether you will support reading in GRIB files with the associated GRIBTAB (aka parameter index) file? BTW, Panoply is not alone in this area; we have the same dilemma with IDV. We have some examples if you care to play with them, e.g.: Data file: ftp://agdisc.gsfc.nasa.gov/data/s4pa//GLDAS/GLDAS_VIC10_3H//2009/165/GLDAS_VIC10_3H.A2009165.2100.001.grb GRIBTAB file: http://disc.sci.gsfc.nasa.gov/hydrology/grib_tabs/gribtab_VIC.txt -- Christopher Lynnes NASA/GSFC, Code 610.2 301-614-5185-- Christopher Lynnes NASA/GSFC, Code 610.2 301-614-5185-- Robert B. Schmunk, address@hidden NASA Goddard Institute for Space Studies, 2880 Broadway, New York, NY 10025-- Christopher Lynnes NASA/GSFC, Code 610.2 301-614-5185-- Robert B. Schmunk, address@hidden NASA Goddard Institute for Space Studies, 2880 Broadway, New York, NY 10025-- Christopher Lynnes NASA/GSFC, Code 610.2 301-614-5185
=============================================================================== Robb Kambic Unidata Program Center Software Engineer III Univ. Corp for Atmospheric Research address@hidden WWW: http://www.unidata.ucar.edu/ ===============================================================================