Yes, this seems to work very well! Thank you so much for the help!<div><br></div><div>Cheers,</div><div>Karl<br><br><div class="gmail_quote">On Fri, Feb 11, 2011 at 12:55 PM, Berk Geveci <span dir="ltr"><<a href="mailto:berk.geveci@kitware.com">berk.geveci@kitware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Actually, it may be leaking display properties. Try:<br>
<br>
Delete(dp)<br>
<br>
The best thing to do in scripts is to be consistent in whether you use<br>
the simple or the servermanager to create objects. If you use the<br>
simple module, make sure you call Delete(). If you are using<br>
servermanager, you don't have to call Delete().<br>
<br>
I think that this goes for the display properties. As soon as you call<br>
Show() or GetDisplayProperties(), the simple module will create a<br>
representation object and register it with what is called the proxy<br>
manager. By the way, calling Initialize() on the view is a bad idea.<br>
It doesn't do what you think it does. Do this:<br>
<br>
for infile in glob.glob( os.path.join(path, '*.vtk') ):<br>
print "Input file: " + infile<br>
<br>
# read the vtk file<br>
reader = LegacyVTKReader(FileNames=infile)<br>
Show(reader)<br>
dp = GetDisplayProperties(reader)<br>
<br>
# Create LUT<br>
dp.LookupTable = MakeBlueToRedLT(0, 1)<br>
<br>
# Set array to color by the model<br>
dp.ColorAttributeType = 'POINT_DATA'<br>
dp.ColorArrayName = 'Model'<br>
servermanager.createModule("piecewise_functions", servermanager.rendering)<br>
<br>
# Setup opacity function<br>
opacity_func = servermanager.rendering.PiecewiseFunction()<br>
opacity_func.Points = [0, 0, 1, 0.5]<br>
dp.ScalarOpacityFunction = opacity_func<br>
dp.Representation = 'Volume'<br>
<br>
view0 = GetActiveView()<br>
view0.Background =[0.57,0.61,0.77]<br>
<br>
# Set the camera and view options, etc<br>
view0.OrientationAxesVisibility=1<br>
view0.CenterAxesVisibility=1<br>
view0.ViewSize=[632,632]<br>
view0.CameraPosition = [430,420,310]<br>
view0.CameraFocalPoint = [-135,-125,-20]<br>
view0.CameraViewUp = [-0.26,-0.29,0.92]<br>
<br>
# Render<br>
Render()<br>
<br>
# write out the png file<br>
new=infile.replace('.vtk','.png') # use orig filename for png filename<br>
print "Output file: " + new<br>
WriteImage(new, view0)<br>
<br>
view0.Representations = []<br>
Delete(dp)<br>
Delete(reader)<br>
<div><div></div><div class="h5"><br>
<br>
On Fri, Feb 11, 2011 at 12:05 PM, Karl Battams <<a href="mailto:karlbattams@gmail.com">karlbattams@gmail.com</a>> wrote:<br>
> Pat,<br>
> Ah! That makes sense now I think about it.<br>
> So I put the call at the end of my routine, and it pukes after the first<br>
> file:<br>
><br>
> Traceback (most recent call last):<br>
> File "script.py", line 52, in <module><br>
> Delete(reader)<br>
> File "/usr/local/lib/paraview-3.11/paraview/simple.py", line 367, in<br>
> Delete<br>
> servermanager.UnRegister(proxy)<br>
> File "/usr/local/lib/paraview-3.11/paraview/servermanager.py", line 2674,<br>
> in UnRegister<br>
> raise RuntimeError, "UnRegistration error."<br>
> RuntimeError: UnRegistration error.<br>
><br>
> Thanks again,<br>
> ~~Karl<br>
><br>
> On Fri, Feb 11, 2011 at 11:47 AM, pat marion <<a href="mailto:pat.marion@kitware.com">pat.marion@kitware.com</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> Your loop is leaking readers. At the end of your loop, call<br>
>> Delete(reader). The Delete() function is analogous to selecting an object<br>
>> in the paraview gui and pressing the delete key. You'll still leak some<br>
>> objects, there are more thorough ways you cleanup, but deleting the reader<br>
>> make take care of the bulk of it. You can remove the Initialize() calls.<br>
>><br>
>> Pat<br>
>><br>
>> On Fri, Feb 11, 2011 at 7:31 AM, Karl Battams <<a href="mailto:karlbattams@gmail.com">karlbattams@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> Hi Pat,<br>
>>><br>
>>> Yes -- I should have gone with my first suspicion. It is indeed a memory<br>
>>> leak. I'm obviously not cleaning stuff up properly... which doesn't surprise<br>
>>> me because my script really is kind of a hack... I have attached it.<br>
>>> Basically it reads a directory of vtk files, loops over each, volume-renders<br>
>>> them with a fixed set of camera positions, and then saves a png.<br>
>>><br>
>>> One issue I was having was getting paraview to "forget" about the<br>
>>> previous vtk file. It was rendering each new image over the top of the<br>
>>> previous one. I fixed that by using Initialize( ) on the different views at<br>
>>> the end of the loop, but that is perhaps (probably!) not the right way to do<br>
>>> it.<br>
>>><br>
>>> Many thanks for your help!<br>
>>><br>
>>> Regards,<br>
>>> Karl<br>
>>><br>
>>> On Thu, Feb 10, 2011 at 3:08 PM, pat marion <<a href="mailto:pat.marion@kitware.com">pat.marion@kitware.com</a>><br>
>>> wrote:<br>
>>>><br>
>>>> Hi Karl,<br>
>>>><br>
>>>> It sounds like a memory leak problem. Have you tried opening the System<br>
>>>> Monitor in ubuntu and watching the memory usage of pvserver as you run your<br>
>>>> script? Can you post your script so we can take a look at it, maybe you<br>
>>>> aren't cleaning up after you process each file?<br>
>>>><br>
>>>> You can pass --cslog=log.txt to pvserver. This records very low level<br>
>>>> log information, it captures every message sent to the server. Problem is<br>
>>>> that it does not work very well for a parallel server, all processes all<br>
>>>> write to the same file.<br>
>>>><br>
>>>> pvserver exits when the client disconnects and there is no keep-alive<br>
>>>> flag. Try running pvserver in a bash loop, or starting it from your python<br>
>>>> script.<br>
>>>><br>
>>>> Pat<br>
>>>><br>
>>>> On Thu, Feb 10, 2011 at 1:46 PM, Karl Battams <<a href="mailto:karlbattams@gmail.com">karlbattams@gmail.com</a>><br>
>>>> wrote:<br>
>>>>><br>
>>>>> I'm pretty new to paraview so could be doing fundamentally wrong here,<br>
>>>>> but here's my issue...<br>
>>>>> I have paraview 3.10 compiled/installed from source on Ubuntu 10. I'm<br>
>>>>> using a python script to connect to pvserver, iterate over a bunch of vtk<br>
>>>>> files, do some stuff, and saving the output as a png. I'm running the python<br>
>>>>> script and the pvserver on the same (8-core) machine.<br>
>>>>> So I start pvserver with (e.g.) mpirun -np 6 pvserver and it sits<br>
>>>>> happily listening for a client. In another terminal, I run my python script<br>
>>>>> which connects (successfully) to pvserver, and starts running through the<br>
>>>>> files exactly as I ask it to. So far so good.<br>
>>>>> Problem is, after a random length of time, and/or number of files, the<br>
>>>>> pvserver abruptly dies and so the whole python script obviously dies with<br>
>>>>> it. The pvserver gives no error message... just dies. If I just run the<br>
>>>>> script for one file (or even a few of them), it runs without an issue.<br>
>>>>> What I have noticed is that the less processors I use, the more files<br>
>>>>> my script will process before pvserver dies. If I use pvserver by itself<br>
>>>>> (i.e. one processor) it will do about 120-or-so files. If I use four<br>
>>>>> processors, it'll only go through 30-or-so before one of them throws a kill<br>
>>>>> signal and takes the whole thing down. It is not a particular file that does<br>
>>>>> it, nor is it at a particular point in the processing script. The length of<br>
>>>>> time and number of files processed is also not fixed. (It's almost like it's<br>
>>>>> a memory leak issue..??)<br>
>>>>> So... questions:<br>
>>>>> 1) Am I being inefficient/stupid by using pvserver + python script to<br>
>>>>> do this batch processing? If so, what's the recommended practice?<br>
>>>>> 2) My script only does one server connect (via Connect('localhost') )<br>
>>>>> and then loops over the files. Should I do a new server connect for each<br>
>>>>> file instead?<br>
>>>>> 3) Assuming yes to question 2, how do I cleanly disconnect from<br>
>>>>> pvserver without killing the server altogether (see below)?<br>
>>>>> 4) If I run a single instance of file processing (i.e. one file) the<br>
>>>>> script runs fine... but when it's done, the pvserver disconnects the client<br>
>>>>> and dies. Is that normal? Is there a 'keep-alive' flag for pvserver? Why<br>
>>>>> does dropping the connection kill the server?<br>
>>>>> 5) Does pvserver leave any logs anywhere? Anyway I can trace what's<br>
>>>>> causing the kill signal?<br>
>>>>> I just can't shake the feeling that the pvserver process should be a<br>
>>>>> lot more robust than what I'm seeing.<br>
>>>>> Many thanks for any help!<br>
>>>>> Karl<br>
>>>>> _______________________________________________<br>
>>>>> Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
>>>>><br>
>>>>> Visit other Kitware open-source projects at<br>
>>>>> <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
>>>>><br>
>>>>> Please keep messages on-topic and check the ParaView Wiki at:<br>
>>>>> <a href="http://paraview.org/Wiki/ParaView" target="_blank">http://paraview.org/Wiki/ParaView</a><br>
>>>>><br>
>>>>> Follow this link to subscribe/unsubscribe:<br>
>>>>> <a href="http://www.paraview.org/mailman/listinfo/paraview" target="_blank">http://www.paraview.org/mailman/listinfo/paraview</a><br>
>>>>><br>
>>>><br>
>>><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
><br>
> Visit other Kitware open-source projects at<br>
> <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
><br>
> Please keep messages on-topic and check the ParaView Wiki at:<br>
> <a href="http://paraview.org/Wiki/ParaView" target="_blank">http://paraview.org/Wiki/ParaView</a><br>
><br>
> Follow this link to subscribe/unsubscribe:<br>
> <a href="http://www.paraview.org/mailman/listinfo/paraview" target="_blank">http://www.paraview.org/mailman/listinfo/paraview</a><br>
><br>
><br>
</div></div></blockquote></div><br></div>