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.gev...@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 <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