[Paraview] d3 poor domain decomposition

[Burlen Loring]

Hi John,

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

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.

Burlen

On 05/10/2013 02:06 PM, Biddiscombe, John A. wrote:
>
> Burlen, Ken, List
>
> **
>
> *>*
>
> 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.
>
> <
>
> This is my own experience too.
>
> Question: What would you like to see in the output
>
> 1)Existing behaviour, each block is partitioned separately, previous 
> multiblock structure is preserved
>
> 2)All blocks partitioned as a single block, no multiblock structure in 
> the output
>
> 3)All blocks partitioned as a single block, multiblock structure from 
> input regenerated based on a block Id assigned to each cell prior to 
> partitioning.
>
> 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.
>
> JB
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20130510/d81ffa2f/attachment.htm>