<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi Ken,<br>
<br>
Thanks for the help, you're right D3 is dividing each "dataset".
looking at the vtm file for this dataset, which was produced by
saving from an extract surface filter that was run on a grouped
set of 8 vts datasets while running pv in client-server with 8
ranks. In the vtm file each "piece" has 8 vtu "datasets". So d3 is
seeing what appears in the gui to be an 8 block multiblock dataset
as 64 items to divide individually, so running with 4 ranks this
produces 256 regions. When the surface data is generated in serial
with only one "dataset" per "piece" in the vtm file it works
wonderfully.<br>
<br>
While exploring this I've noticed that sometimes after d3 some
geometry is being dropped, not sure if that's occuring in d3 or
some point after, filed a bug report about that.
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a href="http://paraview.org/Bug/view.php?id=14061">http://paraview.org/Bug/view.php?id=14061</a><br>
<br>
Burlen<br>
<br>
<br>
On 05/10/2013 07:52 AM, Moreland, Kenneth wrote:<br>
</div>
<blockquote cite="mid:CDB26553.17999%25kmorel@sandia.gov"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div>
<div>
<div>I am guessing that this has to do with the blocks in your
multiblock dataset. The D3 filter will partition each block
independently. This means that each process will have a
small region in each partition, which will be spread
throughout the dataset.</div>
</div>
</div>
<div><br>
</div>
<div>Although not a good solution, one way around the problem
would be to first run the merge blocks filters to construct a
monolithic unstructured grid, and then run D3.</div>
<div><br>
</div>
<div>-Ken</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt;
text-align:left; color:black; BORDER-BOTTOM: medium none;
BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT:
0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid;
BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Burlen Loring
<<a moz-do-not-send="true" href="mailto:bloring@lbl.gov">bloring@lbl.gov</a>><br>
<span style="font-weight:bold">Date: </span>Thursday, May 9,
2013 5:36 PM<br>
<span style="font-weight:bold">To: </span>"<a
moz-do-not-send="true" href="mailto:paraview@paraview.org">paraview@paraview.org</a>"
<<a moz-do-not-send="true"
href="mailto:paraview@paraview.org">paraview@paraview.org</a>><br>
<span style="font-weight:bold">Subject: </span>[EXTERNAL]
[Paraview] d3 poor domain decomposition<br>
</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE"
style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0
0 0 5;">
<div>
<div bgcolor="#FFFFFF" text="#000000">I wanted to report a
situation where D3 is generating really poor domain
decomposition. In this case it's taking decent data
locality and destroying it. This is a multiblock with 8
polydata surfaces. Screen shot shows result with 4 mpi
ranks, 8 produces a similar result. D3 usually does a
great job, so maybe this has hit some of its weak spots.
I'm surprised that there are so many disconnected regions
on each rank and that it doesn't retain any of the initial
data locality. Although here I was just experimenting
trying to get a more even data distribution by using d3, I
think similar use cases arise frequently. for example the
need to re-balancing the data distribution after an
iso-surface in parallel. Should this be considered a bug?<br>
<br>
<img moz-do-not-send="true"
src="cid:part1.08060803.06010605@lbl.gov" alt=""><br>
<br>
<br>
<br>
<br>
</div>
</div>
</blockquote>
</span>
</blockquote>
<br>
</body>
</html>