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