[Paraview] distributed stream tracer scalability issue

[David E DeMarle]

There was a paper at Super Computing last year (or maybe the year before)
about improved partitioning for stream tracing that would probably help
alot. Think of making a filter like D3 which moves data around to
repartition, such that the partitions take into account the principle flow
directions. That way particles stay resident much more often. The upfront
cost might be high to do the repartition, but afterwards stream tracing
would be faster.

David E DeMarle
Kitware, Inc.
R&D Engineer
28 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-371-3971 x109


On Tue, Aug 25, 2009 at 4:42 AM, John Biddiscombe <biddisco at cscs.ch> wrote:

> Burlen
>
> I have had performance issues with the Distributed Stream tracer, but in
> fact I found that in general, the problem of it not being very well
> optimized for parallel operation was not the main trouble. If you are using
> Unstructured Grids, and they are large (in my case 20million cells in a
> block), then the main time was taken by the building of cell links which are
> used to FindCEll inwhich an integration point lies. I modified the stream
> tracer interpolation to use a BSP tree (or CellLocator) and found a huge
> improvement in execution time. (minutes instead of hours).
>
> Secondly. the parallelization of the stream tracer is an inherent problem.
> One cannot integrate the streamline in block 2, until it has reached a
> boundary in block 1 - one must wait until the streamling traverses one block
> before passing it to the next. In actuality, the implementation could be
> improved with more intelligent seeding and rending/receiving of streamline
> seeds etc between iterations.
>
> The Particle tracer code could be modifed to produce streamlines in a
> serial or distributed manner and ought to give a 'reasonably' optimal
> solution to the problem - but in fact the chaps at kitware are at the moment
> (they tell me) in the process of revamping the streamline code to make use
> of CellLocators - and for this reason I recently committed my BSP tree code.
>
> Here's how to check your bottleneck.
> Find a large StructuredGrid dataset which is loaded in parallel. Generate
> streamlines. Time it. Convert the grdi to UnstructuredGrid and do the same.
> If test 1 takes 1 minute and test 2 1 hour, then it isn't the parallization
> that's the real issue, but the grid being used.
>
> JB
>
>
>
>
>
>  We've been using the distributed stream tracer to generate 100s-1000s of
>> stream lines per time step. It's very slow, and it doesn't scale at all.
>>  The class comments say as much. I'm sure there is a reason why this
>> implementation was chosen. Is there something that generally prevents real
>> parallel implementation? Is there a better implementation available out
>> there?
>>
>> There is this post a while back
>> http://www.paraview.org/pipermail/paraview/2009-July/012959.html
>>
>> What's the status?
>>
>> Thanks
>> Burlen
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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
>>
>
>
> --
> John Biddiscombe,                            email:biddisco @ cscs.ch
> http://www.cscs.ch/
> CSCS, Swiss National Supercomputing Centre  | Tel:  +41 (91) 610.82.07
> Via Cantonale, 6928 Manno, Switzerland      | Fax:  +41 (91) 610.82.82
>
>
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20090825/f0e95f74/attachment-0001.htm>