[Paraview] pvserver disconnecting...

Mon Feb 14 10:13:26 EST 2011

Yes, this seems to work very well! Thank you so much for the help!

Cheers,
Karl

On Fri, Feb 11, 2011 at 12:55 PM, Berk Geveci <berk.geveci at kitware.com>wrote:

> 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 <karlbattams at 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.marion at 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 <karlbattams at 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.marion at 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 <karlbattams at 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
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20110214/e40fadcb/attachment-0001.htm>