<div dir="ltr">Hi Burlen,<div><br></div><div style>This sounds like a good use case for handling multi-block and multi-piece differently. The intent of multi-piece was to be a vehicle for parallelism (or other reasons for partitioning data) whereas multi-block was to represent intentional hierarchies. We haven't taken this to its logical conclusion so we are a bit in limbo when it comes to differentiating the two. I would encourage folks to think about this and move this functionality forward where it makes sense. It is definitely on my to do list to make progress on this within the next year or two.</div>
<div style><br></div><div style>In the case of D3, it should be doable to have D3 treat multi-piece datasets as one thing and repartition the whole thing freely across MPI ranks.</div><div style><br></div><div style>Best,</div>
<div style>-berk</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 10, 2013 at 6:13 PM, Burlen Loring <span dir="ltr"><<a href="mailto:bloring@lbl.gov" target="_blank">bloring@lbl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Hi John,<br>
<br>
In hind sight I think d3 is doing something reasonable. you have
quite a few use cases to support. when blocks are only a vehicle
for parallelism, the block structure doesn't matter and could be
ignored or done away with. when blocks describe physical
structures, assemblies, parts of a machines and so on, you will
have to retain the full heirarchy. perhaps a data partitioner
could make a better decomposition if there was a way to let the
user choose which level of structure he wants to retain and do the
best it can within that constraint...<br>
<br>
In my case ParaView had saved unexpected sub-block partitions, 1
dataset per rank within each block, in the vtm file based on how
many ranks were running at the time i extracted the surface (8
ranks x 8 blocks = 64 sub block partitions in the vtm file). But
when that file is loaded in PV it shows no evidence of this, both
composite index and process id correspond to the original 8
blocks. However d3 partitioned each of those sub-block partitions.
in my case 4 ranks 64 sub blocks = 256 partitions in all!
definitely not what I expected and I guess its a worst case
scenario for d3. I don't care about sub block partitioning
structure that PV used when I saved the data. But there's no way
the writer, reader, or d3 could know that.<span class="HOEnZb"><font color="#888888"><br>
<br>
Burlen</font></span><div><div class="h5"><br>
<br>
On 05/10/2013 02:06 PM, Biddiscombe, John A. wrote:<br>
</div></div></div><div><div class="h5">
<blockquote type="cite">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Burlen,
Ken, List<u></u><u></u></span></p>
<div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></b></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" lang="EN-US">><u></u> <u></u></span></b></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif"">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.</span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d"><<u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">This
is my own experience too.
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Question:
What would you like to see in the output<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>1)<span style="font:7.0pt "Times New Roman"">
</span></span></span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Existing
behaviour, each block is partitioned separately,
previous multiblock structure is preserved<u></u><u></u></span></p>
<p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>2)<span style="font:7.0pt "Times New Roman"">
</span></span></span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">All
blocks partitioned as a single block, no multiblock
structure in the output<u></u><u></u></span></p>
<p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>3)<span style="font:7.0pt "Times New Roman"">
</span></span></span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">All
blocks partitioned as a single block, multiblock
structure from input regenerated based on a block Id
assigned to each cell prior to partitioning.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The
reason I ask is because I’m working on a new
partitioning class and I have not yet handled
multi-block datasets and I wonder what ought to be
done in this case. 3) seems ideal, but is a bit harder
and might use some intermediate memory that would be
undesireable.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">JB<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the ParaView Wiki at: <a href="http://paraview.org/Wiki/ParaView" target="_blank">http://paraview.org/Wiki/ParaView</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.paraview.org/mailman/listinfo/paraview" target="_blank">http://www.paraview.org/mailman/listinfo/paraview</a><br>
<br></blockquote></div><br></div>