<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Dear Steve,</div><div>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:</div><div><br></div><div><div><font class="Apple-style-span" face="Courier" size="3"><span class="Apple-style-span" style="font-size: 12px;">dset ^ts.nc</span></font></div><div><font class="Apple-style-span" face="Courier" size="3"><span class="Apple-style-span" style="font-size: 12px;">title sample</span></font></div><div><font class="Apple-style-span" face="Courier" size="3"><span class="Apple-style-span" style="font-size: 12px;">undef -9.99e+8</span></font></div><div><font class="Apple-style-span" face="Courier" size="3"><span class="Apple-style-span" style="font-size: 12px;">dtype netcdf</span></font></div><div><font class="Apple-style-span" face="Courier" size="3"><span class="Apple-style-span" style="font-size: 12px;">xdef 144 linear 0 2.5</span></font></div><div><font class="Apple-style-span" face="Courier" size="3"><span class="Apple-style-span" style="font-size: 12px;">ydef 96 linear -90 1.89474</span></font></div><div><font class="Apple-style-span" face="Courier" size="3"><span class="Apple-style-span" style="font-size: 12px;">zdef 1 linear 0 1</span></font></div><div><font class="Apple-style-span" face="Courier" size="3"><span class="Apple-style-span" style="font-size: 12px;">tdef 1 linear 00Z01JAN2000 1mo</span></font></div><div><font class="Apple-style-span" face="Courier" size="3"><span class="Apple-style-span" style="font-size: 12px;">vars 1</span></font></div><div><font class="Apple-style-span" face="Courier" size="3"><span class="Apple-style-span" style="font-size: 12px;">TS=>ts 0 t,y,x Surface temperature (radiative)</span></font></div><div><font class="Apple-style-span" face="Courier" size="3"><span class="Apple-style-span" style="font-size: 12px;">endvars</span></font></div></div><div><br></div><div>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. </div><div>--Jennifer</div><div><br></div><div><br></div><div><br></div><br><div><div>On Feb 8, 2011, at 3:04 PM, Ghan, Steven J wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>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.<br><br>-Steve Ghan<br><br></div></blockquote></div><br><div apple-content-edited="true"> <div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-size: 12px; "><div>--</div><div>Jennifer M. Adams</div><div>IGES/COLA</div><div>4041 Powder Mill Road, Suite 302</div><div>Calverton, MD 20705</div><div><a href="mailto:jma@cola.iges.org">jma@cola.iges.org</a></div><div><br class="khtml-block-placeholder"></div><br class="Apple-interchange-newline"></div> </div><br></body></html>