Mehmet sent us the ECHAM file.
[0] Mehmet ... who/what created this grib file? Did the model out this
file or was a tool used to subset the data?
[1]
NCL does have an issue with the gaussian latitudes on this file.
At this time, it is thought to be a 'bug'. Unfortunately, a code
freeze for the soon to be released v5.2.0 is in effect. This means
that a fix is *not* likely to make it into the 5.2 release.
[2]
Possibly, the CDO may have a problem with the variables on the GRIB
file. The following explains why I say this.
===
Background file info:
netCDF rules *require* that all names on a file be *unique*.
HDF/HDF-EOS allows a file to have multiple variables with the same
but they must be in different 'directories/structures' on the file.
GRIB-1 is a *record format* ... *not a file format*
In fact, each GRIB-1 record pertains to a 2-dimensional 'horizontal'
field [eg, single pressure level]. The creation of 3, 4 or 5 dimensional
arrays by NCL and CDO is done 'under the hood' by reading the 2d
grib records and merging the times and levels.
NCL creates rather awkward ['ugly'] variable names that have multiple
parts separated by underscores (_). There is a reason for this. It
assures that all variable names in a file will be unique ... a netCDF
requirement.
Details on GRIB names: Read the GRIB section of:
http://www.ncl.ucar.edu/Document/Manuals/Ref_Manual/NclFormatSupport.shtml
There are *two* precipitation variables on the ECHAM file. They have
identical GRIB level_indicator, gds_grid_type, parameter_number and
parameter_table_version. One precipitation variable is a forecast field
that has 8 (forecast) time steps associated with it. The other is an
initial precipitation field that has 2884 (initial) time steps
If the CDO creates one field 'prec' it looks like it merges
these 2 variables as one [2884+8=2892]
NCL recognizes this distinction and creates two separate variables. Each
variable has its' unique time steps. An edited [for brevity]
ncl_filedump yields
filename: pr_A1_EUROPE
path: pr_A1_EUROPE.grb
file global attributes:
dimensions:
forecast_time0 = 8
g4_lat_1 = 24
g4_lon_2 = 58
initial_time3_hours = 2884
variables:
float A_PCP_GDS4_SFC ( forecast_time0, g4_lat_1, g4_lon_2 )
long_name : Total precipitation
units : kg/m^2
_FillValue : 1e+20
initial_time : 01/01/1860 (00:00)
float A_PCP_GDS4_SFC_10 ( initial_time3_hours, g4_lat_1,g4_lon_2 )
long_name : Total precipitation
units : kg/m^2
_FillValue : 1e+20
forecast_time : 0
forecast_time_units : minutes
double initialqtime3_hours ( initial_time3_hours )
long_name : initial time
units : hours since 1800-01-01 00:00
integer forecast_time0 ( forecast_time0 )
long_name : Forecast offset from initial time
units : days
=======================
It looks like the CDO mergesd the
On 04/01/2010 03:53 AM, Carlos A. F. Marques wrote:
> Hello Mehmet,
>
> I don't know what is happening in your case. I'm not an
> expert in either NCL or CDO. Also, in a previous message
> someone has told (I think it was Dennis) that there was
> some issue with your files related to the initial warning
> message you got - warning:GdsGAGrid:
>
> I can tell you that I've used CDO to remap ECHAM5 data
> (and other models) from Gaussian grid (T63) to the fixed
> grid (2.5 x 2.5) and it works fine. This remapping (or
> regridding) can also be done with NCL using for example
> function "g2fsh", but only in the case of global data. I
> have compared the results of remapping global data from
> Gaussian grids to the fixed grid (2.5 x 2.5) using both
> CDO (that uses a conservative remapping scheme) and NCL
> (uses spherical harmonics) and they are fairly similar.
>
>
> Carlos
>
>
> Em Thu, 01 Apr 2010 10:44:29 +0200
> Mehmet Coskun<mehmet.coskun@ufz.de> escreveu:
>> Hello Carlos,
>>
>> Thank you,
>>
>> cdo works well after converting netcdf I think I got
>> values, but
>> attribute names were totally changed ,
>>
>> for example when I read grb file with NCL
>>
>> Total Size: 64 bytes
>> 8 values
>> Number of Dimensions: 1
>> Dimensions and sizes: [8]
>> Coordinates:
>> (0) forecast_time0
>> (1) g4_lon_2
>> (2) g4_lat_1
>> (3) initial_time3
>> (4) initial_time3_encoded
>> (5) initial_time3_hours
>> (6) A_PCP_GDS4_SFC_10
>> (7) A_PCP_GDS4_SFC
>>
>> But after converting netcdf attributes names;
>>
>> Total Size: 32 bytes
>> 4 values
>> Number of Dimensions: 1
>> Dimensions and sizes: [4]
>> Coordinates:
>> (0) prec
>> (1) time
>> (2) lat
>> (3) lon
>>
>>
>> dimension of time variables increase from 2884 to 2892
>>
>> netcdf: time(2892) from 15 to 88008.5,
>> Dimensions and sizes: [time | 2892]
>> Coordinates:
>> time: [ 15..88008.5]
>> Number Of Attributes: 2
>> units : days since 1860-01-01 00:00:00
>> calendar : proleptic_gregorian
>>
>> but
>> grib: initial_time3_encoded(2884) from 1860091600 to
>> 2100121612
>>
>> grid type Gaussian Latitude/Longitude Grid (24 x 58),
>> should I remap this grid, does it not contain same
>> geographic coordinate which meteorological station has,
>>
>> thank you
>>
>>
>> Best regard
>>
>> mehmet
>>
>>
>>
>>
>>
>> Carlos A. F. Marques wrote:
>>> Hi Mehmet,
>>>
>>> You can easily remap the ECHAM5 Gaussian grid to a fixed
>>> grid with the
>>> Climate Data Operators (CDO), freely available at:
>>> http://www.mpimet.mpg.de/fileadmin/software/cdo/
>>>
>>> Example: Using CDO to remap data from Gaussian grid to a
>>> fixed grid
>>> (say, 2.5 by 2.5 => r144x73).
>>>
>>> First you can convert the grib files to netCDF as:
>>>
>>> cdo -f nc copy ECHAM5_in.grb ECHAM5_in.nc
>>>
>>>
>>> For the remapping use:
>>>
>>> cdo gencon,r144x73, ECHAM5_in.nc weights.nc
>>> cdo remap,r144x73,weights.nc ECHAM5_in.nc ECHAM5_out.nc
>>>
>>> The data in ECHAM5_out.nc will be in a 2.5 by 2.5 fixed
>>> grid.
>>>
>>> Good luck
>>>
>>> Carlos
>>>
>>>
>>>
>>> Em Wed, 31 Mar 2010 17:07:34 +0200
>>> Mehmet Coskun<mehmet.coskun@ufz.de> escreveu:
>>>> Hi,
>>>> I tried to read ECHAM5 grib file which is Gaussian
>>>> Latitude/Longitude
>>>> Grid , I got a warning message;
>>>>
>>>> !! warning:GdsGAGrid: Gaussian latitude coordinate array
>>>> is partially
>>>> or wholly undefined
>>>>
>>>>
>>>> Also my lattitute are not geographic latitute, How can I
>>>> convert
>>>> Gaussian Latitude/Longitude Grid to regular grid?
>>>>
>>>> 1.440558e+32
>>>> 8.547921e-44
>>>> 2.224632e-37
>>>> 0
>>>> 2.224708e-37
>>>> 0
>>>> 0
>>>> 0
>>>> 0
>>>> 0
>>>> 0
>>>> 0
>>>> 2.224697e-37
>>>> 0
>>>> 0
>>>> 0
>>>> 0
>>>> 0
>>>> 6.866362e-44
>>>> 0
>>>> 1.853472e-37
>>>> 0
>>>> 2.22465e-37
>>>> 0
>>>>
>>>> thanks
>>>>
>>>> Best regard
>>>>
>>>> mehmet
>>>
>>> _________________________________
>>> Physics Department
>>> University of Aveiro.
>>> Campus Universitário de Santiago
>>> 3810-193 Aveiro.
>>> Portugal
>>> _________________________________
>>
>
> _________________________________
> Physics Department
> University of Aveiro.
> Campus Universitário de Santiago
> 3810-193 Aveiro.
> Portugal
> _________________________________
> _______________________________________________
> ncl-talk mailing list
> List instructions, subscriber options, unsubscribe:
> http://mailman.ucar.edu/mailman/listinfo/ncl-talk
-- ====================================================== Dennis J. Shea tel: 303-497-1361 | P.O. Box 3000 fax: 303-497-1333 | Climate Analysis Section | Climate & Global Dynamics Div. | National Center for Atmospheric Research | Boulder, CO 80307 | USA email: shea 'at' ucar.edu | ====================================================== _______________________________________________ ncl-talk mailing list List instructions, subscriber options, unsubscribe: http://mailman.ucar.edu/mailman/listinfo/ncl-talkReceived on Thu Apr 1 18:16:37 2010
This archive was generated by hypermail 2.1.8 : Wed Apr 07 2010 - 07:12:50 MDT