[prev in list] [next in list] [prev in thread] [next in thread]
List: paraview
Subject: Re: [Paraview] Parallel Streamtracer
From: Yuanxin Liu <leo.liu () kitware ! com>
Date: 2012-05-31 19:33:27
Message-ID: CAH+HHJ9ZKR2EMGrmL=8+Agq5GDjfyRhhOD4Eaf2PH8KWbfNzRw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
It is in the current VTK and ParaView master. The class is
vtkPStreamTracer.
Leo
On Thu, May 31, 2012 at 3:31 PM, Stephan Rogge
<stephan.rogge@tu-cottbus.de>wrote:
> Hi, Andy and Leo,
>
> thanks for your replies.
>
> Is it possible to get this new implementation? I would to give it a try.
>
> Regards,
> Stephan
>
> Am 31.05.2012 um 17:48 schrieb Yuanxin Liu <leo.liu@kitware.com>:
>
> Hi, Stephan,
> The previous implementation only has serial performance: It traces the
> streamlines one at a time and never starts a new streamline until the
> previous one finishes. With communication overhead, it is not surprising
> it got slower.
>
> My new implementation is able to let the processes working on different
> streamlines simultaneously and should scale much better.
>
> Leo
>
>
> On Thu, May 31, 2012 at 11:27 AM, Andy Bauer <andy.bauer@kitware.com>wrote:
>
>> Hi Stephan,
>>
>> The parallel stream tracer uses the partitioning of the grid to determine
>> which process does the integration. When the streamline exits the subdomain
>> of a process there is a search to see if it enters a subdomain assigned to
>> any other processes before figuring it whether it has left the entire
>> domain.
>>
>> Leo, copied here, has been improving the streamline implementation inside
>> of VTK so you may want to get his newer version. It is a pretty tough
>> algorithm to parallelize efficiently without making any assumptions on the
>> flow or partitioning.
>>
>> Andy
>>
>>
>> On Thu, May 31, 2012 at 4:16 AM, Stephan Rogge <
>> Stephan.Rogge@tu-cottbus.de> wrote:
>>
>>> Hello,
>>>
>>> I have a question related to the parallelism of the stream tracer: As I
>>> understand the code right, each line integration (trace) is processed in
>>> an
>>> own MPI process. Right?
>>>
>>> To test the scalability of the Stream tracer I've load a structured
>>> (curvilinear) grid and applied the filter with a Seed resolution of 1500
>>> and
>>> check the timings in a single and multi-thread (Multi Core enabled in PV
>>> GUI) situation.
>>>
>>> I was really surprised that multi core slows done the execution time to 4
>>> seconds. The single core takes only 1.2 seconds. Data migration cannot be
>>> the explanation for that behavior (0.5 seconds). What is the problem
>>> here?
>>>
>>> Please see attached some statistics...
>>>
>>> Data:
>>> * Structured (Curvilinear) Grid
>>> * 244030 Cells
>>> * 37 MB Memory
>>>
>>> System:
>>> * Intel i7-2600K (4 Cores + HT = 8 Threads)
>>> * 16 GB Ram
>>> * Windows 7 64 Bit
>>> * ParaView (master-branch, 64 bit compilation)
>>>
>>> #################################
>>> Single Thread (Seed resolution 1500):
>>> #################################
>>>
>>> Local Process
>>> Still Render, 0.014 seconds
>>> RenderView::Update, 1.222 seconds
>>> vtkPVView::Update, 1.222 seconds
>>> Execute vtkStreamTracer id: 2184, 1.214 seconds
>>> Still Render, 0.015 seconds
>>>
>>> #################################
>>> Eight Threads (Seed resolution 1500):
>>> #################################
>>>
>>> Local Process
>>> Still Render, 0.029 seconds
>>> RenderView::Update, 4.134 seconds
>>> vtkSMDataDeliveryManager: Deliver Geome, 0.619 seconds
>>> FullRes Data Migration, 0.619 seconds
>>> Still Render, 0.042 seconds
>>> OpenGL Dev Render, 0.01 seconds
>>>
>>>
>>> Render Server, Process 0
>>> RenderView::Update, 4.134 seconds
>>> vtkPVView::Update, 4.132 seconds
>>> Execute vtkStreamTracer id: 2193, 3.941 seconds
>>> FullRes Data Migration, 0.567 seconds
>>> Dataserver gathering to 0, 0.318 seconds
>>> Dataserver sending to client, 0.243 seconds
>>>
>>> Render Server, Process 1
>>> Execute vtkStreamTracer id: 2193, 3.939 seconds
>>>
>>> Render Server, Process 2
>>> Execute vtkStreamTracer id: 2193, 3.938 seconds
>>>
>>> Render Server, Process 3
>>> Execute vtkStreamTracer id: 2193, 4.12 seconds
>>>
>>> Render Server, Process 4
>>> Execute vtkStreamTracer id: 2193, 3.938 seconds
>>>
>>> Render Server, Process 5
>>> Execute vtkStreamTracer id: 2193, 3.939 seconds
>>>
>>> Render Server, Process 6
>>> Execute vtkStreamTracer id: 2193, 3.938 seconds
>>>
>>> Render Server, Process 7
>>> Execute vtkStreamTracer id: 2193, 3.939 seconds
>>>
>>> Cheers,
>>> Stephan
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>
>>
>
[Attachment #5 (text/html)]
It is in the current VTK and ParaView master. The class is vtkPStreamTracer. \
<br><br>Leo<br><br><div class="gmail_quote">On Thu, May 31, 2012 at 3:31 PM, Stephan \
Rogge <span dir="ltr"><<a href="mailto:stephan.rogge@tu-cottbus.de" \
target="_blank">stephan.rogge@tu-cottbus.de</a>></span> wrote:<br> <blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div bgcolor="#FFFFFF"><div>Hi, Andy and \
Leo,</div><div><br></div><div>thanks for your replies.</div><div><br></div><div> Is \
it possible to get this new implementation? I would to give it a \
try.</div><div><br></div><div>Regards,</div><div>Stephan</div><div><br>Am 31.05.2012 \
um 17:48 schrieb Yuanxin Liu <<a href="mailto:leo.liu@kitware.com" \
target="_blank">leo.liu@kitware.com</a>>:<br> <br></div><div><div \
class="h5"><div></div><blockquote type="cite"><div>Hi, Stephan,<br> The previous \
implementation only has serial performance: It traces the streamlines one at a time \
and never starts a new streamline until the previous one finishes. With \
communication overhead, it is not surprising it got slower.<br>
<br> My new implementation is able to let the processes working on different \
streamlines simultaneously and should scale much better.<br><br>Leo<br><br><br><div \
class="gmail_quote">On Thu, May 31, 2012 at 11:27 AM, Andy Bauer <span \
dir="ltr"><<a href="mailto:andy.bauer@kitware.com" \
target="_blank">andy.bauer@kitware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">Hi Stephan,<br><br>The parallel stream tracer uses the \
partitioning of the grid to determine which process does the integration. When the \
streamline exits the subdomain of a process there is a search to see if it enters a \
subdomain assigned to any other processes before figuring it whether it has left the \
entire domain. <br>
<br>Leo, copied here, has been improving the streamline implementation inside of VTK \
so you may want to get his newer version. It is a pretty tough algorithm to \
parallelize efficiently without making any assumptions on the flow or \
partitioning.<span><font color="#888888"><br>
<br>Andy</font></span><div><div><br><br><div class="gmail_quote">On Thu, May 31, 2012 \
at 4:16 AM, Stephan Rogge <span dir="ltr"><<a \
href="mailto:Stephan.Rogge@tu-cottbus.de" \
target="_blank">Stephan.Rogge@tu-cottbus.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">Hello,<br> <br>
I have a question related to the parallelism of the stream tracer: As I<br>
understand the code right, each line integration (trace) is processed in an<br>
own MPI process. Right?<br>
<br>
To test the scalability of the Stream tracer I've load a structured<br>
(curvilinear) grid and applied the filter with a Seed resolution of 1500 and<br>
check the timings in a single and multi-thread (Multi Core enabled in PV<br>
GUI) situation.<br>
<br>
I was really surprised that multi core slows done the execution time to 4<br>
seconds. The single core takes only 1.2 seconds. Data migration cannot be<br>
the explanation for that behavior (0.5 seconds). What is the problem here?<br>
<br>
Please see attached some statistics...<br>
<br>
Data:<br>
* Structured (Curvilinear) Grid<br>
* 244030 Cells<br>
* 37 MB Memory<br>
<br>
System:<br>
* Intel i7-2600K (4 Cores + HT = 8 Threads)<br>
* 16 GB Ram<br>
* Windows 7 64 Bit<br>
* ParaView (master-branch, 64 bit compilation)<br>
<br>
#################################<br>
Single Thread (Seed resolution 1500):<br>
#################################<br>
<br>
Local Process<br>
Still Render, 0.014 seconds<br>
RenderView::Update, 1.222 seconds<br>
vtkPVView::Update, 1.222 seconds<br>
Execute vtkStreamTracer id: 2184, 1.214 seconds<br>
Still Render, 0.015 seconds<br>
<br>
#################################<br>
Eight Threads (Seed resolution 1500):<br>
#################################<br>
<br>
Local Process<br>
Still Render, 0.029 seconds<br>
RenderView::Update, 4.134 seconds<br>
vtkSMDataDeliveryManager: Deliver Geome, 0.619 seconds<br>
FullRes Data Migration, 0.619 seconds<br>
Still Render, 0.042 seconds<br>
OpenGL Dev Render, 0.01 seconds<br>
<br>
<br>
Render Server, Process 0<br>
RenderView::Update, 4.134 seconds<br>
vtkPVView::Update, 4.132 seconds<br>
Execute vtkStreamTracer id: 2193, 3.941 seconds<br>
FullRes Data Migration, 0.567 seconds<br>
Dataserver gathering to 0, 0.318 seconds<br>
Dataserver sending to client, 0.243 seconds<br>
<br>
Render Server, Process 1<br>
Execute vtkStreamTracer id: 2193, 3.939 seconds<br>
<br>
Render Server, Process 2<br>
Execute vtkStreamTracer id: 2193, 3.938 seconds<br>
<br>
Render Server, Process 3<br>
Execute vtkStreamTracer id: 2193, 4.12 seconds<br>
<br>
Render Server, Process 4<br>
Execute vtkStreamTracer id: 2193, 3.938 seconds<br>
<br>
Render Server, Process 5<br>
Execute vtkStreamTracer id: 2193, 3.939 seconds<br>
<br>
Render Server, Process 6<br>
Execute vtkStreamTracer id: 2193, 3.938 seconds<br>
<br>
Render Server, Process 7<br>
Execute vtkStreamTracer id: 2193, 3.939 seconds<br>
<br>
Cheers,<br>
Stephan<br>
<br>
<br>
_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a \
href="http://www.kitware.com/opensource/opensource.html" \
target="_blank">http://www.kitware.com/opensource/opensource.html</a><br> <br>
Please keep messages on-topic and check the ParaView Wiki at: <a \
href="http://paraview.org/Wiki/ParaView" \
target="_blank">http://paraview.org/Wiki/ParaView</a><br> <br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.paraview.org/mailman/listinfo/paraview" \
target="_blank">http://www.paraview.org/mailman/listinfo/paraview</a><br> \
</blockquote></div><br> </div></div></blockquote></div><br>
</div></blockquote></div></div></div></blockquote></div><br>
_______________________________________________
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic