Error in creating netCDF for GrADS reading
Jennifer Adams
jma at COLA.IGES.ORG
Tue Jan 5 11:46:24 EST 2010
On Jan 5, 2010, at 11:35 AM, Owen Doherty wrote:
> Dear Jennifer et al,
>
> Thanks for your help. Here is the information you requested.
>
> 1) ncdump output (omitting the data section for space constraints,
> but that looks good)
> owen at graupel:~/data/barbados$ ncdump -c test_ncgen6.nc
> netcdf test_ncgen6 {
> dimensions:
> longitude = 144 ;
> latitude = 73 ;
> t = 31 ;
> z = 9 ;
> variables:
> double longitude(longitude) ;
> longitude:units = "degrees_east" ;
> double latitude(latitude) ;
> latitude:units = "degrees_north" ;
> double t(t) ;
> t:units = "seconds since 1970-1-1 00:00:00" ;
> double z(z) ;
> z:units = "lev" ;
> z:valid_range = 200., 1000. ;
> float omejjam(longitude, latitude, t, z) ;
Your variable has no attributes! That's a really bad file-writing
practice. What is omejjam? Also, your data are written out with a
highly unconventional axis order: x,y,t,z. Is that intentional? Are
you sure Matlab is writing it out that way?
> data:
>
> 2) Control files first for XDF and then for CTL
>
> DSET ^test_ncgen6.nc
> DTYPE netcdf
> TITLE This is a test
> UNDEF -9999
> XDEF longitude 144 LINEAR 0.0 2.5
> YDEF latitude 73 LINEAR -90.0 2.5
> TDEF t 31 LINEAR 0Z01JUN1979 1YR
> ZDEF z 9 LEVELS 1000 925 850 700 600 500 400 300 250
> VARS 1
> omejjam=>ome 9 99 longitude,latitude,t,z seasonal mean vertical
> motion
> ENDVARS
>
> DSET ^test_ncgen6.nc
> DTYPE netcdf
> TITLE This is a test
> OPTIONS little_endian
> UNDEF -9999
How do you know this is the undef value? What if you put 9e36 (or
whatever the actual data value is that is causing GrADS to chose those
contour intervals ... find out what the right missing value is in your
file.
> XDEF 144 LINEAR 0.0 2.5
> YDEF 73 LINEAR -90.0 2.5
> TDEF 31 LINEAR 0Z01JUN1979 1YR
> ZDEF 9 LEVELS 1000 925 850 700 600 500 400 300 250
> VARS 1
> omejjam=>ome 9 x,y,z,t seasonal mean vertical motion
> ENDVARS
>
> 3) Version of Grads: Version 2.0.a5.oga.5
>
> 4) Error message received:
> No error exactly, but rather all the data is displayed as 0 to 9e+36
> interval 1e+36 instead of the actual values.
>
> Thanks again,
>
> Owen
>
> Jennifer Adams wrote:
>> Hi, Owen --
>> It sounds like you have a problem specifying the undef value in
>> your data file. I can't help with the Matlab bit, but if you need
>> help to figure out why GrADS can't read your file, you need to post:
>> 1. The output from ncdump -c on your file (in case Matlab changes
>> the metadata in some way)
>> 2. Your descriptor file (if you are using 'open' with 'dtype
>> netcdf' or 'xdfopen'). 3. The version of GrADS that you are using
>> 4. The text from the GrADS session that illustrates the error.
>> Jennifer
>>
>>
>> On Jan 4, 2010, at 6:31 PM, Owen Doherty wrote:
>>
>>> Dear Grads Users,
>>>
>>> I am having difficulties creating and writing to a netcdf file
>>> that can be read by GrADS. The data is loaded into GrADS
>>> successfully, but when displayed looks similar to improperly
>>> written binary data (e.g. all data is in the range of 0 to 9e+36
>>> interval 1e+36). Below are the steps I take to create a 4-D
>>> gridded netCDF, write to the netCDF and finally to read the file
>>> into GrADS.
>>>
>>> First, I create an nc file using the ncgen utility. I have tried
>>> creating netCDF files with the variable both as "float" and
>>> "double" neither of which is successful and the errors from which
>>> appear to be similar. Below is my source code (.cdl file) for
>>> this step.
>>>
>>> netcdf test_ncgen{
>>> dimensions:
>>> longitude=144;
>>> latitude =73;
>>> t=31;
>>> z=9;
>>>
>>> variables:
>>> double longitude(longitude);
>>> longitude:units = "degrees_east";
>>>
>>> double latitude(latitude);
>>> latitude:units = "degrees_north";
>>> double t(t);
>>> t:units = "seconds since 1970-1-1 00:00:00";
>>> double z(z);
>>> z:units = "lev";
>>> z:valid_range = 200.,1000.;
>>>
>>> float omejjam(longitude, latitude, t, z) ;
>>> data:
>>> omejjam = 0;
>>>
>>> Secondly, I write to the netCDF file using MATLAB. The write step
>>> is fairly simple and I suspect that I am missing something in here
>>> to have it write out as binary. I have tried outputting single
>>> precision (float) and double precision data from MATLAB both of
>>> which result in the same error. I am using MATLAB 2008b to do the
>>> writing. The write command is as follows:
>>>
>>> nc=netcdf.open('test_ncgen.nc','nc_write');
>>> [varname, xtype, dimids, numatts] = netcdf.inqVar(nc,4)% 0 - omejjam
>>> netcdf.putVar(nc,4,omejjam);
>>>
>>> Lastly, I read the data into GrADS. I have tried using sdfopen,
>>> xdfopen and the regular open command. Adding the OPTION
>>> little_endian to the control file does not solve the issue. All
>>> of the data looks erroneous, but consistent in between each
>>> different open command. If anyone has any advice as to how to
>>> solve this problem, I would be grateful for the insight.
>>>
>>> Owen
>>>
>>> --
>>> Owen Doherty
>>> School of Marine and Atmospheric Science
>>> Institute for Terrestrial and Planetary Atmospheres
>>> 103 Discovery Hall
>>> Stony Brook University
>>> Stony Brook, NY 11794
>>> (631)-632-8682 (office)
>>
>> --
>> Jennifer M. Adams
>> IGES/COLA
>> 4041 Powder Mill Road, Suite 302
>> Calverton, MD 20705
>> jma at cola.iges.org <mailto:jma at cola.iges.org>
>>
>>
>>
>
>
> --
> Owen Doherty
> School of Marine and Atmospheric Science
> Institute for Terrestrial and Planetary Atmospheres
> 103 Discovery Hall
> Stony Brook University
> Stony Brook, NY 11794
> (631)-632-8682 (office)
--
Jennifer M. Adams
IGES/COLA
4041 Powder Mill Road, Suite 302
Calverton, MD 20705
jma at cola.iges.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20100105/dbb57c76/attachment.html
More information about the gradsusr
mailing list