[Paraview] Some D3 and MPI questions

John Biddiscombe biddisco at cscs.ch
Mon Nov 20 11:42:27 EST 2006


I wrote
[lots of stuff deleted]

So I tried it and here's a clip of an animation that shows what I don't 
want.
ftp://ftp.cscs.ch/out/biddisco/flowviz/D3_Test_1.avi

The partitioning flips after the first 15 or so time steps, and then 
flips back. The distribution is very good (this snapshot doesn't show 
the rest of the data, but it is well balanced).

I'd like to say
D3->KeepTheseCuttingPlanes(planes from earlier)

and have the spatial regions always the same.

Can it be done, and if I'm willing to dig into the BSP code is there a 
clear point at which cellIDs can be stuffed into regions that are 
already defined? I want the spatial regions to be the same in each time 
step, because particle tracking across the regions is better if the 
spatial zones are not jumping about.

TIA

JB



> Part 1 : D3
>
> I'd like to add the DistributedDataFilter into one of our readers. It 
> cannot necessarily partition the data well at read time due to the 
> format of the data so having the readers do the distribution using D3 
> is my best bet.
> When the TimeStep changes, the geometry changes. I'd like to use the
>
> "// Enhancement: You can set the k-d tree decomposition, rather than
> // have D3 compute it.  This allows you to divide a dataset using
> // the decomposition computed for another dataset.  Obtain a description
> // of the k-d tree cuts this way:"
>
> Capability, to generate the BSP tree when the first time step is 
> loaded, and then re-use it when successive steps are loaded. However, 
> I'm slightly uncertain about one (actually more) thing.
> It goes on to say
> "  //    When this filter executes, it creates a vtkPKdTree (K-d tree)
>  //    data structure in parallel which divides the total distributed
>  //    data set into spatial regions.  The K-d tree object also creates
>  //    tables describing which processes have data for which
>  //    regions.  Only then does this filter redistribute
>  //    the data according to the region assignment scheme."
>
> Now as each time step is produced, one part of the mesh is rotating, 
> it occupies the same space, so the BSP partition should be fine 
> (providing some small tolerance is allowed for), but the 
> partitioning/allocation of cells between the spatial regions is going 
> to be changing. I don';t want the BSP tree to store the partitioning 
> of cells between processors, only the spatial regions themselves.
> If I save the BSPCuts (vtkBSPCuts *cuts = 
> D3Object1->GetKdtree()->GetCuts()) and re-use it on later time steps, 
> is there a way I can tell the D3 filter to not re-use the cell 
> allocation between processors, but instead to recompute it using the 
> cuts provided.
> Perhaps it will do this if I SetRetainKdtree(0), but supply the Cuts 
> from above.
>
> Have I understood this correctly. If not, is there a way of achieving 
> what I want.
>
> Part 2 : MPI/D3
> If I create a D3 filter with an instantiation in each process as part 
> of the reader, I will assign the MPI controller using the 
> SetController(this->Controller) and this Controller was taken from 
> MPIController::GetGlobalController - but this seems dangerous, because 
> if I later turn on ordered compositing, or perhaps use a D3 filter in 
> the pipeline, how does the MPI controller know which D3 filter belongs 
> to which part of the pipeline. There will be two D3 filters per 
> process one in the reader and one later in the pipeline and they both 
> have the same RMI signatures. What should I do to ensure that the D3 
> in the reader doesn't send data to the D3 in the compositor and vice 
> versa. Previously when I've used the MPI communicator, there has been 
> only one of my filters per process so no possible conflict.
>
> Thanks
>
> JB
>
>


-- 
John Biddiscombe,                            email:biddisco @ cscs.ch
http://www.cscs.ch/about/BJohn.php
CSCS, Swiss National Supercomputing Centre  | Tel:  +41 (91) 610.82.07
Via Cantonale, 6928 Manno, Switzerland      | Fax:  +41 (91) 610.82.82



More information about the ParaView mailing list