<div dir="ltr"><div><div><div><div>Hi Tim,<br><br></div>If you build Catalyst with VTK_DEBUG_LEAKS enabled it is pretty good at finding VTK objects that aren't deleted properly. You should be able to run this with a small amount of calls to Catalyst as well. If you try this and want help understanding the output (if an object like a vtkUnstructuredGrid is leaked it will often give a whole bunch of false leaks that the unstructured grid is just holding the references to), just share your output file and I can take a look at it to try and narrow down the culprit. That may be slightly easier to use than Valgrind.<br><br></div><div>Beyond this, you could maybe try the same run but without doing any Catalyst work to see what happens then. That may be a lot of compute cycles but I'm not sure how else to try and bisect where the memory leak is occurring.<br></div><div><br></div>Initializing and finalizing Catalyst every time you want output would probably work but I'd think there may be significant overhead doing it like this. Plus, it's not really solving the problem -- just avoiding it.<br><br></div>Best,<br></div>Andy<br><div><div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 20, 2016 at 12:57 PM, Gallagher, Timothy P <span dir="ltr"><<a href="mailto:tim.gallagher@gatech.edu" target="_blank">tim.gallagher@gatech.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




<div dir="ltr">
<div style="font-size:12pt;color:#000000;background-color:#ffffff;font-family:Calibri,Arial,Helvetica,sans-serif">
<p>Hi,</p>
<p><br>
</p>
<p>One of our users is running a very big simulation and writing out images of two slices (two different views) every 1000 iterations and writing out the data for the two slices (two different data writers) as VTK files every 5000 iterations. It is using Paraview
 4.4. <br>
</p>
<p><br>
</p>
<p>After 21000 iterations, the simulation is killed because the memory on the compute nodes fills up. I usually know how to track down memory problems in our code using valgrind and related tools, but is that the right way to go to try and find this problem?</p>
<p><br>
</p>
<p>Are there any tips on how to isolate where the problem may be? I don't know if it is in the adapter, or in paraview itself. Has anybody encountered problems with runaway memory using Catalyst in 4.4 when writing images or VTK files?
<br>
</p>
<p><br>
</p>
<p>I know when we use pvpython to generate images and loop over many files, sometimes the memory also blows up and so we usually move the loop over the files outside the pvpython script and into a driver script that executes a new pvpython for each file. Is
 there a way to shut down/start up Catalyst each time it needs to write something? Is that advisable?
<br>
</p>
<p><br>
</p>
<p>Thanks,</p>
<p><br>
</p>
<p>Tim<br>
</p>
</div>
</div>

<br>_______________________________________________<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the ParaView Wiki at: <a href="http://paraview.org/Wiki/ParaView" rel="noreferrer" target="_blank">http://paraview.org/Wiki/ParaView</a><br>
<br>
Search the list archives at: <a href="http://markmail.org/search/?q=ParaView" rel="noreferrer" target="_blank">http://markmail.org/search/?q=ParaView</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/mailman/listinfo/paraview" rel="noreferrer" target="_blank">http://public.kitware.com/mailman/listinfo/paraview</a><br>
<br></blockquote></div><br></div>