On Feb 7, 2008 12:15 AM, Adam Sobel <<a href="mailto:ahs129@columbia.edu">ahs129@columbia.edu</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I have a set of netcdf files, each is 1 day. I have a .ctl file so I can<br>view a bunch of them together in sequence using xdfopen. The ctl file<br>is below.</blockquote><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
If I set t to the whole time range (in this case set t 1 12) I can view<br>the variables u or v just fine, e.g. make animations for the whole<br>period, looks good. But then if I do<br><br>define rvort=hcurl(u,v)<br><br>
I get a segmentation fault</blockquote><div><br>This is a well known problem in the v1.8/v1.9 series (but not v1.7b9 and new v2). There is a memory leak in the sdfopen/xdfopen part of the code that causes the amount of memory to increase with the size of the timeseries until you ran out of memory. (On a linux system you can watch this happen by opening another window and executing "top"). I usually experience this problem with much longer data sets, but all depends on your system load and horizontal resolution.<br>
<br>I have a patched a version of GrADS for use at NASA/GMAO which is built with the sdfopen/xdfopen code from v1.7b9 sdf/xdfopen code, with some of the bugfixes up to v1.9b4. Since it *may* not address all NetCDF files supported by v1.9b4, COLA recommended that this patch not be included in v1.9.0-rc1. Their recommended action is to prepare a ctl file with "DTYPE netcdf" and use the "open" command. Another option is the just released v2, but this version is still in active development and is not as stable as v1.9 yet. BTW, this problem is common to netcdf and hdf files alike.<br>
<br> Arlindo<br><br><br></div></div>-- <br>Arlindo da Silva<br><a href="mailto:dasilva@alum.mit.edu">dasilva@alum.mit.edu</a>