[gradsusr] SDF file does not have any non-coordinate variables

Jennifer Adams jma at cola.iges.org
Wed Feb 9 12:07:15 EST 2011


Dear Steve,
This uncovered a bug in the sdfopen code that was stomping on memory  
(thereby erasing the variable name) when the variables long_name was  
more than 128 characters (a limit imposed by GrADS).  The workaround  
until the next release is to use 'open' with a full descriptor file  
(using dtype netcdf) instead of 'xdfopen'. The descriptor I used for  
the file you gave me is:

dset ^ts.nc
title sample
undef -9.99e+8
dtype netcdf
xdef 144 linear 0 2.5
ydef 96 linear -90 1.89474
zdef 1 linear 0 1
tdef 1 linear 00Z01JAN2000 1mo
vars 1
TS=>ts  0  t,y,x  Surface temperature (radiative)
endvars

While debugging this problem, I found that some the metadata in the  
file sample was somehow corrupted, perhaps by the netcdf operators  
used to tweak it. For example, an attribute named "units" of type  
NC_CHAR has a value of "K" but a length of 256. Inaccuracies in the  
length of metadata values was what led me to the bug. Strange things  
were wrong with your file that were not apparent from examining the  
ncdump output. Your best bet is to use the 'dtype netcdf' descriptor,  
so that GrADS does not rely on any of the metadata in the file.
--Jennifer




On Feb 8, 2011, at 3:04 PM, Ghan, Steven J wrote:

> I found a version of ncatted that can read my file. I removed the  
> calendar attribute. I can now open the file with sdfopen (which is a  
> great improvement), but grads is still not getting the variable  
> names. I am going to provide this file to Jennifer to see if she can  
> reproduce the problem.
>
> -Steve Ghan
>

--
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/20110209/724fd29b/attachment-0003.html 


More information about the gradsusr mailing list