[Paraview-developers] Using OpenMP for custom plugins/filters

[Schlottke-Lakemper, Michael]

Hi Sujin,

Thanks again for the fast and helpful answer! One last question: if I do not call vtkSMPTools::Initialize() and OMP_NUM_THREADS is not set, which number of threads will be used? Will it be the same as if running a normal OpenMP program with OMP_NUM_THREADS not set or will a different value be used?

Michael

On 08 Mar 2016, at 15:22 , Sujin Philip <sujin.philip at kitware.com<mailto:sujin.philip at kitware.com>> wrote:

Hi Michael,

- What is the default SMP backend if I do not configure anything during ParaView compilation (I assume “Sequential”)?
Sequential is the default backend.

- With OpenMP, will I have to call vtkSMPTools::Initialize(nThreads) explicitly with nThreads determined by myself, or will it honor e.g. OMP_NUM_THREADS automatically?
It is not necessary to call vtkSMPTools::Initialize. If initialize is not called and OMP_NUM_THREADS is set, it will be used.

- Am I correct in the assumption that the backend type should not change the results, i.e. that on hosts where I do not know which SMP backend is configured, I can assume my algorithms “just work”?
Yes, the different backends should produce the same results. The only noticeable difference should be in the performance. If the results are not the same then its a bug.

Thanks
Sujin


On Tue, Mar 8, 2016 at 9:08 AM, Schlottke-Lakemper, Michael <m.schlottke-lakemper at aia.rwth-aachen.de<mailto:m.schlottke-lakemper at aia.rwth-aachen.de>> wrote:
Hi Utkarsh,

Thanks for the fast answer. I have a a few follow-up questions, if I may:

- What is the default SMP backend if I do not configure anything during ParaView compilation (I assume “Sequential”)?
- With OpenMP, will I have to call vtkSMPTools::Initialize(nThreads) explicitly with nThreads determined by myself, or will it honor e.g. OMP_NUM_THREADS automatically?
- If I have to call vtkSMPTools::Initialize(nThreads) explicitly, where should it be done in case of a plugin? In the plugin’s ctor, in the RequestData method, or someplace else?
- Am I correct in the assumption that the backend type should not change the results, i.e. that on hosts where I do not know which SMP backend is configured, I can assume my algorithms “just work”?

Thanks a lot in advance

Michael

> On 08 Mar 2016, at 14:39 , Utkarsh Ayachit <utkarsh.ayachit at kitware.com<mailto:utkarsh.ayachit at kitware.com>> wrote:
>
> Michael,
>
> The VTK-SMP approach is indeed the way to go for this. To make the
> backend use OpenMP, you simply compile VTK/ParaView with
> VTK_SMP_IMPLEMENTATION_TYPE set to OpenMP. The programming model
> described in the SMP Guide PDF has been implemented for all supported
> backends including OpenMP and TBB.
>
> Utkarsh
>
> On Tue, Mar 8, 2016 at 6:22 AM, Schlottke-Lakemper, Michael
> <m.schlottke-lakemper at aia.rwth-aachen.de<mailto:m.schlottke-lakemper at aia.rwth-aachen.de>> wrote:
>> Hi everyone,
>>
>> We have a custom parallel reader plugin that works well with our files even
>> on large-ish (100-1000) number of cores for the pvserver. Recently we’ve
>> added the capability to also create ghost cells with this reader such that
>> MPI domain boundaries become transparent to filters that need neighbor data,
>> e.g., for gradient computations. However, this ghost cell generation takes
>> up quite some time, so we would like to keep the number of MPI ranks at a
>> minimum and use hybrid MPI-OpenMP parallelism for our plugin.
>>
>> My question is thus if it is possible to use OpenMP inside a custom plugin?
>> And if yes, is there a canonical way to do it (maybe an example plugin) or
>> is it going to be a hack?
>>
>> When searching the interwebs for ParaView and OpenMP, I only came up with an
>> old VTK mailing list thread from 2014
>> (http://public.kitware.com/pipermail/vtkusers/2014-March/083399.html), in
>> which David (DeMarle) refers to some initial documentation of the SMP
>> framework (http://www.vtk.org/Wiki/images/3/3b/VTK_SMP_Guide.pdf). However,
>> the linked PDF does not contain references to OpenMP.
>>
>> Thanks a lot in advance!
>>
>> Michael
>>
>> --
>> Michael Schlottke-Lakemper
>>
>> Chair of Fluid Mechanics and Institute of Aerodynamics
>> RWTH Aachen University
>> Wüllnerstraße 5a
>> 52062 Aachen
>> Germany
>>
>> Phone: +49 (241) 80 95188<tel:%2B49%20%28241%29%2080%2095188>
>> Fax: +49 (241) 80 92257<tel:%2B49%20%28241%29%2080%2092257>
>> Mail: m.schlottke-lakemper at aia.rwth-aachen.de<mailto:m.schlottke-lakemper at aia.rwth-aachen.de>
>> Web: http://www.aia.rwth-aachen.de<http://www.aia.rwth-aachen.de/>
>>
>>
>> _______________________________________________
>> Powered by www.kitware.com<http://www.kitware.com/>
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Search the list archives at:
>> http://markmail.org/search/?q=Paraview-developers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/paraview-developers
>>

_______________________________________________
Powered by www.kitware.com<http://www.kitware.com/>

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=Paraview-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview-developers


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20160308/2dc312c7/attachment-0001.html>