[Paraview] Even more Questions about ParaView on a Tiled Display
Wylie, Brian
bnwylie at sandia.gov
Mon Aug 7 17:13:35 EDT 2006
I wanted to interject a general comment.
D3 is a 'heavy weight' load balancing filter. It's really intended for
unstructured data and, right now, it will take vtkPolydata and turn it
to vtkUnstructuredGrid.
You might just want to run it once, right after the reader, and then run
'Extract Surface' to get back to vtkPolyData. You also might play with
the immediate mode and t-strip options to see if they make a big diff on
your rendering times.
Also, if your dataset has lots of files, you should see how it runs
without D3 at all, just for comparison. :)
Brian Wylie - Org 1424
Sandia National Laboratories
MS 0822 - Building 880/A1-J
(505)844-2238 FAX(505)845-0833
____ _ __
/ __ \____ _________ | | / (_)__ _ __
/ /_/ / __ `/ ___/ __ `/ | / / / _ \ | /| / /
/ ____/ /_/ / / / /_/ /| |/ / / __/ |/ |/ /
/_/ \__,_/_/ \__,_/ |___/_/\___/|__/|__/
Unleash the Beast
________________________________
From: paraview-bounces+bnwylie=sandia.gov at paraview.org
[mailto:paraview-bounces+bnwylie=sandia.gov at paraview.org] On Behalf Of
Moreland, Kenneth
Sent: Monday, August 07, 2006 3:01 PM
To: Randall Hand; Paraview List
Subject: RE: [Paraview] Even more Questions about ParaView on a
Tiled Display
0. I just finished incorporating your patch. Because it's
late, I'm going to wait until tomorrow to check it in.
1. There are two reasons that your memory usage is varying.
First, it is true that the memory is not freed-up from the Cut
operation. The same is true of the data between reader and the first
D3. Second, if the number of processes you have is not a power of 2,
than D3 is not perfect at distributing your data. You can have up to
twice as much data on one node as the other.
2. It does seem strange that one would be so different than the
other 12. I don't have a good explanation for that.
3. I'm guess that has to do with your MPI implementation. It
looks like it forks a couple of times. I notice that of the 3
processes, only one is running. The other 2 may be parents that have
forked and are now waiting (perhaps as a precaution in case the MPI job
crashes and needs to be shut down cleanly).
4. That sounds like a glitch. Go ahead and submit a bug report.
-Ken
________________________________
From: paraview-bounces+kmorel=sandia.gov at paraview.org
[mailto:paraview-bounces+kmorel=sandia.gov at paraview.org] On Behalf Of
Randall Hand
Sent: Monday, August 07, 2006 2:28 PM
To: Paraview List
Subject: [Paraview] Even more Questions about ParaView on a
Tiled Display
Ok, so I've got my Mullions code (still looking for any comments
about that) working on our RenderWall and I'm noticing some interesting
behaviour that i've got some questions about.
In this cluster, we have 12 nodes + 1 head node, each one
connected via a GeForce 7800GTX to a 1600x1200 LCD Display. Each node
has 2 single-core Xeon processors Hyperthreaded, for an "effective" 4
cores, and 8G of ram. All connected via Infiniband. I've loaded up 2
PVTP datasets:
a) Dataset A is a 52Million Triangle 24-part surface, RGB per
point
b) Dataset B is a 67Million Triangle 12-part surface, no data
per point (Geometry only)
(Both datasets were load-balanced with Paraview's D3 filter.)
Now when I load them in Paraview, with a Tiled Display, they
both load and I'm able to interact with them beautifully. 119Million
Triangles rendered in 1s (for a still frame). I applied a cutting plane
to one of them, and then another D3 (to balance the newly cut surface,
right?), and the results are still fabulously interactive. But a few
things i've noticed:
1) Even tho the results are now "load balanced" again (via the
D3), my memory usage is still fairly varying. I'm seeing numbers
ranging from 1.8G to 3.8G on various nodes. Is this because the memory
isn't really freed-up from the Cut operation?
2) One of my 12 nodes is basically "idle". While the other 11
nodes show runtimes of over 250minutes on the pvserver process, one node
shows less than 5. Images are visible on all 12 displays.
3) On every node I have 3 processes. 4 I would understand, and
1 I had expected. But 3? It seems one is for the Rendering & MPI work,
while the other 2 are for computations (one has the usual spinlock
runtime of 250+minutes, while the others have 0.00).
An example:
[rhand at plasma proc]$ pdsh -a top -b -n1 | grep pvserver | sort
plasma01ib: 18580 rhand 25 0 1969M 1.9G 21052 R 25.0
25.0 275:25 1 pvserver
plasma01ib: 18581 rhand 25 0 1969M 1.9G 21052 S 0.0
25.0 0:00 3 pvserver
plasma01ib: 18582 rhand 25 0 1969M 1.9G 21052 S 0.0
25.0 0:00 3 pvserver
plasma02ib: 18367 rhand 25 0 1926M 1.9G 21052 R 25.0
24.5 275:22 1 pvserver
plasma02ib: 18368 rhand 25 0 1926M 1.9G 21052 S 0.0
24.5 0:00 0 pvserver
plasma02ib: 18369 rhand 25 0 1926M 1.9G 21052 S 0.0
24.5 0:00 0 pvserver
plasma03ib: 18407 rhand 25 0 3268M 3.2G 21052 R 25.2
41.7 275:20 1 pvserver
...(snip)...
plasma11ib: 20771 rhand 25 0 1997M 1.9G 21060 S 0.0
25.4 0:00 3 pvserver
plasma12ib: 18301 rhand 18 0 4161M 4.0G 21164 S 0.0
53.1 6:38 1 pvserver
plasma12ib: 18302 rhand 25 0 4161M 4.0G 21164 S 0.0
53.1 0:00 1 pvserver
plasma12ib: 18303 rhand 25 0 4161M 4.0G 21164 S 0.0
53.1 0:00 1 pvserver
4) While interacting, the 2D Scalar Bar seems to resize/move
down to the display closest the origin (lower-left corner), and then
return to it's desired location when the full-res image is rendered
again. Is this a glitch, or by design?
So can someone explain to me a bit of what's going on "behind
the curtain"? I've also had no luck chasing down what's going on with
the Slow Renderings &mangled options on tiled Displays (On the
production 2.4.4 release, not my customized mullion-enabled one)
--
----------------------------------------
Randall Hand
Visualization Scientist
ERDC MSRC-ITL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/paraview/attachments/20060807/bc44a517/attachment.html
More information about the ParaView
mailing list