Re: Quasi/thin grib 1 grids (fwd)

• To: bit-bucket <bit-bucket@xxxxxxxxxxxxxxxx>
• Subject: Re: Quasi/thin grib 1 grids (fwd)
• From: Robb Kambic <rkambic@xxxxxxxxxxxxxxxx>
• Date: Mon, 26 Feb 2007 10:16:49 -0700 (MST)

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

---------- Forwarded message ----------
Date: Thu, 22 Feb 2007 09:44:27 +0100
From: Simon Elliott <Simon.Elliott@xxxxxxxxxxxx>
To: Robb Kambic <rkambic@xxxxxxxxxxxxxxxx>
Subject: Re: Quasi/thin grib 1 grids

Hello Robb,

As I expect you realise, at EUMETSAT we don't produce and GRIB1 data.
Nevertheless, we are used to processing these data from ECMWF (center
98),
and so I hope we can help you out.

Usually, when octet 5 of the GDS is set to 255, it means the data are
on a regular grid
(with hte same number of grid points in each row) and that there are no
complex
vertical coordinates being used.  The data we use here come on "model"
levels
which are hybrid sigma (vertial) coordinates, and so octet 4 and 5 are
set accordingly.

If the model has 61 levels, and each is specified by two parameters,
this gives 122
vertical coordinate parameter, hence octet 4 (NV) would be 122.  It
would then be
necessary to put 33 in octet 5 (PV) to show that the vertical
coordiate
parameters being at this octet of Section 2.  As each parameter is
store in 4 octets,
the total length f the section would be 32 + (122 * 4) = 520, and this
value would
be stored in octets 1 to 3.

If you would like me to look at some specific data from ECMWF, perhaps
you could
send them to me or make them available for FTP collection.

Cheers,

Simon
(p.s. If you could make sure our help desk ops@xxxxxxxxxxxx is on copy
or
contacted directly, this would help to ensure a response from us)


Dr Simon Elliott
Product Implementation Manager
Operations Department
EUMETSAT
tel: (+49) 6151 807385
fax: (+49) 6151 807304

Robb Kambic <rkambic@xxxxxxxxxxxxxxxx> 21/02/2007 23:40:29 >>>

Hi Simon,

Can you point me to the GRIB1 documentation for eumetsat.  It seems to
be
a little different then the NCEP documentation for the GDS, especially
for
the Quasi/Thin grid processing.

The problem details for a Quasi Grib1 grid from center 98

In the GDS:
i know octet 5 != 255 means that this is a quasi grid. The information
for
the number of points is at the end of the GDS section. For NCEP grids,
i
get the number of parallels from the nx or ny depending on the scan
mode.
Then i read in the points using readUnsignedShort() for the values.
This
works for NCEP thin gribs, but ECMWF thin gribs give numbers in the
1000's. i know that is not correct. if i would use 3 octets to read in
the
values, the read would go past the length of the section. This doesn't
seem correct either.  i must be missing something here

GDS NV = 122  octet 4
GDS PL = 33  octet 5
GDS length =520
GDS  numPts = 181
GDS  numPV[ 0 ] = 0
GDS  numPV[ 1 ] = 0
GDS  numPV[ 2 ] = 16916
GDS  numPV[ 3 ] = 0
GDS  numPV[ 4 ] = 16934
GDS  numPV[ 5 ] = 27875
GDS  numPV[ 6 ] = 16959
GDS  numPV[ 7 ] = 42454
GDS  numPV[ 8 ] = 16991
GDS  numPV[ 9 ] = 41744
GDS  numPV[ 10 ] = 17030
GDS  numPV[ 11 ] = 31674
GDS  numPV[ 12 ] = 17076
GDS  numPV[ 13 ] = 38296



Thanks,
Robb...

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