[Paraview] problems generating ghost cells, update on PKdTree questions

Tue Nov 24 09:53:00 EST 2009

Well, I don't know what else would be wrong.  Perhaps you could set a breakpoint in D3's RequestData to see what ghost level is being passed to it.

-Ken

On 11/24/09 4:22 AM, "Christine Corbett Moran" <corbett at physik.uzh.ch> wrote:

I tried this-still no ghost levels (the array is there, as before, but
the ghost level of everything is still 0).

I don't necessarily want the result of the pipeline to have ghost
levels (but would like to know how to do this anyway). My end goal is
to have my reader, which internally runs D3, produce ghost levels on
request of a downstream filter. Moreover, if a user doesn't use my
reader, uses the ParaView D3 in the pipeline, and then uses a filter
of mine which requests ghost level, I would like D3 to generate ghost
levels.

I am currently failing on both accounts.

Christine

On Mon, Nov 23, 2009 at 10:53 PM, Moreland, Kenneth <kmorel at sandia.gov> wrote:
> The UPDATE_NUMBER_OF_GHOST_LEVELS key is used to request the number of ghost
> levels a filter is supposed to produce.  You set it on an algorithm's output
> information.  It is passed up the pipeline during the RequestUpdateExtent
> phase of execution and used during the computation in the RequestData phase.
>  The DATA_NUMBER_OF_GHOST_LEVELS is attached to the data object itself and
> identifies how many levels were created.
>
> Most of the time the requested UPDATE_NUMBER_OF_GHOST_LEVELS is 0 until a
> filter needs a layer of ghost cells for proper operation, at which time it
> bumps up the UPDATE_NUMBER_OF_GHOST_LEVELS in its RequestUpdateExtent.
>  Yours is an uncommon case where you want the result of the pipeline to have
> ghost levels.
>
> I think the trick is just to call something like
>
> d3->GetOutputPortInformation(0)->Set(UPDATE_NUMBER_OF_GHOST_LEVELS, 1);
>
> before calling Update should do the trick.
>
> -Ken
>
>
> On 11/23/09 1:21 PM, "Christine Corbett Moran" <corbett at physik.uzh.ch>
> wrote:
>
> Hi Ken,
>
> First of all thank you very much for your response.
>
> I see the DATA_NUMBER_OF_GHOST_LEVELS or UPDATE_NUMBER_OF_GHOST_LEVELS
> sets operating on vtkInformation, which I don't call Update on. Should
> I somehow be accessing the vtkDataObject of the vtkInformation (or
> something else related to the pipeline as a whole) and call Update on
> it?  That sounds like it is very likely my problem.
>
> Right now
> 1. I run D3 within my data reader, I set the output to be D3->output,
> then the _last thing_ I do is call:
>  output->GetInformation()->Set(vtkDataObject::DATA_NUMBER_OF_GHOST_LEVELS(),
> 1);
> 2. In a downstream filter which requires ghost cells, the _first
> thing_ I do if running in parallel call:
>   inInfo->Set(vtkStreamingDemandDrivenPipeline::UPDATE_NUMBER_OF_GHOST_LEVELS(),1);
>
> The documentation I can find on this is pretty fluffy ("filters can
> request ghost cells"), so if anyone points me to something better it
> would help tremendously (or even a good nugget of example code that I
> missed in my grepping).
>
> Cheers,
> Christine
>
> On Mon, Nov 23, 2009 at 8:57 PM, Moreland, Kenneth <kmorel at sandia.gov>
> wrote:
>> I think setting UPDATE_NUMBER_OF_GHOST_LEVELS on the output of the filter
>> before calling Update is the right thing to do.  However, in your example
>> code I do not see where that value is getting set.  I only see the update
>> extent being set, and that is not sufficient to produce ghost cells.
>>
>> -Ken
>>
>>
>> On 11/19/09 4:50 PM, "Christine Corbett Moran" <corbett at physik.uzh.ch>
>> wrote:
>>
>> I'm having trouble with generating ghost cells, either on my own or
>> with D3 (via the duplicate boundary points mode). In neither case am I
>> able to see a single ghost level of value 1 for any of my points on a
>> test data set, which has 10,000 cells, one point per cell, distributed
>> on 4 processors. I try both generating ghost cells at level one within
>> my d3 call in my reader as follows:
>>                 vtkSmartPointer<vtkDistributedDataFilter> d3 = \
>>                     vtkSmartPointer<vtkDistributedDataFilter>::New();
>>                 d3->AddInput(tipsyReadInitialOutput);
>>                 d3->UpdateInformation();
>>                 vtkStreamingDemandDrivenPipeline* exec = \
>>
>>                         static_cast<vtkStreamingDemandDrivenPipeline*>(d3->GetExecutive());
>>
>>                 // adds one ghostlevel
>>                 exec->SetUpdateExtent(exec->GetOutputInformation(0),
>> piece,
>> numPieces, 1);
>>                 d3->Update();
>>                 // changing output to output of d3
>>                 output->ShallowCopy(d3->GetOutput());
>>                 output->GetInformation()->Set(
>>                         vtkDataObject::DATA_NUMBER_OF_GHOST_LEVELS(), 1);
>> And, as far as I can tell, the procedure for a filter requesting ghost
>> levels is:
>>                 // Requesting one level of ghost cells
>>                 vtkInformation* inInfo =
>> inputVector[0]->GetInformationObject(0);
>>                 inInfo->Set(
>>
>>                         vtkStreamingDemandDrivenPipeline::UPDATE_NUMBER_OF_GHOST_LEVELS(),1);
>> And my reader or D3 would then have to access the inInfo act on this
>> request. However neither my filter nor D3 are generating any ghost
>> cells, as is verified by examining:
>>
>>                  output->GetPointData()->GetArray("vtkGhostLevels")->GetTuple(
>>                                 nextHaloId)[0]
>> Can any one see what's going on? I've read a chunk of vtk source
>> referencing vtkGhostLevels or using UPDATE_NUMBER_OF_GHOST_LEVELS but
>> haven't found the clue yet.
>>
>> An update on my D3/PKd tree question: I decided to run D3
>> automatically if the user checks a button in my readers and strongly
>> recommend they run D3 if they don't use my readers. I found that
>> BuildLocator() or BuildLocatorFromPoints(points) never worked as I had
>> hoped from the documentation (I wanted to call it once/or on all
>> processes on the PkD tree generated by D3 and have it build a locator
>> which works across all processes, i.e. can also find points belonging
>> to a neighbor process), so instead I build a KdTree locator local to
>> each process, separate from the PKdTree generated by D3, and
>> coordinate a search if necessary, I can still make this highly data
>> parallel for my applications, e.g. finding the mass of all points
>> within a given radius by doing local searches/consolidation and just
>> sending the results for a final consolidation to the root.
>>
>> Christine
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the ParaView Wiki at:
>> http://paraview.org/Wiki/ParaView
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.paraview.org/mailman/listinfo/paraview
>>
>>
>>
>>
>>    ****      Kenneth Moreland
>>     ***      Sandia National Laboratories
>> ***********
>> *** *** ***  email: kmorel at sandia.gov
>> **  ***  **  phone: (505) 844-8919
>>     ***      web:   http://www.cs.unm.edu/~kmorel
>>
>>
>
>
>
>
>    ****      Kenneth Moreland
>     ***      Sandia National Laboratories
> ***********
> *** *** ***  email: kmorel at sandia.gov
> **  ***  **  phone: (505) 844-8919
>     ***      web:   http://www.cs.unm.edu/~kmorel
>
>

   ****      Kenneth Moreland
    ***      Sandia National Laboratories
***********
*** *** ***  email: kmorel at sandia.gov
**  ***  **  phone: (505) 844-8919
    ***      web:   http://www.cs.unm.edu/~kmorel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20091124/1e0ba1ea/attachment-0001.htm>