Re: Reading GRIB2 data

To: Ethan Davis <edavis@xxxxxxxxxxxxxxxx>
Subject: Re: Reading GRIB2 data
From: Robb Kambic <rkambic@xxxxxxxxxxxxxxxx>
Date: Tue, 20 May 2008 13:07:15 -0600 (MDT)
Cc: John Caron <caron@xxxxxxxxxxxxxxxx>, decoders <support-decoders@xxxxxxxxxxxxxxxx>
Delivered-to: support-decoders@unidata.ucar.edu (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laraine.unidata.ucar.edu (Postfix) with ESMTP id B9C3CCB18A; Tue, 20 May 2008 13:07:15 -0600 (MDT) by wcfields.unidata.ucar.edu (8.14.2/8.13.8) with ESMTP id m4KJ7Fr4009750; Tue, 20 May 2008 13:07:15 -0600 by wcfields.unidata.ucar.edu (8.14.2/8.14.2/Submit) with ESMTP id m4KJ7FKR009745; Tue, 20 May 2008 13:07:15 -0600
In-reply-to: <483317DD.7030802@unidata.ucar.edu>
References: <483317DD.7030802@unidata.ucar.edu>

On Tue, 20 May 2008, Ethan Davis wrote:

Hi Robb,
A few questions on GRIB2 and reading it through the netCDF-Java library:
1) Is each GRIB record individually compressed?

yes

So, each level of each field

is separately compressed?

yes, so if a parm has 30 levels it requires 30 different data reads to get all the levels

2) What information is in the index files? Parameter id, levels, grid definition, and of course the location in the file? The reason I'm asking is I'm wondering if there are any times the actual GRIB file has to be opened other than when data values are requested?

Section 2 Grib records one line for each record in the file blank separated ProductType Discipline Category Parameter TypeGenProcess LevelType1 LevelValue1 LevelType2 LevelValue2 ReferenceTime ForecastTime Gdskey GdsOffset PdsOffset

noop, the only time the file needs to be opened is when data is requested.

3) Once a GRIB2 dataset is opened and data is requested for one level of one parameter, does that uncompressed data get cached in-case other requests for the same level and parameter are made?

the index is cached but i don't think the data is cached because it's large. John handles that part


4) Are the decompressed records in memory or on disk?

they are represented by offsets to a RAF, there is some caching by the RAF.

robb...

That's it for now.

Thanks,

Ethan

--
Ethan R. Davis                                Telephone: (303) 497-8155
Software Engineer                             Fax:       (303) 497-8690
UCAR Unidata Program Center                   E-mail:    edavis@xxxxxxxx
P.O. Box 3000
Boulder, CO  80307-3000                       http://www.unidata.ucar.edu/
---------------------------------------------------------------------------


===============================================================================
Robb Kambic        			   Unidata Program Center
Software Engineer III			   Univ. Corp for Atmospheric Research
rkambic@xxxxxxxxxxxxxxxx		   WWW: http://www.unidata.ucar.edu/
===============================================================================

Prev by Date: [netCDFDecoders #URO-892112]: Bug in BUFR table reading code
Next by Date: Re: your request to subscribe to "BUFRLIB support"
Previous by thread: [netCDFDecoders #URO-892112]: Bug in BUFR table reading code
Next by thread: Re: your request to subscribe to "BUFRLIB support"
Index(es):
- Date
- Thread

				Unidata is a member of the UCAR Office of Programs, is managed by the University Corporation for Atmospheric Research, and is sponsored by the National Science Foundation.
				P.O. Box 3000 • Boulder, CO 80307-3000 USA • Tel: 303-497-8643 • Fax: 303-497-8690