Re: problem of reading grb file

Shuhua -

As the "appropriate developer" I have examined this file, and as far as
I can tell, the current version of NCL is reading the file correctly and
giving the correct values for the "Total precipitation" data as well
as for
the various coordinates. We do not have available for testing NCL
version
4.0.2, which is very old now, but I did build a version with the code
prior to the code that includes the warning message you report. That
version produced identical values for the first time step of the
precipation
variable but bogus values for the latitude coordinates.

A note about the warning message:
This file seems to conform to the type of file available from the IPCC
Data
Distribution Centre: http://cera-www.dkrz.de/IPCC_DDC/

What the files on this site have (or had, last time I checked) in
common is that
they all, according to my understanding of the NCEP GRIB documentation,
incorrectly specify the Gaussian grid in the GRIB Grid Description
Section (GDS).
Specifically, they have an incorrect value in GDS octets 26-27.

This may get annoyingly technical but I'll step through it anyway, in
case someone
on this list can shed more light on the problem.

If you look at
http://www.nco.ncep.noaa.gov/pmb/docs/on388/tabled.html (Sundry Grid
Definitions)
the table that applies for Gaussian Grids is the first one.
It says that for a Gaussian grid octets 26-27 should contain
'N - number of latitude circles between a pole and the equator
Mandatory if Gaussian Grid specified'.

So NCL has always used this value to generate the Gaussian latitudes. 2
* N latitudes are
generated. The values of these latitudes are completely specified by
the number N according to
a formula. The actual latitudes used in the grid could be all or a
subset of the latitudes generated by
the formula, depending on the values (again referring to the GRIB
table) Nj, La1 and La2.

GDS octets 26-27 in this file have the value 20 for N, which results in
40 latitude values. But
Nj has the value 48: not a subset, or equal, but more latitudes than
are defined by the
formula. This is not possible. In fact, it appears that whoever created
these files expects that N should be taken as
Nj / 2, and that octets 26-27 should be ignored. If you do this,
then La1 and La2 match up with the
first and last generated Gaussian latitude values and all is okay.
Since all these IPCC grids are global
(i.e. all the generated latitude are used) this works, but you could
not have a subset of latitudes,
which is the purpose of requiring that N be specified ("Mandatory") by
the GRIB spec.
The warning is generated because the files do not conform to the spec,
but nevertheless
I believe that NCL interprets them correctly -- at least recent
versions of NCL do.

If you still question the actual data values, let me know.
  -dave

On Nov 10, 2005, at 1:23 PM, Dennis Shea wrote:

>> When I read a grb file using ncl
>>
>> tempa2f = addfile("CCCma_SRES_B2_PREC_1900-2100.grb","r")
>>
>> The following message is shown.
>>
>> warning:GdsGAGrid: Invalid value for Gaussian LatLon grid in GDS
>> octets
>> 26-27; inferring N from octets 9-10 (See GRIB Section 2 documentation)
>>
>> The current version of NCL is 4.2.0. However, the older version 4.0.2
>> has no such warning message. I retrieved data from some points, the
>> results from both versions are different.
> -------------------------
>
> The current version of ncl is 4.2.0.a032
> ^^^^
>
> I have read the file you sent via ftp using
> both a032 and the next release a033 both give
> the same *warning" message.
>
> Note: The data is read correctly despite the warning message.
>
> -----
> I will send the file to the appropriate NCL developer.
>
> Regards
> Dennis Shea
>
> _______________________________________________
> ncl-talk mailing list
> ncl-talk_at_ucar.edu
> http://mailman.ucar.edu/mailman/listinfo/ncl-talk

_______________________________________________
ncl-talk mailing list
ncl-talk_at_ucar.edu
http://mailman.ucar.edu/mailman/listinfo/ncl-talk
Received on Fri Nov 11 2005 - 13:03:20 MST