[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fwd: Re: grib tables]



Greg Thompson wrote:

John et al,

The NCAR-RAL files are purely experimental and a place-holder
as the products migrate into true NCEP operations.  For that
reason, we have to accomodate a variety of situations.  The
good news is a copy of table2 (NCEP version) could be made then
modified locally for our ADDS use to solve any Thredds issue
we're having today.  As those rare EXP products mature through
the wickets, we can just keep altering our local copy of Table 2.
Is this a workable strategy?


should be fine - you just have to keep track of the tables and make sure you're 
using the right ones.



--Greg


On Thu, Jun 21, 2007 at 02:21:16PM -0600, John Caron wrote:
So if I understand the situation, the GRIB files really should be changed to indicate that they are using a different table. Greg, that a possibility? If so, we can add the NCAR/RAL table to the GRIB library release.
If not, the GRIB library can be confgured by the user to substitute the NCAR/RAL table. However, that means that real NCEP files will not be useable. 

Robb Kambic wrote:

can you comment on this? -------- Original Message --------
Subject: Re: grib tables
Date: Thu, 21 Jun 2007 08:52:36 -0600
From: Greg Thompson <address@hidden>
Organization: UCAR/Unidata
To: Rob Weingruber <address@hidden>
CC: address@hidden
References: <address@hidden>


Rob,

NCEP maintains what I refer to as the "GRIB bible."  It is "Office
Note 388" and I have two rather old copies in my office in a red
3-ring binder to the right of my desktop computer (lowest book
shelf).  You're welcome to look at the hard copy or download a more
recent one off web - should be pretty easy to locate on Google
using "GRIB Edition 1 Office Note 388."

The most problematic part of GRIB is the need for the various
a-priori lookup tables.  Specifically "TABLE 2" which holds the
names of the various weather variables.  Since the GRIB spec only
originally held 256 elements for these and NCEP has "bloated" the
table with duplicates and can never "retire" out of use elements, they
have since created a "secondary" table to hold more elements.  That
is now TABLE 129 I believe.  Somewhere in the GRIB "Product Description
Section (PDS)" [rather similar to MDV's field header] is an
element that determines whether to use Table 129 or Table 2 to
identify the parameter.

Here's the deal (I believe).  Thredds should be coded to allow a
local user to "override" the NCEP Table 2 (or 129) and refer to
some local version instead.  Given that the GRIB spec allows for
each "originating center" to produce its own Table 2, the need for
local variants of Table 2 is almost mandatory.  By the spec, elements
1-128 are "dictated" to be standardized by WMO and all originating
centers should leave those alone.  Each originating center is
"expected" to maintain their own 129-255 elements.  To my knowledge,
there's no single person at NCAR to "maintain" that NCAR-wide
table.  I was personally responsible for getting NCEP to enter us
(NCAR) as an originating center 13 years ago.

John will know all about Table 2 if he's dealt much in GRIB (I
expect he has).  He may not know that Table 2 got completely
filled and now Table 129 exists.  Regardless, I contend that
Thredds needs an inherent way to allow customization for local
use to "ingest" a user-defined Table 2.


Hiya,

The management of GRIB parameter tables is the weakest link in the GRIB
format. With that being said here's the THREDDS solution to the problem.

According to the file attached to the original message, here are the
variables in the file that designate which table to use.

center = 7 NCEP
sub_center = 0
table_version = 2

As stated, these files appear that they are coming from NCEP, so they use
the NCEP parameter table. Since this is not the table that is wanted to
decode the data, the user must overide the table with a local user defined
table. Here's a page that shows how to overide the tables:
http://www.unidata.ucar.edu/software/netcdf-java/tutorial/docGrib/tables/grib1tables.html
Once the table is overridden the only way to revert to the original table is to read in the original table again. 


Robb...






NCAR-Graphic's NCL software had this sort of defficiency when first
created and has since been altered to allow user-defined Table 2
data.

Now, part of the reason this mess may exist is because some GRIB files
arriving on ExpADDS are from NCAR-RAL, not NCEP.  Those may be
"pretending" to be NCEP originating center or they may correctly be
identified (in the PDS) and NCAR originating.  We generally don't
want to ask RAL developers to alter PDS elements because most times RAL
needs to set the final file as close to what NCEP will end up with
as possible.

I do know GRIB inside and out so it might be wise for 3 of us to
discuss in person if other questions arise.

-- Greg



On Wed, Jun 20, 2007 at 12:02:19PM -0600, Rob Weingruber wrote:

Greg -

Can you describe what you mean by those grib tables?  John is asking
whether or not we can fix the grib files to put in a more reasonable
name for the fields.  How do I respond?  Simply that he needs to
look into a different grib table for the field name?  Who's grib table?
I cant imagine that it's just John's code either, since it happens in the 
OPeNDAP arena too.  Anywho....
=============================================================================== 
Robb Kambic                       Unidata Program Center
Software Engineer III               Univ. Corp for Atmospheric Research
address@hidden           WWW: http://www.unidata.ucar.edu/
===============================================================================