Hi Berk,
Thanks for your help here.
By the way, I really meant for "slow" to read "time consuming". I am
heartened by your comments, because I am really hoping to get a speed
up, to make our application feasible! We need too many stream lines,
that's really the issue.
Seems that the current DST implementation is a reasonable choice for
generating a single stream or a set of streams with seeds that all
originate in the same sub-domain/process, which is often the case. I
wonder about the other cases, where many seeds are distributed over a
number of sub-domains. And perhaps as others suggest that its pretty
good there as well.
For our use case we have a heavier work load, with better (but far from
ideal) loading, and neighbor meta data that could be used. We hope the
potential for a speed up is there, but I am convinced I need to do more
homework on this before coming to that conclusion!
Thanks again,
Burlen
Berk Geveci wrote:
Hi Burlen,
The only reason I implemented it as it is was time constraint. It can
be made much scalable (hint hint ;-) ).
As for the issue with building links, we are working on incorporating
the BSP tree locator as an alternative to vtkPointSet::FindCell().
Thanks John for contributing it.
-berk
On Tue, Aug 25, 2009 at 4:42 AM, John Biddiscombe<[email protected]> 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
_______________________________________________
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
_______________________________________________
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
