[Paraview] Some D3 and MPI questions

Moreland, Kenneth kmorel at sandia.gov
Mon Nov 20 13:13:06 EST 2006


John,

I'm a little confused.  Once you call SetCuts on a k-d tree, the
distribution should be set and will never be recalculated.  Are you
calling D3->GetKdTree()->SetCuts()?

-Ken

> -----Original Message-----
> From: paraview-bounces+kmorel=sandia.gov at paraview.org
[mailto:paraview-
> bounces+kmorel=sandia.gov at paraview.org] On Behalf Of John Biddiscombe
> Sent: Monday, November 20, 2006 9:42 AM
> To: John Biddiscombe
> Cc: Paraview Mailing List
> Subject: Re: [Paraview] Some D3 and MPI questions
> 
> 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
> 
> _______________________________________________
> ParaView mailing list
> ParaView at paraview.org
> http://www.paraview.org/mailman/listinfo/paraview




More information about the ParaView mailing list