From joachim.pouderoux at kitware.com  Tue Oct  3 07:35:00 2017
From: joachim.pouderoux at kitware.com (Joachim Pouderoux)
Date: Tue, 3 Oct 2017 07:35:00 -0400
Subject: [Paraview-developers] FW: [EXTERNAL] [Paraview] Rendering
 problem with the Streamline Representation plugin
In-Reply-To: <fe5c4b416f5d4a05bace011ef66319f4@ES01AMSNLNT.srn.sandia.gov>
References: <1505225937791.47900@epfl.ch>
 <fe5c4b416f5d4a05bace011ef66319f4@ES01AMSNLNT.srn.sandia.gov>
Message-ID: <CACJ=gTh0=QywJeey3iShLZG0YT00d8hCrq+Gzkz4Oet9VX6o3w@mail.gmail.com>

Scott,

Streamlines are green by default as this is the default "Solid color" we
set for this representation. You can change the coloring with any other
array as usual.
Doesn't this work on your machine? I just tried Wavelet+Gradient and it
works as expected (eg. I can color with RTData or a component of
RTDataGradient).
With wich version of ParaView did you test?
The line width is set to 1 by default but this can be changed, changing the
usual "Line Width" property.
I toggled the orientation axis on and off but didn't see any change. If
they grew on your machine this is clearly a bug.

Regarding Dave's small CTH dataset, I resampled it to image. It works
without applying the gradient but you need to reduce the Step Length to get
something meaningful.
Not sure why you would apply a Gradient here as the data comes with a
velocity field but when applying a gradient filter (by default on the Mass
array), the
Stream Lines representation hangs - I guess because vector field is null.
So clearly we should add a check to avoid this issue.

Best,


*Joachim Pouderoux*, PhD

*Technical Expert - Scientific Computing Team*
*Kitware SAS <http://www.kitware.fr>*


2017-09-12 14:04 GMT-04:00 Scott, W Alan <wascott at sandia.gov>:

> I played around with this plugin/filter a bit this morning, and am pretty
> confused.  Let?s start with a question ? what does this plugin do?
>
>
>
> Lets start with my observations.
>
>
>
> I loaded the plugin, and then tested with Wavelet/ Gradient filter/ Stream
> Lines.
>
>
>
> Streamlines are green.  Color can?t be changed.  Is this a bug, or by
> design?
>
> Streamlines default to really, really small.
>
> As I toggled the orientation axis on and off, the streamlines grew.
> Huh?  Is this a bug, or by design?
>
> I tried Dave?s Small CTH dataset, then Resample to Image, then Gradient.
> This crashed.  This shouldn?t crash, should it?
>
>
>
>
>
> Thanks for any insight,
>
>
>
> Alan
>
>
>
> *From:* ParaView [mailto:paraview-bounces at paraview.org] *On Behalf Of *Wilhelm
> Lionel
> *Sent:* Tuesday, September 12, 2017 8:19 AM
> *To:* Paraview at paraview.org
> *Subject:* [EXTERNAL] [Paraview] Rendering problem with the Streamline
> Representation plugin
>
>
>
> Dear Paraviewers,
>
>
>
> I found sevral rendering issues in the Streamline Representation plugin.
> In order the issue to be reproducible, I followed the "How to test ?"
> section on this page https://blog.kitware.com/new-animated-stream-lines-
> representation-for-paraview-5-3/. In order to see what I'm talking about,
> one can open Paraview (GUI) tools -> Python Shell -> run script ->
> PVstateSurfRepBug.py (I load the plugin in the script)
>
>
>
> 1. The streamlines appear in green as default color. If I try to set their
> color to white in the GUI it does not work (Gradient proxy -> Coloring ->
> edit color map). The user must first set the color as some other preset and
> then the GUI sets the DiffuseColor attribute to whatever the user choose.
>
> 2. In addition to the gradient filter, if a slice filter is attached to
> the wavelet source, even if the streamlines should be displayed (because
> the slice plane is behind the streamlines) they do always show. If the
> representation type of the slice is Point Gaussian, Surface or Surface
> with edges, they do not show but the other representation types work well
>
> 3. If I want to record an animation of the streamlines, the "Transparent
> Background" option leads to strange animation (with AVI format but not with
> OGG/Theora).
>
>
>
> Despite these little bugs, I'd like to thank the developpers for this
> awsome plugin !! It realy helps to understand and interpret CFD results :)
>
>
>
> Kindly,
>
>
>
> Lionel Wilhelm
>
> _______________________________________________
> Powered by 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/20171003/b65feffb/attachment.html>

From sur.chiranjib at gmail.com  Tue Oct  3 14:16:57 2017
From: sur.chiranjib at gmail.com (Chiranjib Sur)
Date: Tue, 3 Oct 2017 23:46:57 +0530
Subject: [Paraview-developers] object numbering in pipeline browser
Message-ID: <CAJk8dSCe7uU2xp_2h96AumezgstRas23xkpg6HDPNnUDjf7egg@mail.gmail.com>

Hi,
Can any one explain how the numbering sequencing happen when we create
objects  (e.g. Source > Cone) and the objects appears as "Cone1", "Cone2"
etc.?

I am interested which part of the code is responsible for numerical
increment 1,2 etc following the Object name.

Thanks in advance.

Chiranjib
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171003/8a68875f/attachment.html>

From joachim.pouderoux at kitware.com  Tue Oct  3 14:35:40 2017
From: joachim.pouderoux at kitware.com (Joachim Pouderoux)
Date: Tue, 3 Oct 2017 14:35:40 -0400
Subject: [Paraview-developers] object numbering in pipeline browser
In-Reply-To: <CAJk8dSCe7uU2xp_2h96AumezgstRas23xkpg6HDPNnUDjf7egg@mail.gmail.com>
References: <CAJk8dSCe7uU2xp_2h96AumezgstRas23xkpg6HDPNnUDjf7egg@mail.gmail.com>
Message-ID: <CACJ=gTg5A9LNKMK65Er6eetyCiDt=xtCRx-SfO4JWmaFey9eaQ@mail.gmail.com>

Chiranjib,

Take a look at vtkSMSessionProxyManager::GetUniqueProxyName().
This is the function called in vtkSMSessionProxyManager::RegisterProxy() that
setup the default proxy names.

Regards,

*Joachim Pouderoux*, PhD

*Technical Expert - Scientific Computing Team*
*Kitware SAS <http://www.kitware.fr>*


2017-10-03 14:16 GMT-04:00 Chiranjib Sur <sur.chiranjib at gmail.com>:

> Hi,
> Can any one explain how the numbering sequencing happen when we create
> objects  (e.g. Source > Cone) and the objects appears as "Cone1", "Cone2"
> etc.?
>
> I am interested which part of the code is responsible for numerical
> increment 1,2 etc following the Object name.
>
> Thanks in advance.
>
> Chiranjib
>
> _______________________________________________
> Powered by 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/20171003/9e4bd9fc/attachment.html>

From sur.chiranjib at gmail.com  Tue Oct  3 14:38:50 2017
From: sur.chiranjib at gmail.com (Chiranjib Sur)
Date: Wed, 4 Oct 2017 00:08:50 +0530
Subject: [Paraview-developers] object numbering in pipeline browser
In-Reply-To: <CACJ=gTg5A9LNKMK65Er6eetyCiDt=xtCRx-SfO4JWmaFey9eaQ@mail.gmail.com>
References: <CAJk8dSCe7uU2xp_2h96AumezgstRas23xkpg6HDPNnUDjf7egg@mail.gmail.com>
 <CACJ=gTg5A9LNKMK65Er6eetyCiDt=xtCRx-SfO4JWmaFey9eaQ@mail.gmail.com>
Message-ID: <CAJk8dSBM8gB4Q4e5t-XqPvcyKTdPHABQDnvS_A_MVpy12yRBJw@mail.gmail.com>

Thanks. How about the number sequencing? I figure out the proxy part when
you scan through the pipe line. But when creating source how the numbers
appeared?

Thanks and regards,
Chiranjib

Using handheld device, sorry for the typos, if any.


On Oct 4, 2017 12:06 AM, "Joachim Pouderoux" <joachim.pouderoux at kitware.com>
wrote:

Chiranjib,

Take a look at vtkSMSessionProxyManager::GetUniqueProxyName().
This is the function called in vtkSMSessionProxyManager::RegisterProxy() that
setup the default proxy names.

Regards,

*Joachim Pouderoux*, PhD

*Technical Expert - Scientific Computing Team*
*Kitware SAS <http://www.kitware.fr>*


2017-10-03 14:16 GMT-04:00 Chiranjib Sur <sur.chiranjib at gmail.com>:

> Hi,
> Can any one explain how the numbering sequencing happen when we create
> objects  (e.g. Source > Cone) and the objects appears as "Cone1", "Cone2"
> etc.?
>
> I am interested which part of the code is responsible for numerical
> increment 1,2 etc following the Object name.
>
> Thanks in advance.
>
> Chiranjib
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensou
> rce/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/20171004/6e84b55d/attachment.html>

From joachim.pouderoux at kitware.com  Tue Oct  3 17:49:17 2017
From: joachim.pouderoux at kitware.com (Joachim Pouderoux)
Date: Tue, 3 Oct 2017 17:49:17 -0400
Subject: [Paraview-developers] object numbering in pipeline browser
In-Reply-To: <CAJk8dSBM8gB4Q4e5t-XqPvcyKTdPHABQDnvS_A_MVpy12yRBJw@mail.gmail.com>
References: <CAJk8dSCe7uU2xp_2h96AumezgstRas23xkpg6HDPNnUDjf7egg@mail.gmail.com>
 <CACJ=gTg5A9LNKMK65Er6eetyCiDt=xtCRx-SfO4JWmaFey9eaQ@mail.gmail.com>
 <CAJk8dSBM8gB4Q4e5t-XqPvcyKTdPHABQDnvS_A_MVpy12yRBJw@mail.gmail.com>
Message-ID: <CACJ=gThyB__y6swiBtEbgvCWdxq9g+MiCzcwhEqyXM_=KCqA9w@mail.gmail.com>

Chiranjib,

Well as you can see in vtkSMSessionProxyManager::GetUniqueProxyName(),
there is a suffix loop (master / line 600) from 1 to VTK_INT_MAX that
is incremented until no other proxy as the same name.
As you can see, if you create a Cone, it is named Cone1. Rename it manually
to Cone2, then create a new Cone, this new cone get the name Cone1 because
this name is no more used.

Regards,

*Joachim Pouderoux*, PhD

*Technical Expert - Scientific Computing Team*
*Kitware SAS <http://www.kitware.fr>*


2017-10-03 14:38 GMT-04:00 Chiranjib Sur <sur.chiranjib at gmail.com>:

> Thanks. How about the number sequencing? I figure out the proxy part when
> you scan through the pipe line. But when creating source how the numbers
> appeared?
>
> Thanks and regards,
> Chiranjib
>
> Using handheld device, sorry for the typos, if any.
>
>
> On Oct 4, 2017 12:06 AM, "Joachim Pouderoux" <
> joachim.pouderoux at kitware.com> wrote:
>
> Chiranjib,
>
> Take a look at vtkSMSessionProxyManager::GetUniqueProxyName().
> This is the function called in vtkSMSessionProxyManager::RegisterProxy() that
> setup the default proxy names.
>
> Regards,
>
> *Joachim Pouderoux*, PhD
>
> *Technical Expert - Scientific Computing Team*
> *Kitware SAS <http://www.kitware.fr>*
>
>
> 2017-10-03 14:16 GMT-04:00 Chiranjib Sur <sur.chiranjib at gmail.com>:
>
>> Hi,
>> Can any one explain how the numbering sequencing happen when we create
>> objects  (e.g. Source > Cone) and the objects appears as "Cone1", "Cone2"
>> etc.?
>>
>> I am interested which part of the code is responsible for numerical
>> increment 1,2 etc following the Object name.
>>
>> Thanks in advance.
>>
>> Chiranjib
>>
>> _______________________________________________
>> Powered by 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/20171003/12f6f635/attachment-0001.html>

From mathieu.westphal at kitware.com  Wed Oct  4 03:46:15 2017
From: mathieu.westphal at kitware.com (Mathieu Westphal)
Date: Wed, 4 Oct 2017 09:46:15 +0200
Subject: [Paraview-developers] ArchLinux AUR paraview-git package
Message-ID: <CAC2t4US6hcvTHdLrdL3kLZ7LoQPhYmNuXHYLtm-pLf=LD0Xt0A@mail.gmail.com>

Hello

If you are an ArchLinux user and a ParaView plugin/branded app developper,
you may be interested by an AUR package I just uploaded.
https://aur.archlinux.org/packages/paraview-git/

With this AUR package, you will be able to build a "configured as the
release" paraview from git master, and use the installed package for
building your plugin and ParaView branded app flawlessly.

Let me know if you have any questions or requests regarding default
configuration options in the PKGBUILD.

Best Regards,

Mathieu Westphal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171004/3f5f7683/attachment.html>

From sur.chiranjib at gmail.com  Wed Oct  4 04:08:22 2017
From: sur.chiranjib at gmail.com (Chiranjib Sur)
Date: Wed, 4 Oct 2017 13:38:22 +0530
Subject: [Paraview-developers] compare polydata
Message-ID: <CAJk8dSDFphSiVkVaznsao7xB2Evt73FqueY9Y6htHvt0E79zkA@mail.gmail.com>

Hi,
Is there any implementation available in VTK where I can compare two
polydata and know if they are different?

I want to design a function like this

int polydataCompare(polydata1, polydata2)

if they are different the function will return 1 else return 0

Thanks and regards,
Chiranjib
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171004/3c0232eb/attachment.html>

From mathieu.westphal at kitware.com  Wed Oct  4 04:14:02 2017
From: mathieu.westphal at kitware.com (Mathieu Westphal)
Date: Wed, 4 Oct 2017 10:14:02 +0200
Subject: [Paraview-developers] compare polydata
In-Reply-To: <CAJk8dSDFphSiVkVaznsao7xB2Evt73FqueY9Y6htHvt0E79zkA@mail.gmail.com>
References: <CAJk8dSDFphSiVkVaznsao7xB2Evt73FqueY9Y6htHvt0E79zkA@mail.gmail.com>
Message-ID: <CAC2t4UTOVuNRdc9ztF4MFakWO+h1W9ChSy6oSYtVJZJP_NxOSQ@mail.gmail.com>

Hello

Since you asked on the ParaView ML as well, this can be easilly done in a
ParaView Programmable Filter,
where you could compare all points, cells, point data, cell data and filed
data of the inputs datasets.

Best,

Mathieu Westphal

On Wed, Oct 4, 2017 at 10:08 AM, Chiranjib Sur <sur.chiranjib at gmail.com>
wrote:

> Hi,
> Is there any implementation available in VTK where I can compare two
> polydata and know if they are different?
>
> I want to design a function like this
>
> int polydataCompare(polydata1, polydata2)
>
> if they are different the function will return 1 else return 0
>
> Thanks and regards,
> Chiranjib
>
> _______________________________________________
> Powered by 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/20171004/5dbfb143/attachment.html>

From sur.chiranjib at gmail.com  Wed Oct  4 04:17:50 2017
From: sur.chiranjib at gmail.com (Chiranjib Sur)
Date: Wed, 4 Oct 2017 13:47:50 +0530
Subject: [Paraview-developers] compare polydata
In-Reply-To: <CAC2t4UTOVuNRdc9ztF4MFakWO+h1W9ChSy6oSYtVJZJP_NxOSQ@mail.gmail.com>
References: <CAJk8dSDFphSiVkVaznsao7xB2Evt73FqueY9Y6htHvt0E79zkA@mail.gmail.com>
 <CAC2t4UTOVuNRdc9ztF4MFakWO+h1W9ChSy6oSYtVJZJP_NxOSQ@mail.gmail.com>
Message-ID: <CAJk8dSDFo7eBUVU6WGQD0BDbe6CBGtuCkeBxp51hQxDcQ4Z=PA@mail.gmail.com>

Thanks Mathieu, any pointers for that? Actually my solution is within
ParaView and internally I use VTK classes.


Thanks and regards,
Chiranjib

On Wed, Oct 4, 2017 at 1:44 PM, Mathieu Westphal <
mathieu.westphal at kitware.com> wrote:

> Hello
>
> Since you asked on the ParaView ML as well, this can be easilly done in a
> ParaView Programmable Filter,
> where you could compare all points, cells, point data, cell data and filed
> data of the inputs datasets.
>
> Best,
>
> Mathieu Westphal
>
> On Wed, Oct 4, 2017 at 10:08 AM, Chiranjib Sur <sur.chiranjib at gmail.com>
> wrote:
>
>> Hi,
>> Is there any implementation available in VTK where I can compare two
>> polydata and know if they are different?
>>
>> I want to design a function like this
>>
>> int polydataCompare(polydata1, polydata2)
>>
>> if they are different the function will return 1 else return 0
>>
>> Thanks and regards,
>> Chiranjib
>>
>> _______________________________________________
>> Powered by 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/20171004/21dc46bb/attachment.html>

From paul.melis at surfsara.nl  Wed Oct  4 04:44:40 2017
From: paul.melis at surfsara.nl (Paul Melis)
Date: Wed, 4 Oct 2017 10:44:40 +0200
Subject: [Paraview-developers] OpenGL context provider: Qt5 or other?
Message-ID: <18a42817-f75a-52f9-3904-7a9f190e75cb@surfsara.nl>

Hi devs,

Does ParaView get its OpenGL context through Qt (either directly or 
through VTK) or in some other way? I looked in the source, but could not 
really find a clear answer, other than that the string "QOpenGL" is only 
used in the about box code to provide OpenGL version and vendor info.

More concretely: can I build an (NVidia) GPU-accelerated version of the 
ParaView client if the underlying Qt5 is using Mesa as its OpenGL 
implementation? Or do the library symbols clash in this case?

Regards,
Paul

-- 

Paul Melis
| Visualization group leader & developer | SURFsara |
| Science Park 140 | 1098 XG Amsterdam |
| T 020 800 1312 | paul.melis at surfsara.nl | www.surfsara.nl |

From utkarsh.ayachit at kitware.com  Wed Oct  4 13:41:15 2017
From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit)
Date: Wed, 4 Oct 2017 13:41:15 -0400
Subject: [Paraview-developers] OpenGL context provider: Qt5 or other?
In-Reply-To: <18a42817-f75a-52f9-3904-7a9f190e75cb@surfsara.nl>
References: <18a42817-f75a-52f9-3904-7a9f190e75cb@surfsara.nl>
Message-ID: <CADHSJjBw4MCKvzfKobsR2+OUuovank48ai_kz894s2of7WKRqg@mail.gmail.com>

Paul,

ParaView with Qt 5 let's Qt create the OpenGL context.  The code to
look into is the QVTKOpenGLWidget [1].

> More concretely: can I build an (NVidia) GPU-accelerated version of the ParaView client if the underlying Qt5 is using Mesa as its OpenGL implementation? Or do the library symbols clash in this case?

The GL version you get depends on the libGL loaded at runtime more
than that you linked against (unless you're using mangled GL/Mesa).


 [1] https://gitlab.kitware.com/vtk/vtk/blob/master/GUISupport/Qt/QVTKOpenGLWidget.h

From paul.melis at surfsara.nl  Wed Oct  4 14:37:27 2017
From: paul.melis at surfsara.nl (Paul Melis)
Date: Wed, 4 Oct 2017 20:37:27 +0200
Subject: [Paraview-developers] OpenGL context provider: Qt5 or other?
In-Reply-To: <CADHSJjBw4MCKvzfKobsR2+OUuovank48ai_kz894s2of7WKRqg@mail.gmail.com>
References: <18a42817-f75a-52f9-3904-7a9f190e75cb@surfsara.nl>
 <CADHSJjBw4MCKvzfKobsR2+OUuovank48ai_kz894s2of7WKRqg@mail.gmail.com>
Message-ID: <1c5b20ff-5e58-4a59-7efd-11ffc52e707f@surfsara.nl>

Hi Utkarsh,

On 10/04/2017 07:41 PM, Utkarsh Ayachit wrote:
> Paul,
>
> ParaView with Qt 5 let's Qt create the OpenGL context.  The code to
> look into is the QVTKOpenGLWidget [1].
>
>> More concretely: can I build an (NVidia) GPU-accelerated version of the ParaView client if the underlying Qt5 is using Mesa as its OpenGL implementation? Or do the library symbols clash in this case?
> The GL version you get depends on the libGL loaded at runtime more
> than that you linked against (unless you're using mangled GL/Mesa).
>
>
>   [1] https://gitlab.kitware.com/vtk/vtk/blob/master/GUISupport/Qt/QVTKOpenGLWidget.h
Thanks (wondering why I didn't find that file with my grep). So does 
that mean that these days Mesa and NVidia libGL (or any other OpenGL 
implementation) are changeable at runtime? I got the idea that there 
were still issues with that, even though the whole OpenGL vendor-neutral 
library solution seems to be gaining traction (e.g. [2]).

Paul

[2] 
https://www.archlinux.org/news/mesa-with-libglvnd-support-is-now-in-testing/

From utkarsh.ayachit at kitware.com  Wed Oct  4 14:55:42 2017
From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit)
Date: Wed, 4 Oct 2017 14:55:42 -0400
Subject: [Paraview-developers] OpenGL context provider: Qt5 or other?
In-Reply-To: <1c5b20ff-5e58-4a59-7efd-11ffc52e707f@surfsara.nl>
References: <18a42817-f75a-52f9-3904-7a9f190e75cb@surfsara.nl>
 <CADHSJjBw4MCKvzfKobsR2+OUuovank48ai_kz894s2of7WKRqg@mail.gmail.com>
 <1c5b20ff-5e58-4a59-7efd-11ffc52e707f@surfsara.nl>
Message-ID: <CADHSJjAYvCKNnBvMmMN8pEbKXdNqMenhKJvtTHn9_y0X07xnaw@mail.gmail.com>

>
> Thanks (wondering why I didn't find that file with my grep). So does that
>> mean that these days Mesa and NVidia libGL (or any other OpenGL
>> implementation) are changeable at runtime? I got the idea that there were
>> still issues with that, even though the whole OpenGL vendor-neutral library
>> solution seems to be gaining traction (e.g. [2]).
>>
>
At load time, and not run time. Thus you can't swap them once the app has
started. The GLVND is supposed to address that issue where you can have
Mesa and Nvidia OpenGL contexts, for example, in the same application
without issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171004/6548131f/attachment.html>

From kapinos at itc.rwth-aachen.de  Mon Oct  9 03:08:12 2017
From: kapinos at itc.rwth-aachen.de (Paul Kapinos)
Date: Mon, 9 Oct 2017 09:08:12 +0200
Subject: [Paraview-developers] 100% CPU usage once again
Message-ID: <2dc309ab-846f-f6a2-5fa3-e72ab739e9f6@itc.rwth-aachen.de>

(cross-post from 'paraview at paraview.org' 10/04/2017)

Dear ParaView developer,

in [1] you say
> If you have information on disabling the busy wait using a different MPI
> implementation, please contribute back by documenting it here.

Here we go.

a)
It is possible to build 'pvserver' using Intel MPI (and GCC compilers).
By setting I_MPI_WAIT_MODE  environment variable to 'enable' value you can
effectively prevent busy waiting, see [2] p.10 (Tested with Intel MPI
5.1(.3.181)).

Q/FR.1 Could you please provide a version of 'pvserver' build using Intel MPI in
official release of ParaView? [4]



b)
It is (obviously) possible to build 'pvserver' using MPICH (and GCC compilers).
Itself, MPICH can be *configured* with '--with-device=ch3:sock' option. This is
described to be 'slower' as '--with-device=ch3:nemesis'
For our experiments it turned out, that 'pvserver' compiled and linked using
MPICH with 'ch3:sock' configure option did not have the busy waiting aka
100%-CPU behaviour.
Note that this is *configure-time of MPI library* parameter.


(Tested with MPICH  3.2)

Q/FR.2 Could you please provide a version of 'pvserver' build using MPICH
*configured with '--with-device=ch3:sock' option* in official release of
ParaView? [4]
This binary will be very likely be even compatible with 'standard' MPICH
installations; we're able to start it even with IntelMPI's 'mpiexec' with
success and no busy waiting. However YES you will need to have a MPICH release
be build




c)
It is possible to build 'pvserver' using Open MPI (and GCC compilers).
In [1] you document how-to 'turn off' the busy waiting behaviour in Open MPI
(cf. [5],[6]).
Unfortunately this *did not work* in our environment (InfiniBand QDR and Intel
OmniPath clusters, OpenMPI 1.10.4).
Note that likely we're not alone, cf. [7].
Note that the switch likely just move the spinning location from MPI library
itself to the fabrics library (cf. the screenshots, without 'mpi_yield_when_idle
1' (=default) the 'pvserver' processes spin with 'green' aka user 100%, and with
'mpi_yield_when_idle 1' the processes stays spinning but now with a lot of 'red'
aka kernel time portion.

Conclusion: the way to disable busy waiting for Open MPI which is documented in
[1], is not useful for us. We do not know this is a speciality of our site or a
general issue; we think some survey at this point could be useful.

Q/FR.3 In case you should want to provide precompiled versions ov 'pvserver' for
Open MPI, remember that there are ABI changes in major version changes. So you
would likely need to compile+link *three* versions of 'pvserver' with Open MPI
1.10.x (still default in Linux), 2.x (current), 3.x (new).



d) In [10] there is a phrase about how-to disable busy waiting on yet another
two MPI implementaions,
> ... IBM MPI has the MP_WAIT_MODE and
> the SUPER-UX MPI/XS library has MPISUSPEND to choose the waiting mode,
> either polling or sleeping.

Somebody with access to there MPIs could evaluate this, maybe.

Have a nice day,

Paul Kapinos



[1]
https://www.paraview.org/Wiki/Setting_up_a_ParaView_Server#Server_processes_always_have_100.25_CPU_usage

[2]
https://software.intel.com/sites/products/Whitepaper/Clustertools/amplxe_inspxe_interop_with_mpi.pdf
  (cf. p.10)

[3]
https://wiki.mpich.org/mpich/index.php/Frequently_Asked_Questions#Q:_Why_does_my_MPI_program_run_much_slower_when_I_use_more_processes.3F

[4] https://www.paraview.org/download/

[5] http://www.open-mpi.org/faq/?category=running#oversubscribing

[6] http://www.open-mpi.org/faq/?category=running#force-aggressive-degraded

[7] https://www.paraview.org/pipermail/paraview/2008-December/010349.html

[8] http://blogs.cisco.com/performance/polling-vs-blocking-message-passingprogress

[9] https://www.open-mpi.org/community/lists/users/2010/10/14505.php

[10] http://comp.parallel.mpi.narkive.com/3oXMDXno/non-busy-waiting-barrier-in-mpi

[11] http://blogs.cisco.com/performance/polling-vs-blocking-message-passingprogress

[12] https://stackoverflow.com/questions/14560714/probe-seems-to-consume-the-cpu


-- 
Dipl.-Inform. Paul Kapinos   -   High Performance Computing,
RWTH Aachen University, IT Center
Seffenter Weg 23,  D 52074  Aachen (Germany)
Tel: +49 241/80-24915


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4891 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171009/c3017a82/attachment.bin>

From cory.quammen at kitware.com  Mon Oct  9 10:18:53 2017
From: cory.quammen at kitware.com (Cory Quammen)
Date: Mon, 9 Oct 2017 07:18:53 -0700
Subject: [Paraview-developers] Dashboard whoas
Message-ID: <CAB5Fpx43O1QP9bQLDmvWrEPvEC8SEgF1fdgjWJu-teA4tHkaMg@mail.gmail.com>

Hi folks,

The ParaView dashboard is in a bad state. Please take a look at the
dashboard and address any problems that your recent changes may have caused.

https://open.cdash.org/index.php?project=ParaView

We have:

* Sphinx errors on vall
* vtkWrapHierarchy errors related to VTKm
* xdmf3 errors
* avtSiloFileFormat errors on pvbindash
* numpy build errors on bigmac
* CoProcessing errors on vall

Thank you for making the dashboard green,
Cory

-- 
Cory Quammen
Staff R&D Engineer
Kitware, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171009/b58e4962/attachment.html>

From utkarsh.ayachit at kitware.com  Mon Oct  9 10:23:09 2017
From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit)
Date: Mon, 9 Oct 2017 10:23:09 -0400
Subject: [Paraview-developers] Dashboard whoas
In-Reply-To: <CAB5Fpx43O1QP9bQLDmvWrEPvEC8SEgF1fdgjWJu-teA4tHkaMg@mail.gmail.com>
References: <CAB5Fpx43O1QP9bQLDmvWrEPvEC8SEgF1fdgjWJu-teA4tHkaMg@mail.gmail.com>
Message-ID: <CADHSJjCjVxpX2eKfT7UN8xiJ3J+b-etvkLoPZrTnB2433C9tdQ@mail.gmail.com>

To avoid multiple people looking at the same issue, here a spreadsheet.
Please add the issue and put your name next to an entry when you start
looking at it.

?
 Dashboard cleanup Oct 2017
<https://docs.google.com/a/kitware.com/spreadsheets/d/1gpgIfncRyGuLQDsCgh-4mFu_SmfyQWCcrYUpnoflaxo/edit?usp=drive_web>
?



On Mon, Oct 9, 2017 at 10:18 AM, Cory Quammen <cory.quammen at kitware.com>
wrote:

> Hi folks,
>
> The ParaView dashboard is in a bad state. Please take a look at the
> dashboard and address any problems that your recent changes may have caused.
>
> https://open.cdash.org/index.php?project=ParaView
>
> We have:
>
> * Sphinx errors on vall
> * vtkWrapHierarchy errors related to VTKm
> * xdmf3 errors
> * avtSiloFileFormat errors on pvbindash
> * numpy build errors on bigmac
> * CoProcessing errors on vall
>
> Thank you for making the dashboard green,
> Cory
>
> --
> Cory Quammen
> Staff R&D Engineer
> Kitware, Inc.
>
> _______________________________________________
> Powered by 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/20171009/f5b078da/attachment.html>

From cory.quammen at kitware.com  Mon Oct  9 10:43:43 2017
From: cory.quammen at kitware.com (Cory Quammen)
Date: Mon, 9 Oct 2017 07:43:43 -0700
Subject: [Paraview-developers] Dashboard whoas
In-Reply-To: <CAB5Fpx43O1QP9bQLDmvWrEPvEC8SEgF1fdgjWJu-teA4tHkaMg@mail.gmail.com>
References: <CAB5Fpx43O1QP9bQLDmvWrEPvEC8SEgF1fdgjWJu-teA4tHkaMg@mail.gmail.com>
Message-ID: <CAB5Fpx4Fw+hdt7FYBst+r3-dpV2_P5sW7fCCxuKn9hPvn3YU4A@mail.gmail.com>

Of course I meant "whoas" as in "Whoa! Look at the red on that dashboard!",
not "woes", though that would have worked :-)

On Mon, Oct 9, 2017 at 7:18 AM, Cory Quammen <cory.quammen at kitware.com>
wrote:

> Hi folks,
>
> The ParaView dashboard is in a bad state. Please take a look at the
> dashboard and address any problems that your recent changes may have caused.
>
> https://open.cdash.org/index.php?project=ParaView
>
> We have:
>
> * Sphinx errors on vall
> * vtkWrapHierarchy errors related to VTKm
> * xdmf3 errors
> * avtSiloFileFormat errors on pvbindash
> * numpy build errors on bigmac
> * CoProcessing errors on vall
>
> Thank you for making the dashboard green,
> Cory
>
> --
> Cory Quammen
> Staff R&D Engineer
> Kitware, Inc.
>



-- 
Cory Quammen
Staff R&D Engineer
Kitware, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171009/e3a6332e/attachment-0001.html>

From andy.bauer at kitware.com  Mon Oct  9 10:51:04 2017
From: andy.bauer at kitware.com (Andy Bauer)
Date: Mon, 9 Oct 2017 10:51:04 -0400
Subject: [Paraview-developers] Dashboard whoas
In-Reply-To: <CAB5Fpx4Fw+hdt7FYBst+r3-dpV2_P5sW7fCCxuKn9hPvn3YU4A@mail.gmail.com>
References: <CAB5Fpx43O1QP9bQLDmvWrEPvEC8SEgF1fdgjWJu-teA4tHkaMg@mail.gmail.com>
 <CAB5Fpx4Fw+hdt7FYBst+r3-dpV2_P5sW7fCCxuKn9hPvn3YU4A@mail.gmail.com>
Message-ID: <CAMaOp+HAye+dtYm1t4DxsN2+hkSWmqmDwrfabAxrw8LCpcf4jg@mail.gmail.com>

I don't see any coprocessing errors on Vall. Is this something that gets
hit after/without sphinx?

On Mon, Oct 9, 2017 at 10:43 AM, Cory Quammen <cory.quammen at kitware.com>
wrote:

> Of course I meant "whoas" as in "Whoa! Look at the red on that
> dashboard!", not "woes", though that would have worked :-)
>
> On Mon, Oct 9, 2017 at 7:18 AM, Cory Quammen <cory.quammen at kitware.com>
> wrote:
>
>> Hi folks,
>>
>> The ParaView dashboard is in a bad state. Please take a look at the
>> dashboard and address any problems that your recent changes may have caused.
>>
>> https://open.cdash.org/index.php?project=ParaView
>>
>> We have:
>>
>> * Sphinx errors on vall
>> * vtkWrapHierarchy errors related to VTKm
>> * xdmf3 errors
>> * avtSiloFileFormat errors on pvbindash
>> * numpy build errors on bigmac
>> * CoProcessing errors on vall
>>
>> Thank you for making the dashboard green,
>> Cory
>>
>> --
>> Cory Quammen
>> Staff R&D Engineer
>> Kitware, Inc.
>>
>
>
>
> --
> Cory Quammen
> Staff R&D Engineer
> Kitware, Inc.
>
> _______________________________________________
> Powered by 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/20171009/0291a0e4/attachment.html>

From utkarsh.ayachit at kitware.com  Mon Oct  9 13:08:23 2017
From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit)
Date: Mon, 9 Oct 2017 13:08:23 -0400
Subject: [Paraview-developers] Dashboard whoas
In-Reply-To: <CAMaOp+HAye+dtYm1t4DxsN2+hkSWmqmDwrfabAxrw8LCpcf4jg@mail.gmail.com>
References: <CAB5Fpx43O1QP9bQLDmvWrEPvEC8SEgF1fdgjWJu-teA4tHkaMg@mail.gmail.com>
 <CAB5Fpx4Fw+hdt7FYBst+r3-dpV2_P5sW7fCCxuKn9hPvn3YU4A@mail.gmail.com>
 <CAMaOp+HAye+dtYm1t4DxsN2+hkSWmqmDwrfabAxrw8LCpcf4jg@mail.gmail.com>
Message-ID: <CADHSJjCJnTjxUa1rL79N1kLX24LrMK5BKxxeRWbCzxMYb=-65g@mail.gmail.com>

On Mon, Oct 9, 2017 at 10:51 AM, Andy Bauer <andy.bauer at kitware.com> wrote:

> I don't see any coprocessing errors on Vall. Is this something that gets
> hit after/without sphinx?
>
>
That's correct. e.g.
https://open.cdash.org/viewBuildError.php?buildid=5094399

The Sphinx is now fixed in master, so you'll see it once buildbot gets
around to building `master`. In the mean time, look at any MR. Since we
don't build docs on MRs, it will skip the Sphinx issue.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171009/76165424/attachment.html>

From utkarsh.ayachit at kitware.com  Mon Oct  9 14:11:13 2017
From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit)
Date: Mon, 9 Oct 2017 14:11:13 -0400
Subject: [Paraview-developers] Dashboard whoas
In-Reply-To: <CADHSJjCJnTjxUa1rL79N1kLX24LrMK5BKxxeRWbCzxMYb=-65g@mail.gmail.com>
References: <CAB5Fpx43O1QP9bQLDmvWrEPvEC8SEgF1fdgjWJu-teA4tHkaMg@mail.gmail.com>
 <CAB5Fpx4Fw+hdt7FYBst+r3-dpV2_P5sW7fCCxuKn9hPvn3YU4A@mail.gmail.com>
 <CAMaOp+HAye+dtYm1t4DxsN2+hkSWmqmDwrfabAxrw8LCpcf4jg@mail.gmail.com>
 <CADHSJjCJnTjxUa1rL79N1kLX24LrMK5BKxxeRWbCzxMYb=-65g@mail.gmail.com>
Message-ID: <CADHSJjD9q2W1DPzqz3ydPd=CB7DiEpuEQvMkj9BUfPe+pi4ggg@mail.gmail.com>

Is anyone working on any issues? Looks like I am the only one taking
on tasks :).



On Mon, Oct 9, 2017 at 1:08 PM, Utkarsh Ayachit
<utkarsh.ayachit at kitware.com> wrote:
> On Mon, Oct 9, 2017 at 10:51 AM, Andy Bauer <andy.bauer at kitware.com> wrote:
>>
>> I don't see any coprocessing errors on Vall. Is this something that gets
>> hit after/without sphinx?
>>
>
> That's correct. e.g.
> https://open.cdash.org/viewBuildError.php?buildid=5094399
>
> The Sphinx is now fixed in master, so you'll see it once buildbot gets
> around to building `master`. In the mean time, look at any MR. Since we
> don't build docs on MRs, it will skip the Sphinx issue.

From cory.quammen at kitware.com  Mon Oct  9 14:24:35 2017
From: cory.quammen at kitware.com (Cory Quammen)
Date: Mon, 9 Oct 2017 14:24:35 -0400
Subject: [Paraview-developers] Dashboard whoas
In-Reply-To: <CADHSJjD9q2W1DPzqz3ydPd=CB7DiEpuEQvMkj9BUfPe+pi4ggg@mail.gmail.com>
References: <CAB5Fpx43O1QP9bQLDmvWrEPvEC8SEgF1fdgjWJu-teA4tHkaMg@mail.gmail.com>
 <CAB5Fpx4Fw+hdt7FYBst+r3-dpV2_P5sW7fCCxuKn9hPvn3YU4A@mail.gmail.com>
 <CAMaOp+HAye+dtYm1t4DxsN2+hkSWmqmDwrfabAxrw8LCpcf4jg@mail.gmail.com>
 <CADHSJjCJnTjxUa1rL79N1kLX24LrMK5BKxxeRWbCzxMYb=-65g@mail.gmail.com>
 <CADHSJjD9q2W1DPzqz3ydPd=CB7DiEpuEQvMkj9BUfPe+pi4ggg@mail.gmail.com>
Message-ID: <CAB5Fpx6Wvsb=2BHYzdLmEqo_UqqS3mzYD7jEzGGK3_yExFNWvw@mail.gmail.com>

I'm taking a look at the VisIt bridge failure, possibly linked to the VTK
decaprathon.

On Mon, Oct 9, 2017 at 2:11 PM, Utkarsh Ayachit <utkarsh.ayachit at kitware.com
> wrote:

> Is anyone working on any issues? Looks like I am the only one taking
> on tasks :).
>
>
>
> On Mon, Oct 9, 2017 at 1:08 PM, Utkarsh Ayachit
> <utkarsh.ayachit at kitware.com> wrote:
> > On Mon, Oct 9, 2017 at 10:51 AM, Andy Bauer <andy.bauer at kitware.com>
> wrote:
> >>
> >> I don't see any coprocessing errors on Vall. Is this something that gets
> >> hit after/without sphinx?
> >>
> >
> > That's correct. e.g.
> > https://open.cdash.org/viewBuildError.php?buildid=5094399
> >
> > The Sphinx is now fixed in master, so you'll see it once buildbot gets
> > around to building `master`. In the mean time, look at any MR. Since we
> > don't build docs on MRs, it will skip the Sphinx issue.
>



-- 
Cory Quammen
Staff R&D Engineer
Kitware, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171009/bf26112d/attachment.html>

From utkarsh.ayachit at kitware.com  Mon Oct  9 14:28:07 2017
From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit)
Date: Mon, 9 Oct 2017 14:28:07 -0400
Subject: [Paraview-developers] Dashboard whoas
In-Reply-To: <CAB5Fpx6Wvsb=2BHYzdLmEqo_UqqS3mzYD7jEzGGK3_yExFNWvw@mail.gmail.com>
References: <CAB5Fpx43O1QP9bQLDmvWrEPvEC8SEgF1fdgjWJu-teA4tHkaMg@mail.gmail.com>
 <CAB5Fpx4Fw+hdt7FYBst+r3-dpV2_P5sW7fCCxuKn9hPvn3YU4A@mail.gmail.com>
 <CAMaOp+HAye+dtYm1t4DxsN2+hkSWmqmDwrfabAxrw8LCpcf4jg@mail.gmail.com>
 <CADHSJjCJnTjxUa1rL79N1kLX24LrMK5BKxxeRWbCzxMYb=-65g@mail.gmail.com>
 <CADHSJjD9q2W1DPzqz3ydPd=CB7DiEpuEQvMkj9BUfPe+pi4ggg@mail.gmail.com>
 <CAB5Fpx6Wvsb=2BHYzdLmEqo_UqqS3mzYD7jEzGGK3_yExFNWvw@mail.gmail.com>
Message-ID: <CADHSJjAQOUkdQV5jNV_AZmKCUf82RDELJuwfWHyZQoH=kT_9qQ@mail.gmail.com>

Too late...already fixed it ;)

On Mon, Oct 9, 2017 at 2:24 PM, Cory Quammen <cory.quammen at kitware.com> wrote:
> I'm taking a look at the VisIt bridge failure, possibly linked to the VTK
> decaprathon.
>
> On Mon, Oct 9, 2017 at 2:11 PM, Utkarsh Ayachit
> <utkarsh.ayachit at kitware.com> wrote:
>>
>> Is anyone working on any issues? Looks like I am the only one taking
>> on tasks :).
>>
>>
>>
>> On Mon, Oct 9, 2017 at 1:08 PM, Utkarsh Ayachit
>> <utkarsh.ayachit at kitware.com> wrote:
>> > On Mon, Oct 9, 2017 at 10:51 AM, Andy Bauer <andy.bauer at kitware.com>
>> > wrote:
>> >>
>> >> I don't see any coprocessing errors on Vall. Is this something that
>> >> gets
>> >> hit after/without sphinx?
>> >>
>> >
>> > That's correct. e.g.
>> > https://open.cdash.org/viewBuildError.php?buildid=5094399
>> >
>> > The Sphinx is now fixed in master, so you'll see it once buildbot gets
>> > around to building `master`. In the mean time, look at any MR. Since we
>> > don't build docs on MRs, it will skip the Sphinx issue.
>
>
>
>
> --
> Cory Quammen
> Staff R&D Engineer
> Kitware, Inc.

From utkarsh.ayachit at kitware.com  Mon Oct  9 15:37:08 2017
From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit)
Date: Mon, 9 Oct 2017 15:37:08 -0400
Subject: [Paraview-developers] Dashboard whoas
In-Reply-To: <CADHSJjCJnTjxUa1rL79N1kLX24LrMK5BKxxeRWbCzxMYb=-65g@mail.gmail.com>
References: <CAB5Fpx43O1QP9bQLDmvWrEPvEC8SEgF1fdgjWJu-teA4tHkaMg@mail.gmail.com>
 <CAB5Fpx4Fw+hdt7FYBst+r3-dpV2_P5sW7fCCxuKn9hPvn3YU4A@mail.gmail.com>
 <CAMaOp+HAye+dtYm1t4DxsN2+hkSWmqmDwrfabAxrw8LCpcf4jg@mail.gmail.com>
 <CADHSJjCJnTjxUa1rL79N1kLX24LrMK5BKxxeRWbCzxMYb=-65g@mail.gmail.com>
Message-ID: <CADHSJjD_C1JOGzeUY1-jhTKXqZ5kv1HySEQCmAsN71kok15++A@mail.gmail.com>

Andy,

This MR may address vall issues too, not sure:
https://gitlab.kitware.com/paraview/paraview/merge_requests/1957
Just FYI.

Utkarsh

On Mon, Oct 9, 2017 at 1:08 PM, Utkarsh Ayachit
<utkarsh.ayachit at kitware.com> wrote:
> On Mon, Oct 9, 2017 at 10:51 AM, Andy Bauer <andy.bauer at kitware.com> wrote:
>>
>> I don't see any coprocessing errors on Vall. Is this something that gets
>> hit after/without sphinx?
>>
>
> That's correct. e.g.
> https://open.cdash.org/viewBuildError.php?buildid=5094399
>
> The Sphinx is now fixed in master, so you'll see it once buildbot gets
> around to building `master`. In the mean time, look at any MR. Since we
> don't build docs on MRs, it will skip the Sphinx issue.

From andy.bauer at kitware.com  Mon Oct  9 15:40:03 2017
From: andy.bauer at kitware.com (Andy Bauer)
Date: Mon, 9 Oct 2017 15:40:03 -0400
Subject: [Paraview-developers] Dashboard whoas
In-Reply-To: <CADHSJjD_C1JOGzeUY1-jhTKXqZ5kv1HySEQCmAsN71kok15++A@mail.gmail.com>
References: <CAB5Fpx43O1QP9bQLDmvWrEPvEC8SEgF1fdgjWJu-teA4tHkaMg@mail.gmail.com>
 <CAB5Fpx4Fw+hdt7FYBst+r3-dpV2_P5sW7fCCxuKn9hPvn3YU4A@mail.gmail.com>
 <CAMaOp+HAye+dtYm1t4DxsN2+hkSWmqmDwrfabAxrw8LCpcf4jg@mail.gmail.com>
 <CADHSJjCJnTjxUa1rL79N1kLX24LrMK5BKxxeRWbCzxMYb=-65g@mail.gmail.com>
 <CADHSJjD_C1JOGzeUY1-jhTKXqZ5kv1HySEQCmAsN71kok15++A@mail.gmail.com>
Message-ID: <CAMaOp+E6Yw3GBs=nZ0Vvg4Dg5kCcC9mV2EGeNfu=uuMe58K1FQ@mail.gmail.com>

I wasn't planning to get to that until tomorrow anyway. I'll check on the
status before working on it though.

On Mon, Oct 9, 2017 at 3:37 PM, Utkarsh Ayachit <utkarsh.ayachit at kitware.com
> wrote:

> Andy,
>
> This MR may address vall issues too, not sure:
> https://gitlab.kitware.com/paraview/paraview/merge_requests/1957
> Just FYI.
>
> Utkarsh
>
> On Mon, Oct 9, 2017 at 1:08 PM, Utkarsh Ayachit
> <utkarsh.ayachit at kitware.com> wrote:
> > On Mon, Oct 9, 2017 at 10:51 AM, Andy Bauer <andy.bauer at kitware.com>
> wrote:
> >>
> >> I don't see any coprocessing errors on Vall. Is this something that gets
> >> hit after/without sphinx?
> >>
> >
> > That's correct. e.g.
> > https://open.cdash.org/viewBuildError.php?buildid=5094399
> >
> > The Sphinx is now fixed in master, so you'll see it once buildbot gets
> > around to building `master`. In the mean time, look at any MR. Since we
> > don't build docs on MRs, it will skip the Sphinx issue.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171009/0cdb34e6/attachment-0001.html>

From kmorel at sandia.gov  Mon Oct  9 17:27:39 2017
From: kmorel at sandia.gov (Moreland, Kenneth)
Date: Mon, 9 Oct 2017 21:27:39 +0000
Subject: [Paraview-developers] 100% CPU usage once again
Message-ID: <91a3cc1114784287a3842eb6b899256e@ES08AMSNLNT.srn.sandia.gov>

Paul,

Thanks for the info. I updated the Wiki page with your information. Hopefully I captured everything.

I'll let someone from Kitware respond about the possibility of changing the binaries that are distributed.

-Ken

-----Original Message-----
From: Paraview-developers [mailto:paraview-developers-bounces at paraview.org] On Behalf Of Paul Kapinos
Sent: Monday, October 9, 2017 1:08 AM
To: paraview-developers at paraview.org
Subject: [EXTERNAL] [Paraview-developers] 100% CPU usage once again

(cross-post from 'paraview at paraview.org' 10/04/2017)

Dear ParaView developer,

in [1] you say
> If you have information on disabling the busy wait using a different 
> MPI implementation, please contribute back by documenting it here.

Here we go.

a)
It is possible to build 'pvserver' using Intel MPI (and GCC compilers).
By setting I_MPI_WAIT_MODE  environment variable to 'enable' value you can effectively prevent busy waiting, see [2] p.10 (Tested with Intel MPI 5.1(.3.181)).

Q/FR.1 Could you please provide a version of 'pvserver' build using Intel MPI in official release of ParaView? [4]



b)
It is (obviously) possible to build 'pvserver' using MPICH (and GCC compilers).
Itself, MPICH can be *configured* with '--with-device=ch3:sock' option. This is described to be 'slower' as '--with-device=ch3:nemesis'
For our experiments it turned out, that 'pvserver' compiled and linked using MPICH with 'ch3:sock' configure option did not have the busy waiting aka 100%-CPU behaviour.
Note that this is *configure-time of MPI library* parameter.


(Tested with MPICH  3.2)

Q/FR.2 Could you please provide a version of 'pvserver' build using MPICH *configured with '--with-device=ch3:sock' option* in official release of ParaView? [4] This binary will be very likely be even compatible with 'standard' MPICH installations; we're able to start it even with IntelMPI's 'mpiexec' with success and no busy waiting. However YES you will need to have a MPICH release be build




c)
It is possible to build 'pvserver' using Open MPI (and GCC compilers).
In [1] you document how-to 'turn off' the busy waiting behaviour in Open MPI (cf. [5],[6]).
Unfortunately this *did not work* in our environment (InfiniBand QDR and Intel OmniPath clusters, OpenMPI 1.10.4).
Note that likely we're not alone, cf. [7].
Note that the switch likely just move the spinning location from MPI library itself to the fabrics library (cf. the screenshots, without 'mpi_yield_when_idle 1' (=default) the 'pvserver' processes spin with 'green' aka user 100%, and with 'mpi_yield_when_idle 1' the processes stays spinning but now with a lot of 'red'
aka kernel time portion.

Conclusion: the way to disable busy waiting for Open MPI which is documented in [1], is not useful for us. We do not know this is a speciality of our site or a general issue; we think some survey at this point could be useful.

Q/FR.3 In case you should want to provide precompiled versions ov 'pvserver' for Open MPI, remember that there are ABI changes in major version changes. So you would likely need to compile+link *three* versions of 'pvserver' with Open MPI 1.10.x (still default in Linux), 2.x (current), 3.x (new).



d) In [10] there is a phrase about how-to disable busy waiting on yet another two MPI implementaions,
> ... IBM MPI has the MP_WAIT_MODE and
> the SUPER-UX MPI/XS library has MPISUSPEND to choose the waiting mode, 
> either polling or sleeping.

Somebody with access to there MPIs could evaluate this, maybe.

Have a nice day,

Paul Kapinos



[1]
https://www.paraview.org/Wiki/Setting_up_a_ParaView_Server#Server_processes_always_have_100.25_CPU_usage

[2]
https://software.intel.com/sites/products/Whitepaper/Clustertools/amplxe_inspxe_interop_with_mpi.pdf
  (cf. p.10)

[3]
https://wiki.mpich.org/mpich/index.php/Frequently_Asked_Questions#Q:_Why_does_my_MPI_program_run_much_slower_when_I_use_more_processes.3F

[4] https://www.paraview.org/download/

[5] http://www.open-mpi.org/faq/?category=running#oversubscribing

[6] http://www.open-mpi.org/faq/?category=running#force-aggressive-degraded

[7] https://www.paraview.org/pipermail/paraview/2008-December/010349.html

[8] http://blogs.cisco.com/performance/polling-vs-blocking-message-passingprogress

[9] https://www.open-mpi.org/community/lists/users/2010/10/14505.php

[10] http://comp.parallel.mpi.narkive.com/3oXMDXno/non-busy-waiting-barrier-in-mpi

[11] http://blogs.cisco.com/performance/polling-vs-blocking-message-passingprogress

[12] https://stackoverflow.com/questions/14560714/probe-seems-to-consume-the-cpu


-- 
Dipl.-Inform. Paul Kapinos   -   High Performance Computing,
RWTH Aachen University, IT Center
Seffenter Weg 23,  D 52074  Aachen (Germany)
Tel: +49 241/80-24915



From utkarsh.ayachit at kitware.com  Tue Oct 10 08:54:27 2017
From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit)
Date: Tue, 10 Oct 2017 08:54:27 -0400
Subject: [Paraview-developers] Dashboard whoas
In-Reply-To: <CAMaOp+E6Yw3GBs=nZ0Vvg4Dg5kCcC9mV2EGeNfu=uuMe58K1FQ@mail.gmail.com>
References: <CAB5Fpx43O1QP9bQLDmvWrEPvEC8SEgF1fdgjWJu-teA4tHkaMg@mail.gmail.com>
 <CAB5Fpx4Fw+hdt7FYBst+r3-dpV2_P5sW7fCCxuKn9hPvn3YU4A@mail.gmail.com>
 <CAMaOp+HAye+dtYm1t4DxsN2+hkSWmqmDwrfabAxrw8LCpcf4jg@mail.gmail.com>
 <CADHSJjCJnTjxUa1rL79N1kLX24LrMK5BKxxeRWbCzxMYb=-65g@mail.gmail.com>
 <CADHSJjD_C1JOGzeUY1-jhTKXqZ5kv1HySEQCmAsN71kok15++A@mail.gmail.com>
 <CAMaOp+E6Yw3GBs=nZ0Vvg4Dg5kCcC9mV2EGeNfu=uuMe58K1FQ@mail.gmail.com>
Message-ID: <CADHSJjCYx82cgBZ3wbuT_t-2kTL8VN1dXUbkunW5dRh8jzJPew@mail.gmail.com>

Dashboards should be in much better shape this morning. Please rebase
all your ongoing branches on the latest master before testing since
the changes in master which update VTK are extensive and cause all of
ParaView to rebuild. Testing old branches will force the dashboard
machines to do a complete rebuild as they switch between branches.




On Mon, Oct 9, 2017 at 3:40 PM, Andy Bauer <andy.bauer at kitware.com> wrote:
> I wasn't planning to get to that until tomorrow anyway. I'll check on the
> status before working on it though.
>
> On Mon, Oct 9, 2017 at 3:37 PM, Utkarsh Ayachit
> <utkarsh.ayachit at kitware.com> wrote:
>>
>> Andy,
>>
>> This MR may address vall issues too, not sure:
>> https://gitlab.kitware.com/paraview/paraview/merge_requests/1957
>> Just FYI.
>>
>> Utkarsh
>>
>> On Mon, Oct 9, 2017 at 1:08 PM, Utkarsh Ayachit
>> <utkarsh.ayachit at kitware.com> wrote:
>> > On Mon, Oct 9, 2017 at 10:51 AM, Andy Bauer <andy.bauer at kitware.com>
>> > wrote:
>> >>
>> >> I don't see any coprocessing errors on Vall. Is this something that
>> >> gets
>> >> hit after/without sphinx?
>> >>
>> >
>> > That's correct. e.g.
>> > https://open.cdash.org/viewBuildError.php?buildid=5094399
>> >
>> > The Sphinx is now fixed in master, so you'll see it once buildbot gets
>> > around to building `master`. In the mean time, look at any MR. Since we
>> > don't build docs on MRs, it will skip the Sphinx issue.
>
>

From dave.demarle at kitware.com  Wed Oct 11 09:44:42 2017
From: dave.demarle at kitware.com (David E DeMarle)
Date: Wed, 11 Oct 2017 09:44:42 -0400
Subject: [Paraview-developers] Dashboard whoas
In-Reply-To: <CADHSJjCYx82cgBZ3wbuT_t-2kTL8VN1dXUbkunW5dRh8jzJPew@mail.gmail.com>
References: <CAB5Fpx43O1QP9bQLDmvWrEPvEC8SEgF1fdgjWJu-teA4tHkaMg@mail.gmail.com>
 <CAB5Fpx4Fw+hdt7FYBst+r3-dpV2_P5sW7fCCxuKn9hPvn3YU4A@mail.gmail.com>
 <CAMaOp+HAye+dtYm1t4DxsN2+hkSWmqmDwrfabAxrw8LCpcf4jg@mail.gmail.com>
 <CADHSJjCJnTjxUa1rL79N1kLX24LrMK5BKxxeRWbCzxMYb=-65g@mail.gmail.com>
 <CADHSJjD_C1JOGzeUY1-jhTKXqZ5kv1HySEQCmAsN71kok15++A@mail.gmail.com>
 <CAMaOp+E6Yw3GBs=nZ0Vvg4Dg5kCcC9mV2EGeNfu=uuMe58K1FQ@mail.gmail.com>
 <CADHSJjCYx82cgBZ3wbuT_t-2kTL8VN1dXUbkunW5dRh8jzJPew@mail.gmail.com>
Message-ID: <CANjZAi_G=Bv+Ap3UNkbOD7wUOAw9wn-sgCSF0z+kZpXGNgN2vA@mail.gmail.com>

I'll look at the xdmf windows package problems today.


David E DeMarle
Kitware, Inc.
Principal Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909

On Tue, Oct 10, 2017 at 8:54 AM, Utkarsh Ayachit <
utkarsh.ayachit at kitware.com> wrote:

> Dashboards should be in much better shape this morning. Please rebase
> all your ongoing branches on the latest master before testing since
> the changes in master which update VTK are extensive and cause all of
> ParaView to rebuild. Testing old branches will force the dashboard
> machines to do a complete rebuild as they switch between branches.
>
>
>
>
> On Mon, Oct 9, 2017 at 3:40 PM, Andy Bauer <andy.bauer at kitware.com> wrote:
> > I wasn't planning to get to that until tomorrow anyway. I'll check on the
> > status before working on it though.
> >
> > On Mon, Oct 9, 2017 at 3:37 PM, Utkarsh Ayachit
> > <utkarsh.ayachit at kitware.com> wrote:
> >>
> >> Andy,
> >>
> >> This MR may address vall issues too, not sure:
> >> https://gitlab.kitware.com/paraview/paraview/merge_requests/1957
> >> Just FYI.
> >>
> >> Utkarsh
> >>
> >> On Mon, Oct 9, 2017 at 1:08 PM, Utkarsh Ayachit
> >> <utkarsh.ayachit at kitware.com> wrote:
> >> > On Mon, Oct 9, 2017 at 10:51 AM, Andy Bauer <andy.bauer at kitware.com>
> >> > wrote:
> >> >>
> >> >> I don't see any coprocessing errors on Vall. Is this something that
> >> >> gets
> >> >> hit after/without sphinx?
> >> >>
> >> >
> >> > That's correct. e.g.
> >> > https://open.cdash.org/viewBuildError.php?buildid=5094399
> >> >
> >> > The Sphinx is now fixed in master, so you'll see it once buildbot gets
> >> > around to building `master`. In the mean time, look at any MR. Since
> we
> >> > don't build docs on MRs, it will skip the Sphinx issue.
> >
> >
> _______________________________________________
> Powered by 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/20171011/09915be8/attachment.html>

From jfavre at cscs.ch  Wed Oct 11 11:03:23 2017
From: jfavre at cscs.ch (Favre  Jean)
Date: Wed, 11 Oct 2017 15:03:23 +0000
Subject: [Paraview-developers] pvserver with multiple EGL devices
Message-ID: <0EB9B6375711A04B820E6B6F5CCA9F685C9C6255@MBX211.d.ethz.ch>

Folks

I've used EGL for a long time now, but always with a single GPU. I understand it well.

I have a new cluster with *two* GPUs on the node and a more recent driver, where I compiled 5.4 with EGL and OpenMPI

Launching pvserver, and connecting I get this error:

mpirun  -np 1 ./bin/pvserver --egl-device-index=0  : -np 1 ./bin/pvserver --egl-device-index=1

Waiting for client...
Connection URL: cs://greina28:11111
Accepting connection(s): greina28:11111
Client connected.
Warning: In /users/jfavre/ParaView/ParaView-v5.4.1/VTK/Rendering/OpenGL2/vtkEGLRenderWindow.cxx, line 272
vtkEGLRenderWindow (0xed65a0): Setting an EGL display to device index: 0 require EGL_EXT_device_base EGL_EXT_platform_device EGL_EXT_platform_base extensions

ERROR: In /users/jfavre/ParaView/ParaView-v5.4.1/VTK/Rendering/OpenGL2/vtkEGLRenderWindow.cxx, line 341
vtkEGLRenderWindow (0xed65a0): Only EGL 1.4 and greater allows OpenGL as client API. See eglBindAPI for more information.

ERROR: In /users/jfavre/ParaView/ParaView-v5.4.1/VTK/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx, line 819
vtkEGLRenderWindow (0xed65a0): GLEW could not be initialized.

yet, my ./bin/pvserver depends on

    libEGL.so.1 => /usr/lib64/libEGL.so.1 (0x00002aaabc2c8000)
    libOpenGL.so.0 => /usr/lib64/libOpenGL.so.0 (0x00002aaabc4f5000)
    libGLdispatch.so.0 => /usr/lib64/libGLdispatch.so.0 (0x00002aaabc72a000)

and nvidia-smi reports a driver which should support EGL1.4 and greater.

Wed Oct 11 17:00:24 2017
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 384.59                 Driver Version: 384.59                    |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  Tesla P100-SXM2...  On   | 00000000:07:00.0 Off |                  Off |
| N/A   30C    P0    30W / 300W |      0MiB / 16276MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+
|   1  Tesla P100-SXM2...  On   | 00000000:84:00.0 Off |                  Off |
| N/A   32C    P0    31W / 300W |      0MiB / 16276MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+


what setting should I be specifically careful with to overcome this error?

TIA
-----------------
Jean / CSCS

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171011/a4e9d43a/attachment.html>

From dan.lipsa at kitware.com  Wed Oct 11 11:29:47 2017
From: dan.lipsa at kitware.com (Dan Lipsa)
Date: Wed, 11 Oct 2017 11:29:47 -0400
Subject: [Paraview-developers] pvserver with multiple EGL devices
In-Reply-To: <0EB9B6375711A04B820E6B6F5CCA9F685C9C6255@MBX211.d.ethz.ch>
References: <0EB9B6375711A04B820E6B6F5CCA9F685C9C6255@MBX211.d.ethz.ch>
Message-ID: <CADwGrVq=D9e6=gFZY21GnvcsCMXFsYZEJUmcdM=q9Pk-x6G2cw@mail.gmail.com>

Jean,
If you use only
mpirun  -np 1 ./bin/pvserver --egl-device-index=1. Does that work
corrrectly?
Can you see in client that it uses device 1?
Help, About, Connection Information, OpenGL Renderer.
I know we had a bug with how this parameter was passed, but the bug has
been fixed a while ago.


What about
mpirun  -np 1 ./bin/pvserver
(which should use device 0). Does that work?

Thanks,
Dan



On Wed, Oct 11, 2017 at 11:03 AM, Favre Jean <jfavre at cscs.ch> wrote:

> Folks
>
> I've used EGL for a long time now, but always with a single GPU. I
> understand it well.
>
> I have a new cluster with *two* GPUs on the node and a more recent driver,
> where I compiled 5.4 with EGL and OpenMPI
>
> Launching pvserver, and connecting I get this error:
>
> mpirun  -np 1 ./bin/pvserver --egl-device-index=0  : -np 1 ./bin/pvserver
> --egl-device-index=1
>
> Waiting for client...
> Connection URL: cs://greina28:11111
> Accepting connection(s): greina28:11111
> Client connected.
> Warning: In /users/jfavre/ParaView/ParaView-v5.4.1/VTK/Rendering/
> OpenGL2/vtkEGLRenderWindow.cxx, line 272
> vtkEGLRenderWindow (0xed65a0): Setting an EGL display to device index: 0
> require EGL_EXT_device_base EGL_EXT_platform_device EGL_EXT_platform_base
> extensions
>
> ERROR: In /users/jfavre/ParaView/ParaView-v5.4.1/VTK/Rendering/
> OpenGL2/vtkEGLRenderWindow.cxx, line 341
> vtkEGLRenderWindow (0xed65a0): Only EGL 1.4 and greater allows OpenGL as
> client API. See eglBindAPI for more information.
>
> ERROR: In /users/jfavre/ParaView/ParaView-v5.4.1/VTK/Rendering/
> OpenGL2/vtkOpenGLRenderWindow.cxx, line 819
> vtkEGLRenderWindow (0xed65a0): GLEW could not be initialized.
>
> yet, my ./bin/pvserver depends on
>
>     libEGL.so.1 => /usr/lib64/libEGL.so.1 (0x00002aaabc2c8000)
>     libOpenGL.so.0 => /usr/lib64/libOpenGL.so.0 (0x00002aaabc4f5000)
>     libGLdispatch.so.0 => /usr/lib64/libGLdispatch.so.0
> (0x00002aaabc72a000)
>
> and nvidia-smi reports a driver which should support EGL1.4 and greater.
>
> Wed Oct 11 17:00:24 2017
> +-----------------------------------------------------------
> ------------------+
> | NVIDIA-SMI 384.59                 Driver Version:
> 384.59                    |
> |-------------------------------+----------------------+----
> ------------------+
> | GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr.
> ECC |
> | Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute
> M. |
> |===============================+======================+====
> ==================|
> |   0  Tesla P100-SXM2...  On   | 00000000:07:00.0 Off |
> Off |
> | N/A   30C    P0    30W / 300W |      0MiB / 16276MiB |      0%
> Default |
> +-------------------------------+----------------------+----
> ------------------+
> |   1  Tesla P100-SXM2...  On   | 00000000:84:00.0 Off |
> Off |
> | N/A   32C    P0    31W / 300W |      0MiB / 16276MiB |      0%
> Default |
> +-------------------------------+----------------------+----
> ------------------+
>
>
> what setting should I be specifically careful with to overcome this error?
>
> TIA
> -----------------
> Jean / CSCS
>
>
> _______________________________________________
> Powered by 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/20171011/7ddbce81/attachment-0001.html>

From jfavre at cscs.ch  Wed Oct 11 11:36:40 2017
From: jfavre at cscs.ch (Favre  Jean)
Date: Wed, 11 Oct 2017 15:36:40 +0000
Subject: [Paraview-developers] pvserver with multiple EGL devices
In-Reply-To: <CADwGrVq=D9e6=gFZY21GnvcsCMXFsYZEJUmcdM=q9Pk-x6G2cw@mail.gmail.com>
References: <0EB9B6375711A04B820E6B6F5CCA9F685C9C6255@MBX211.d.ethz.ch>,
 <CADwGrVq=D9e6=gFZY21GnvcsCMXFsYZEJUmcdM=q9Pk-x6G2cw@mail.gmail.com>
Message-ID: <0EB9B6375711A04B820E6B6F5CCA9F685C9C629A@MBX211.d.ethz.ch>


>> mpirun  -np 1 ./bin/pvserver --egl-device-index=1.

>> mpirun  -np 1 ./bin/pvserver

neither one works. I get an empty

OpenGL Vendor
OpenGL Version
OpenGL Renderer

Jean


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171011/9b5cabd9/attachment.html>

From jfavre at cscs.ch  Wed Oct 11 11:47:45 2017
From: jfavre at cscs.ch (Favre  Jean)
Date: Wed, 11 Oct 2017 15:47:45 +0000
Subject: [Paraview-developers] pvserver with multiple EGL devices
In-Reply-To: <0EB9B6375711A04B820E6B6F5CCA9F685C9C629A@MBX211.d.ethz.ch>
References: <0EB9B6375711A04B820E6B6F5CCA9F685C9C6255@MBX211.d.ethz.ch>,
 <CADwGrVq=D9e6=gFZY21GnvcsCMXFsYZEJUmcdM=q9Pk-x6G2cw@mail.gmail.com>,
 <0EB9B6375711A04B820E6B6F5CCA9F685C9C629A@MBX211.d.ethz.ch>
Message-ID: <0EB9B6375711A04B820E6B6F5CCA9F685C9C62D7@MBX211.d.ethz.ch>

Hold on. I might have a driver that is too new.

A basic EGL test (without ParaView) fails.

I'll report later on. Thanks
Jean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171011/e0ad1f07/attachment.html>

From kapinos at itc.rwth-aachen.de  Wed Oct 11 12:18:57 2017
From: kapinos at itc.rwth-aachen.de (Paul Kapinos)
Date: Wed, 11 Oct 2017 18:18:57 +0200
Subject: [Paraview-developers] 100% CPU usage once again
In-Reply-To: <91a3cc1114784287a3842eb6b899256e@ES08AMSNLNT.srn.sandia.gov>
References: <91a3cc1114784287a3842eb6b899256e@ES08AMSNLNT.srn.sandia.gov>
Message-ID: <babee0ee-2c10-8a41-2843-834aa4294963@itc.rwth-aachen.de>

Kenneth, thank you for your message and the update of the wiki!

Meanwhile I was able to reproduce the busy waiting with Open MPI (and other
MPIs) on a 10-line-example and asked the Open MPI developers about this:
https://www.mail-archive.com/devel at lists.open-mpi.org//msg20407.html

The spinning processes stuck at MPI_Barrier call in line 40 of
'ParaView-v5.4.1/VTK/Parallel/MPI/vtkMPICommunicator.cxx' file,
>     34 static inline void  vtkMPICommunicatorDebugBarrier(MPI_Comm* handle)
>     35 {
>     36   // If NDEBUG is defined, do nothing.
>     37 #ifdef NDEBUG
>     38   (void)handle; // to avoid warning about unused parameter
>     39 #else
>     40   MPI_Barrier(*handle);
>     41 #endif
>     42 }
It seem that ParaView's auto-build VTK version is build without NDEBUG define,
or with other words, *with* debug stuff.

Q: Is there a way to tell the ParaView's configure to set the VTK's define
'NDEBUG'? Or, more general, how-to tune VTK parameters? :o)

Have a nice day,

Paul Kapinos





On 10/09/2017 11:27 PM, Moreland, Kenneth wrote:
> Paul,
> 
> Thanks for the info. I updated the Wiki page with your information. Hopefully I captured everything.
> 
> I'll let someone from Kitware respond about the possibility of changing the binaries that are distributed.
> 
> -Ken
> 
> -----Original Message-----
> From: Paraview-developers [mailto:paraview-developers-bounces at paraview.org] On Behalf Of Paul Kapinos
> Sent: Monday, October 9, 2017 1:08 AM
> To: paraview-developers at paraview.org
> Subject: [EXTERNAL] [Paraview-developers] 100% CPU usage once again
> 
> (cross-post from 'paraview at paraview.org' 10/04/2017)
> 
> Dear ParaView developer,
> 
> in [1] you say
>> If you have information on disabling the busy wait using a different 
>> MPI implementation, please contribute back by documenting it here.
> 
> Here we go.
> 
> a)
> It is possible to build 'pvserver' using Intel MPI (and GCC compilers).
> By setting I_MPI_WAIT_MODE  environment variable to 'enable' value you can effectively prevent busy waiting, see [2] p.10 (Tested with Intel MPI 5.1(.3.181)).
> 
> Q/FR.1 Could you please provide a version of 'pvserver' build using Intel MPI in official release of ParaView? [4]
> 
> 
> 
> b)
> It is (obviously) possible to build 'pvserver' using MPICH (and GCC compilers).
> Itself, MPICH can be *configured* with '--with-device=ch3:sock' option. This is described to be 'slower' as '--with-device=ch3:nemesis'
> For our experiments it turned out, that 'pvserver' compiled and linked using MPICH with 'ch3:sock' configure option did not have the busy waiting aka 100%-CPU behaviour.
> Note that this is *configure-time of MPI library* parameter.
> 
> 
> (Tested with MPICH  3.2)
> 
> Q/FR.2 Could you please provide a version of 'pvserver' build using MPICH *configured with '--with-device=ch3:sock' option* in official release of ParaView? [4] This binary will be very likely be even compatible with 'standard' MPICH installations; we're able to start it even with IntelMPI's 'mpiexec' with success and no busy waiting. However YES you will need to have a MPICH release be build
> 
> 
> 
> 
> c)
> It is possible to build 'pvserver' using Open MPI (and GCC compilers).
> In [1] you document how-to 'turn off' the busy waiting behaviour in Open MPI (cf. [5],[6]).
> Unfortunately this *did not work* in our environment (InfiniBand QDR and Intel OmniPath clusters, OpenMPI 1.10.4).
> Note that likely we're not alone, cf. [7].
> Note that the switch likely just move the spinning location from MPI library itself to the fabrics library (cf. the screenshots, without 'mpi_yield_when_idle 1' (=default) the 'pvserver' processes spin with 'green' aka user 100%, and with 'mpi_yield_when_idle 1' the processes stays spinning but now with a lot of 'red'
> aka kernel time portion.
> 
> Conclusion: the way to disable busy waiting for Open MPI which is documented in [1], is not useful for us. We do not know this is a speciality of our site or a general issue; we think some survey at this point could be useful.
> 
> Q/FR.3 In case you should want to provide precompiled versions ov 'pvserver' for Open MPI, remember that there are ABI changes in major version changes. So you would likely need to compile+link *three* versions of 'pvserver' with Open MPI 1.10.x (still default in Linux), 2.x (current), 3.x (new).
> 
> 
> 
> d) In [10] there is a phrase about how-to disable busy waiting on yet another two MPI implementaions,
>> ... IBM MPI has the MP_WAIT_MODE and
>> the SUPER-UX MPI/XS library has MPISUSPEND to choose the waiting mode, 
>> either polling or sleeping.
> 
> Somebody with access to there MPIs could evaluate this, maybe.
> 
> Have a nice day,
> 
> Paul Kapinos
> 
> 
> 
> [1]
> https://www.paraview.org/Wiki/Setting_up_a_ParaView_Server#Server_processes_always_have_100.25_CPU_usage
> 
> [2]
> https://software.intel.com/sites/products/Whitepaper/Clustertools/amplxe_inspxe_interop_with_mpi.pdf
>   (cf. p.10)
> 
> [3]
> https://wiki.mpich.org/mpich/index.php/Frequently_Asked_Questions#Q:_Why_does_my_MPI_program_run_much_slower_when_I_use_more_processes.3F
> 
> [4] https://www.paraview.org/download/
> 
> [5] http://www.open-mpi.org/faq/?category=running#oversubscribing
> 
> [6] http://www.open-mpi.org/faq/?category=running#force-aggressive-degraded
> 
> [7] https://www.paraview.org/pipermail/paraview/2008-December/010349.html
> 
> [8] http://blogs.cisco.com/performance/polling-vs-blocking-message-passingprogress
> 
> [9] https://www.open-mpi.org/community/lists/users/2010/10/14505.php
> 
> [10] http://comp.parallel.mpi.narkive.com/3oXMDXno/non-busy-waiting-barrier-in-mpi
> 
> [11] http://blogs.cisco.com/performance/polling-vs-blocking-message-passingprogress
> 
> [12] https://stackoverflow.com/questions/14560714/probe-seems-to-consume-the-cpu
> 
> 


-- 
Dipl.-Inform. Paul Kapinos   -   High Performance Computing,
RWTH Aachen University, IT Center
Seffenter Weg 23,  D 52074  Aachen (Germany)
Tel: +49 241/80-24915

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4891 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171011/24de8861/attachment.bin>

From kmorel at sandia.gov  Wed Oct 11 12:39:41 2017
From: kmorel at sandia.gov (Moreland, Kenneth)
Date: Wed, 11 Oct 2017 16:39:41 +0000
Subject: [Paraview-developers] Define NDEBUG in VTK Submodule (WAS: 100%
	CPU usage once again)
Message-ID: <616bb3b3712048efbf3b4ffcb43989d7@ES08AMSNLNT.srn.sandia.gov>

That's weird. I thought CMake was supposed to automatically add the -DNDEBUG flag whenever you compile anything under Release mode.

At any rate, I'll hand that question off to Utkarsh or one of the ParaView team at Kitware. They would be better than me at answering build questions like this.

-Ken

-----Original Message-----
From: Paul Kapinos [mailto:kapinos at itc.rwth-aachen.de] 
Sent: Wednesday, October 11, 2017 10:19 AM
To: Moreland, Kenneth <kmorel at sandia.gov>; paraview-developers at paraview.org
Subject: [EXTERNAL] Re: [Paraview-developers] 100% CPU usage once again

Kenneth, thank you for your message and the update of the wiki!

Meanwhile I was able to reproduce the busy waiting with Open MPI (and other
MPIs) on a 10-line-example and asked the Open MPI developers about this:
https://www.mail-archive.com/devel at lists.open-mpi.org//msg20407.html

The spinning processes stuck at MPI_Barrier call in line 40 of
'ParaView-v5.4.1/VTK/Parallel/MPI/vtkMPICommunicator.cxx' file,
>     34 static inline void  vtkMPICommunicatorDebugBarrier(MPI_Comm* handle)
>     35 {
>     36   // If NDEBUG is defined, do nothing.
>     37 #ifdef NDEBUG
>     38   (void)handle; // to avoid warning about unused parameter
>     39 #else
>     40   MPI_Barrier(*handle);
>     41 #endif
>     42 }
It seem that ParaView's auto-build VTK version is build without NDEBUG define,
or with other words, *with* debug stuff.

Q: Is there a way to tell the ParaView's configure to set the VTK's define
'NDEBUG'? Or, more general, how-to tune VTK parameters? :o)

Have a nice day,

Paul Kapinos





On 10/09/2017 11:27 PM, Moreland, Kenneth wrote:
> Paul,
> 
> Thanks for the info. I updated the Wiki page with your information. Hopefully I captured everything.
> 
> I'll let someone from Kitware respond about the possibility of changing the binaries that are distributed.
> 
> -Ken
> 
> -----Original Message-----
> From: Paraview-developers [mailto:paraview-developers-bounces at paraview.org] On Behalf Of Paul Kapinos
> Sent: Monday, October 9, 2017 1:08 AM
> To: paraview-developers at paraview.org
> Subject: [EXTERNAL] [Paraview-developers] 100% CPU usage once again
> 
> (cross-post from 'paraview at paraview.org' 10/04/2017)
> 
> Dear ParaView developer,
> 
> in [1] you say
>> If you have information on disabling the busy wait using a different 
>> MPI implementation, please contribute back by documenting it here.
> 
> Here we go.
> 
> a)
> It is possible to build 'pvserver' using Intel MPI (and GCC compilers).
> By setting I_MPI_WAIT_MODE  environment variable to 'enable' value you can effectively prevent busy waiting, see [2] p.10 (Tested with Intel MPI 5.1(.3.181)).
> 
> Q/FR.1 Could you please provide a version of 'pvserver' build using Intel MPI in official release of ParaView? [4]
> 
> 
> 
> b)
> It is (obviously) possible to build 'pvserver' using MPICH (and GCC compilers).
> Itself, MPICH can be *configured* with '--with-device=ch3:sock' option. This is described to be 'slower' as '--with-device=ch3:nemesis'
> For our experiments it turned out, that 'pvserver' compiled and linked using MPICH with 'ch3:sock' configure option did not have the busy waiting aka 100%-CPU behaviour.
> Note that this is *configure-time of MPI library* parameter.
> 
> 
> (Tested with MPICH  3.2)
> 
> Q/FR.2 Could you please provide a version of 'pvserver' build using MPICH *configured with '--with-device=ch3:sock' option* in official release of ParaView? [4] This binary will be very likely be even compatible with 'standard' MPICH installations; we're able to start it even with IntelMPI's 'mpiexec' with success and no busy waiting. However YES you will need to have a MPICH release be build
> 
> 
> 
> 
> c)
> It is possible to build 'pvserver' using Open MPI (and GCC compilers).
> In [1] you document how-to 'turn off' the busy waiting behaviour in Open MPI (cf. [5],[6]).
> Unfortunately this *did not work* in our environment (InfiniBand QDR and Intel OmniPath clusters, OpenMPI 1.10.4).
> Note that likely we're not alone, cf. [7].
> Note that the switch likely just move the spinning location from MPI library itself to the fabrics library (cf. the screenshots, without 'mpi_yield_when_idle 1' (=default) the 'pvserver' processes spin with 'green' aka user 100%, and with 'mpi_yield_when_idle 1' the processes stays spinning but now with a lot of 'red'
> aka kernel time portion.
> 
> Conclusion: the way to disable busy waiting for Open MPI which is documented in [1], is not useful for us. We do not know this is a speciality of our site or a general issue; we think some survey at this point could be useful.
> 
> Q/FR.3 In case you should want to provide precompiled versions ov 'pvserver' for Open MPI, remember that there are ABI changes in major version changes. So you would likely need to compile+link *three* versions of 'pvserver' with Open MPI 1.10.x (still default in Linux), 2.x (current), 3.x (new).
> 
> 
> 
> d) In [10] there is a phrase about how-to disable busy waiting on yet another two MPI implementaions,
>> ... IBM MPI has the MP_WAIT_MODE and
>> the SUPER-UX MPI/XS library has MPISUSPEND to choose the waiting mode, 
>> either polling or sleeping.
> 
> Somebody with access to there MPIs could evaluate this, maybe.
> 
> Have a nice day,
> 
> Paul Kapinos
> 
> 
> 
> [1]
> https://www.paraview.org/Wiki/Setting_up_a_ParaView_Server#Server_processes_always_have_100.25_CPU_usage
> 
> [2]
> https://software.intel.com/sites/products/Whitepaper/Clustertools/amplxe_inspxe_interop_with_mpi.pdf
>   (cf. p.10)
> 
> [3]
> https://wiki.mpich.org/mpich/index.php/Frequently_Asked_Questions#Q:_Why_does_my_MPI_program_run_much_slower_when_I_use_more_processes.3F
> 
> [4] https://www.paraview.org/download/
> 
> [5] http://www.open-mpi.org/faq/?category=running#oversubscribing
> 
> [6] http://www.open-mpi.org/faq/?category=running#force-aggressive-degraded
> 
> [7] https://www.paraview.org/pipermail/paraview/2008-December/010349.html
> 
> [8] http://blogs.cisco.com/performance/polling-vs-blocking-message-passingprogress
> 
> [9] https://www.open-mpi.org/community/lists/users/2010/10/14505.php
> 
> [10] http://comp.parallel.mpi.narkive.com/3oXMDXno/non-busy-waiting-barrier-in-mpi
> 
> [11] http://blogs.cisco.com/performance/polling-vs-blocking-message-passingprogress
> 
> [12] https://stackoverflow.com/questions/14560714/probe-seems-to-consume-the-cpu
> 
> 


-- 
Dipl.-Inform. Paul Kapinos   -   High Performance Computing,
RWTH Aachen University, IT Center
Seffenter Weg 23,  D 52074  Aachen (Germany)
Tel: +49 241/80-24915


From kapinos at itc.rwth-aachen.de  Wed Oct 11 12:46:02 2017
From: kapinos at itc.rwth-aachen.de (Paul Kapinos)
Date: Wed, 11 Oct 2017 18:46:02 +0200
Subject: [Paraview-developers] Define NDEBUG in VTK Submodule (WAS: 100%
	CPU usage once again)
In-Reply-To: <616bb3b3712048efbf3b4ffcb43989d7@ES08AMSNLNT.srn.sandia.gov>
References: <616bb3b3712048efbf3b4ffcb43989d7@ES08AMSNLNT.srn.sandia.gov>
Message-ID: <9c7f28c3-0e00-f287-2218-130e11dd9931@itc.rwth-aachen.de>

We did an 'make VERBOSE=1' and what we see is for example (note the -DDEBUG flag!):
------------------------------------------------------------------------------
cd
/w0/tmp/pk224850/PARAVIEW_BUILD/5.4.1-gcc_4.8.5-intelmpi_5.1.3.181/VTK/ThirdParty/hdf5/vtkhdf5/hl/src
&& /usr/bin/gcc  -DDEBUG -DMPICH_IGNORE_CXX_SEEK -DVTK_IN_VTK -D_BSD_SOURCE
-D_DEFAULT_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_LARGEFILE64_SOURCE
-D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=199506L -Dhdf5_hl_EXPORTS
-I/w0/tmp/pk224850/PARAVIEW_BUILD/5.4.1-gcc_4.8.5-intelmpi_5.1.3.181
-I/w0/tmp/pk224850/PARAVIEW_BUILD/5.4.1-gcc_4.8.5-intelmpi_5.1.3.181/VTK/ThirdParty/hdf5/vtkhdf5
-I/w0/tmp/pk224850/PARAVIEW_BUILD/ParaView-v5.4.1/VTK/ThirdParty/hdf5/vtkhdf5/hl/src
-I/w0/tmp/pk224850/PARAVIEW_BUILD/ParaView-v5.4.1/VTK/ThirdParty/hdf5/vtkhdf5/src
-I/w0/tmp/pk224850/PARAVIEW_BUILD/5.4.1-gcc_4.8.5-intelmpi_5.1.3.181/VTK/ThirdParty/hdf5
-I/w0/tmp/pk224850/PARAVIEW_BUILD/ParaView-v5.4.1/VTK/ThirdParty/hdf5
-I/w0/tmp/pk224850/PARAVIEW_BUILD/5.4.1-gcc_4.8.5-intelmpi_5.1.3.181/VTK/ThirdParty/zlib
-I/w0/tmp/pk224850/PARAVIEW_BUILD/ParaView-v5.4.1/VTK/ThirdParty/zlib
-I/w0/tmp/pk224850/PARAVIEW_BUILD/5.4.1-gcc_4.8.5-intelmpi_5.1.3.181/bin
-I/w0/tmp/pk224850/PARAVIEW_BUILD/5.4.1-gcc_4.8.5-intelmpi_5.1.3.181/VTK/ThirdParty/hdf5/vtkhdf5/src
 -w -w -std=c99 -finline-functions -fno-common -w -Wextra -Wundef -Wshadow
-Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings
-Wconversion -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-declarations -Wredundant-decls -Wnested-externs -Winline
-fmessage-length=0 -g -fPIC   -Wall   -o CMakeFiles/vtkhdf5_hl.dir/H5DS.c.o   -c
/w0/tmp/pk224850/PARAVIEW_BUILD/ParaView-v5.4.1/VTK/ThirdParty/hdf5/vtkhdf5/hl/src/H5DS.c
------------------------------------------------------------------------------

Configure line was:
------------------------------------------------------------------------------
cmake  -DPARAVIEW_USE_MPI=ON           \
                     -DPARAVIEW_USE_VISITBRIDGE=ON               \
                         -DVISIT_BUILD_READER_CGNS=OFF          \
                         -DPARAVIEW_ENABLE_CGNS=OFF             \
                     -DPARAVIEW_BUILD_QT_GUI=OFF     \
                     -DVTK_USE_X=OFF                 \
   -DOPENGL_INCLUDE_DIR=IGNORE                       \
   -DOPENGL_xmesa_INCLUDE_DIR=IGNORE                            \
   -DOPENGL_gl_LIBRARY=IGNORE                        \
   -DOSMESA_INCLUDE_DIR=${INST}/include        \
   -DOSMESA_LIBRARY=${INST}/lib/libOSMesa.so   \
                     -DVTK_OPENGL_HAS_OSMESA=ON                 \
                     -DVTK_USE_OFFSCREEN=OFF                    \
                     -DCMAKE_INSTALL_PREFIX=${INST}     ../ParaView-v${VER}
${GCCB}  2>&1 | tee log.$START.01.cmake.txt
------------------------------------------------------------------------------




On 10/11/2017 06:39 PM, Moreland, Kenneth wrote:
> That's weird. I thought CMake was supposed to automatically add the -DNDEBUG flag whenever you compile anything under Release mode.
> 
> At any rate, I'll hand that question off to Utkarsh or one of the ParaView team at Kitware. They would be better than me at answering build questions like this.
> 
> -Ken
> 
> -----Original Message-----
> From: Paul Kapinos [mailto:kapinos at itc.rwth-aachen.de] 
> Sent: Wednesday, October 11, 2017 10:19 AM
> To: Moreland, Kenneth <kmorel at sandia.gov>; paraview-developers at paraview.org
> Subject: [EXTERNAL] Re: [Paraview-developers] 100% CPU usage once again
> 
> Kenneth, thank you for your message and the update of the wiki!
> 
> Meanwhile I was able to reproduce the busy waiting with Open MPI (and other
> MPIs) on a 10-line-example and asked the Open MPI developers about this:
> https://www.mail-archive.com/devel at lists.open-mpi.org//msg20407.html
> 
> The spinning processes stuck at MPI_Barrier call in line 40 of
> 'ParaView-v5.4.1/VTK/Parallel/MPI/vtkMPICommunicator.cxx' file,
>>     34 static inline void  vtkMPICommunicatorDebugBarrier(MPI_Comm* handle)
>>     35 {
>>     36   // If NDEBUG is defined, do nothing.
>>     37 #ifdef NDEBUG
>>     38   (void)handle; // to avoid warning about unused parameter
>>     39 #else
>>     40   MPI_Barrier(*handle);
>>     41 #endif
>>     42 }
> It seem that ParaView's auto-build VTK version is build without NDEBUG define,
> or with other words, *with* debug stuff.
> 
> Q: Is there a way to tell the ParaView's configure to set the VTK's define
> 'NDEBUG'? Or, more general, how-to tune VTK parameters? :o)
> 
> Have a nice day,
> 
> Paul Kapinos
> 
> 
> 
> 
> 
> On 10/09/2017 11:27 PM, Moreland, Kenneth wrote:
>> Paul,
>>
>> Thanks for the info. I updated the Wiki page with your information. Hopefully I captured everything.
>>
>> I'll let someone from Kitware respond about the possibility of changing the binaries that are distributed.
>>
>> -Ken
>>
>> -----Original Message-----
>> From: Paraview-developers [mailto:paraview-developers-bounces at paraview.org] On Behalf Of Paul Kapinos
>> Sent: Monday, October 9, 2017 1:08 AM
>> To: paraview-developers at paraview.org
>> Subject: [EXTERNAL] [Paraview-developers] 100% CPU usage once again
>>
>> (cross-post from 'paraview at paraview.org' 10/04/2017)
>>
>> Dear ParaView developer,
>>
>> in [1] you say
>>> If you have information on disabling the busy wait using a different 
>>> MPI implementation, please contribute back by documenting it here.
>>
>> Here we go.
>>
>> a)
>> It is possible to build 'pvserver' using Intel MPI (and GCC compilers).
>> By setting I_MPI_WAIT_MODE  environment variable to 'enable' value you can effectively prevent busy waiting, see [2] p.10 (Tested with Intel MPI 5.1(.3.181)).
>>
>> Q/FR.1 Could you please provide a version of 'pvserver' build using Intel MPI in official release of ParaView? [4]
>>
>>
>>
>> b)
>> It is (obviously) possible to build 'pvserver' using MPICH (and GCC compilers).
>> Itself, MPICH can be *configured* with '--with-device=ch3:sock' option. This is described to be 'slower' as '--with-device=ch3:nemesis'
>> For our experiments it turned out, that 'pvserver' compiled and linked using MPICH with 'ch3:sock' configure option did not have the busy waiting aka 100%-CPU behaviour.
>> Note that this is *configure-time of MPI library* parameter.
>>
>>
>> (Tested with MPICH  3.2)
>>
>> Q/FR.2 Could you please provide a version of 'pvserver' build using MPICH *configured with '--with-device=ch3:sock' option* in official release of ParaView? [4] This binary will be very likely be even compatible with 'standard' MPICH installations; we're able to start it even with IntelMPI's 'mpiexec' with success and no busy waiting. However YES you will need to have a MPICH release be build
>>
>>
>>
>>
>> c)
>> It is possible to build 'pvserver' using Open MPI (and GCC compilers).
>> In [1] you document how-to 'turn off' the busy waiting behaviour in Open MPI (cf. [5],[6]).
>> Unfortunately this *did not work* in our environment (InfiniBand QDR and Intel OmniPath clusters, OpenMPI 1.10.4).
>> Note that likely we're not alone, cf. [7].
>> Note that the switch likely just move the spinning location from MPI library itself to the fabrics library (cf. the screenshots, without 'mpi_yield_when_idle 1' (=default) the 'pvserver' processes spin with 'green' aka user 100%, and with 'mpi_yield_when_idle 1' the processes stays spinning but now with a lot of 'red'
>> aka kernel time portion.
>>
>> Conclusion: the way to disable busy waiting for Open MPI which is documented in [1], is not useful for us. We do not know this is a speciality of our site or a general issue; we think some survey at this point could be useful.
>>
>> Q/FR.3 In case you should want to provide precompiled versions ov 'pvserver' for Open MPI, remember that there are ABI changes in major version changes. So you would likely need to compile+link *three* versions of 'pvserver' with Open MPI 1.10.x (still default in Linux), 2.x (current), 3.x (new).
>>
>>
>>
>> d) In [10] there is a phrase about how-to disable busy waiting on yet another two MPI implementaions,
>>> ... IBM MPI has the MP_WAIT_MODE and
>>> the SUPER-UX MPI/XS library has MPISUSPEND to choose the waiting mode, 
>>> either polling or sleeping.
>>
>> Somebody with access to there MPIs could evaluate this, maybe.
>>
>> Have a nice day,
>>
>> Paul Kapinos
>>
>>
>>
>> [1]
>> https://www.paraview.org/Wiki/Setting_up_a_ParaView_Server#Server_processes_always_have_100.25_CPU_usage
>>
>> [2]
>> https://software.intel.com/sites/products/Whitepaper/Clustertools/amplxe_inspxe_interop_with_mpi.pdf
>>   (cf. p.10)
>>
>> [3]
>> https://wiki.mpich.org/mpich/index.php/Frequently_Asked_Questions#Q:_Why_does_my_MPI_program_run_much_slower_when_I_use_more_processes.3F
>>
>> [4] https://www.paraview.org/download/
>>
>> [5] http://www.open-mpi.org/faq/?category=running#oversubscribing
>>
>> [6] http://www.open-mpi.org/faq/?category=running#force-aggressive-degraded
>>
>> [7] https://www.paraview.org/pipermail/paraview/2008-December/010349.html
>>
>> [8] http://blogs.cisco.com/performance/polling-vs-blocking-message-passingprogress
>>
>> [9] https://www.open-mpi.org/community/lists/users/2010/10/14505.php
>>
>> [10] http://comp.parallel.mpi.narkive.com/3oXMDXno/non-busy-waiting-barrier-in-mpi
>>
>> [11] http://blogs.cisco.com/performance/polling-vs-blocking-message-passingprogress
>>
>> [12] https://stackoverflow.com/questions/14560714/probe-seems-to-consume-the-cpu
>>
>>
> 
> 


-- 
Dipl.-Inform. Paul Kapinos   -   High Performance Computing,
RWTH Aachen University, IT Center
Seffenter Weg 23,  D 52074  Aachen (Germany)
Tel: +49 241/80-24915

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4891 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171011/2df03428/attachment-0001.bin>

From kmorel at sandia.gov  Wed Oct 11 12:48:38 2017
From: kmorel at sandia.gov (Moreland, Kenneth)
Date: Wed, 11 Oct 2017 16:48:38 +0000
Subject: [Paraview-developers] Define NDEBUG in VTK Submodule (WAS: 100%
	CPU usage once again)
Message-ID: <89a4a97c938b4c75ad7436fc1ff26ec3@ES08AMSNLNT.srn.sandia.gov>

What happens if you add -DCMAKE_BUILD_TYPE=Release to the cmake flags in your configure line?

-Ken

-----Original Message-----
From: Paul Kapinos [mailto:kapinos at itc.rwth-aachen.de] 
Sent: Wednesday, October 11, 2017 10:46 AM
To: Moreland, Kenneth <kmorel at sandia.gov>; paraview-developers at paraview.org; Ayachit, Utkarsh (External Contacts) <utkarsh.ayachit at kitware.com>
Subject: [EXTERNAL] Re: Define NDEBUG in VTK Submodule (WAS: 100% CPU usage once again)

We did an 'make VERBOSE=1' and what we see is for example (note the -DDEBUG flag!):
------------------------------------------------------------------------------
cd
/w0/tmp/pk224850/PARAVIEW_BUILD/5.4.1-gcc_4.8.5-intelmpi_5.1.3.181/VTK/ThirdParty/hdf5/vtkhdf5/hl/src
&& /usr/bin/gcc  -DDEBUG -DMPICH_IGNORE_CXX_SEEK -DVTK_IN_VTK -D_BSD_SOURCE
-D_DEFAULT_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_LARGEFILE64_SOURCE
-D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=199506L -Dhdf5_hl_EXPORTS
-I/w0/tmp/pk224850/PARAVIEW_BUILD/5.4.1-gcc_4.8.5-intelmpi_5.1.3.181
-I/w0/tmp/pk224850/PARAVIEW_BUILD/5.4.1-gcc_4.8.5-intelmpi_5.1.3.181/VTK/ThirdParty/hdf5/vtkhdf5
-I/w0/tmp/pk224850/PARAVIEW_BUILD/ParaView-v5.4.1/VTK/ThirdParty/hdf5/vtkhdf5/hl/src
-I/w0/tmp/pk224850/PARAVIEW_BUILD/ParaView-v5.4.1/VTK/ThirdParty/hdf5/vtkhdf5/src
-I/w0/tmp/pk224850/PARAVIEW_BUILD/5.4.1-gcc_4.8.5-intelmpi_5.1.3.181/VTK/ThirdParty/hdf5
-I/w0/tmp/pk224850/PARAVIEW_BUILD/ParaView-v5.4.1/VTK/ThirdParty/hdf5
-I/w0/tmp/pk224850/PARAVIEW_BUILD/5.4.1-gcc_4.8.5-intelmpi_5.1.3.181/VTK/ThirdParty/zlib
-I/w0/tmp/pk224850/PARAVIEW_BUILD/ParaView-v5.4.1/VTK/ThirdParty/zlib
-I/w0/tmp/pk224850/PARAVIEW_BUILD/5.4.1-gcc_4.8.5-intelmpi_5.1.3.181/bin
-I/w0/tmp/pk224850/PARAVIEW_BUILD/5.4.1-gcc_4.8.5-intelmpi_5.1.3.181/VTK/ThirdParty/hdf5/vtkhdf5/src
 -w -w -std=c99 -finline-functions -fno-common -w -Wextra -Wundef -Wshadow
-Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings
-Wconversion -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-declarations -Wredundant-decls -Wnested-externs -Winline
-fmessage-length=0 -g -fPIC   -Wall   -o CMakeFiles/vtkhdf5_hl.dir/H5DS.c.o   -c
/w0/tmp/pk224850/PARAVIEW_BUILD/ParaView-v5.4.1/VTK/ThirdParty/hdf5/vtkhdf5/hl/src/H5DS.c
------------------------------------------------------------------------------

Configure line was:
------------------------------------------------------------------------------
cmake  -DPARAVIEW_USE_MPI=ON           \
                     -DPARAVIEW_USE_VISITBRIDGE=ON               \
                         -DVISIT_BUILD_READER_CGNS=OFF          \
                         -DPARAVIEW_ENABLE_CGNS=OFF             \
                     -DPARAVIEW_BUILD_QT_GUI=OFF     \
                     -DVTK_USE_X=OFF                 \
   -DOPENGL_INCLUDE_DIR=IGNORE                       \
   -DOPENGL_xmesa_INCLUDE_DIR=IGNORE                            \
   -DOPENGL_gl_LIBRARY=IGNORE                        \
   -DOSMESA_INCLUDE_DIR=${INST}/include        \
   -DOSMESA_LIBRARY=${INST}/lib/libOSMesa.so   \
                     -DVTK_OPENGL_HAS_OSMESA=ON                 \
                     -DVTK_USE_OFFSCREEN=OFF                    \
                     -DCMAKE_INSTALL_PREFIX=${INST}     ../ParaView-v${VER}
${GCCB}  2>&1 | tee log.$START.01.cmake.txt
------------------------------------------------------------------------------




On 10/11/2017 06:39 PM, Moreland, Kenneth wrote:
> That's weird. I thought CMake was supposed to automatically add the -DNDEBUG flag whenever you compile anything under Release mode.
> 
> At any rate, I'll hand that question off to Utkarsh or one of the ParaView team at Kitware. They would be better than me at answering build questions like this.
> 
> -Ken
> 
> -----Original Message-----
> From: Paul Kapinos [mailto:kapinos at itc.rwth-aachen.de] 
> Sent: Wednesday, October 11, 2017 10:19 AM
> To: Moreland, Kenneth <kmorel at sandia.gov>; paraview-developers at paraview.org
> Subject: [EXTERNAL] Re: [Paraview-developers] 100% CPU usage once again
> 
> Kenneth, thank you for your message and the update of the wiki!
> 
> Meanwhile I was able to reproduce the busy waiting with Open MPI (and other
> MPIs) on a 10-line-example and asked the Open MPI developers about this:
> https://www.mail-archive.com/devel at lists.open-mpi.org//msg20407.html
> 
> The spinning processes stuck at MPI_Barrier call in line 40 of
> 'ParaView-v5.4.1/VTK/Parallel/MPI/vtkMPICommunicator.cxx' file,
>>     34 static inline void  vtkMPICommunicatorDebugBarrier(MPI_Comm* handle)
>>     35 {
>>     36   // If NDEBUG is defined, do nothing.
>>     37 #ifdef NDEBUG
>>     38   (void)handle; // to avoid warning about unused parameter
>>     39 #else
>>     40   MPI_Barrier(*handle);
>>     41 #endif
>>     42 }
> It seem that ParaView's auto-build VTK version is build without NDEBUG define,
> or with other words, *with* debug stuff.
> 
> Q: Is there a way to tell the ParaView's configure to set the VTK's define
> 'NDEBUG'? Or, more general, how-to tune VTK parameters? :o)
> 
> Have a nice day,
> 
> Paul Kapinos
> 
> 
> 
> 
> 
> On 10/09/2017 11:27 PM, Moreland, Kenneth wrote:
>> Paul,
>>
>> Thanks for the info. I updated the Wiki page with your information. Hopefully I captured everything.
>>
>> I'll let someone from Kitware respond about the possibility of changing the binaries that are distributed.
>>
>> -Ken
>>
>> -----Original Message-----
>> From: Paraview-developers [mailto:paraview-developers-bounces at paraview.org] On Behalf Of Paul Kapinos
>> Sent: Monday, October 9, 2017 1:08 AM
>> To: paraview-developers at paraview.org
>> Subject: [EXTERNAL] [Paraview-developers] 100% CPU usage once again
>>
>> (cross-post from 'paraview at paraview.org' 10/04/2017)
>>
>> Dear ParaView developer,
>>
>> in [1] you say
>>> If you have information on disabling the busy wait using a different 
>>> MPI implementation, please contribute back by documenting it here.
>>
>> Here we go.
>>
>> a)
>> It is possible to build 'pvserver' using Intel MPI (and GCC compilers).
>> By setting I_MPI_WAIT_MODE  environment variable to 'enable' value you can effectively prevent busy waiting, see [2] p.10 (Tested with Intel MPI 5.1(.3.181)).
>>
>> Q/FR.1 Could you please provide a version of 'pvserver' build using Intel MPI in official release of ParaView? [4]
>>
>>
>>
>> b)
>> It is (obviously) possible to build 'pvserver' using MPICH (and GCC compilers).
>> Itself, MPICH can be *configured* with '--with-device=ch3:sock' option. This is described to be 'slower' as '--with-device=ch3:nemesis'
>> For our experiments it turned out, that 'pvserver' compiled and linked using MPICH with 'ch3:sock' configure option did not have the busy waiting aka 100%-CPU behaviour.
>> Note that this is *configure-time of MPI library* parameter.
>>
>>
>> (Tested with MPICH  3.2)
>>
>> Q/FR.2 Could you please provide a version of 'pvserver' build using MPICH *configured with '--with-device=ch3:sock' option* in official release of ParaView? [4] This binary will be very likely be even compatible with 'standard' MPICH installations; we're able to start it even with IntelMPI's 'mpiexec' with success and no busy waiting. However YES you will need to have a MPICH release be build
>>
>>
>>
>>
>> c)
>> It is possible to build 'pvserver' using Open MPI (and GCC compilers).
>> In [1] you document how-to 'turn off' the busy waiting behaviour in Open MPI (cf. [5],[6]).
>> Unfortunately this *did not work* in our environment (InfiniBand QDR and Intel OmniPath clusters, OpenMPI 1.10.4).
>> Note that likely we're not alone, cf. [7].
>> Note that the switch likely just move the spinning location from MPI library itself to the fabrics library (cf. the screenshots, without 'mpi_yield_when_idle 1' (=default) the 'pvserver' processes spin with 'green' aka user 100%, and with 'mpi_yield_when_idle 1' the processes stays spinning but now with a lot of 'red'
>> aka kernel time portion.
>>
>> Conclusion: the way to disable busy waiting for Open MPI which is documented in [1], is not useful for us. We do not know this is a speciality of our site or a general issue; we think some survey at this point could be useful.
>>
>> Q/FR.3 In case you should want to provide precompiled versions ov 'pvserver' for Open MPI, remember that there are ABI changes in major version changes. So you would likely need to compile+link *three* versions of 'pvserver' with Open MPI 1.10.x (still default in Linux), 2.x (current), 3.x (new).
>>
>>
>>
>> d) In [10] there is a phrase about how-to disable busy waiting on yet another two MPI implementaions,
>>> ... IBM MPI has the MP_WAIT_MODE and
>>> the SUPER-UX MPI/XS library has MPISUSPEND to choose the waiting mode, 
>>> either polling or sleeping.
>>
>> Somebody with access to there MPIs could evaluate this, maybe.
>>
>> Have a nice day,
>>
>> Paul Kapinos
>>
>>
>>
>> [1]
>> https://www.paraview.org/Wiki/Setting_up_a_ParaView_Server#Server_processes_always_have_100.25_CPU_usage
>>
>> [2]
>> https://software.intel.com/sites/products/Whitepaper/Clustertools/amplxe_inspxe_interop_with_mpi.pdf
>>   (cf. p.10)
>>
>> [3]
>> https://wiki.mpich.org/mpich/index.php/Frequently_Asked_Questions#Q:_Why_does_my_MPI_program_run_much_slower_when_I_use_more_processes.3F
>>
>> [4] https://www.paraview.org/download/
>>
>> [5] http://www.open-mpi.org/faq/?category=running#oversubscribing
>>
>> [6] http://www.open-mpi.org/faq/?category=running#force-aggressive-degraded
>>
>> [7] https://www.paraview.org/pipermail/paraview/2008-December/010349.html
>>
>> [8] http://blogs.cisco.com/performance/polling-vs-blocking-message-passingprogress
>>
>> [9] https://www.open-mpi.org/community/lists/users/2010/10/14505.php
>>
>> [10] http://comp.parallel.mpi.narkive.com/3oXMDXno/non-busy-waiting-barrier-in-mpi
>>
>> [11] http://blogs.cisco.com/performance/polling-vs-blocking-message-passingprogress
>>
>> [12] https://stackoverflow.com/questions/14560714/probe-seems-to-consume-the-cpu
>>
>>
> 
> 


-- 
Dipl.-Inform. Paul Kapinos   -   High Performance Computing,
RWTH Aachen University, IT Center
Seffenter Weg 23,  D 52074  Aachen (Germany)
Tel: +49 241/80-24915


From ben.boeckel at kitware.com  Wed Oct 11 13:20:42 2017
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Wed, 11 Oct 2017 13:20:42 -0400
Subject: [Paraview-developers] 100% CPU usage once again
In-Reply-To: <babee0ee-2c10-8a41-2843-834aa4294963@itc.rwth-aachen.de>
References: <91a3cc1114784287a3842eb6b899256e@ES08AMSNLNT.srn.sandia.gov>
 <babee0ee-2c10-8a41-2843-834aa4294963@itc.rwth-aachen.de>
Message-ID: <20171011172041.GA6383@megas.kitware.com>

On Wed, Oct 11, 2017 at 18:18:57 +0200, Paul Kapinos wrote:
> The spinning processes stuck at MPI_Barrier call in line 40 of
> 'ParaView-v5.4.1/VTK/Parallel/MPI/vtkMPICommunicator.cxx' file,
> >     34 static inline void  vtkMPICommunicatorDebugBarrier(MPI_Comm* handle)
> >     35 {
> >     36   // If NDEBUG is defined, do nothing.
> >     37 #ifdef NDEBUG
> >     38   (void)handle; // to avoid warning about unused parameter
> >     39 #else
> >     40   MPI_Barrier(*handle);
> >     41 #endif
> >     42 }
> It seem that ParaView's auto-build VTK version is build without NDEBUG define,
> or with other words, *with* debug stuff.
> 
> Q: Is there a way to tell the ParaView's configure to set the VTK's define
> 'NDEBUG'? Or, more general, how-to tune VTK parameters? :o)

Hmm, Release builds should have `-DNDEBUG`. We have it set to use
Release for our binaries at least.

On the MPICH front, I have MRs here to add the configure option to the
MPICH we ship in binaries:

    https://gitlab.kitware.com/paraview/paraview-superbuild/merge_requests/375
    https://gitlab.kitware.com/paraview/common-superbuild/merge_requests/191

I'm waiting for the dashboards to settle down so I can get a package
from it for testing.

--Ben

From ben.boeckel at kitware.com  Wed Oct 11 13:23:58 2017
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Wed, 11 Oct 2017 13:23:58 -0400
Subject: [Paraview-developers] Define NDEBUG in VTK Submodule (WAS: 100%
 CPU usage once again)
In-Reply-To: <9c7f28c3-0e00-f287-2218-130e11dd9931@itc.rwth-aachen.de>
References: <616bb3b3712048efbf3b4ffcb43989d7@ES08AMSNLNT.srn.sandia.gov>
 <9c7f28c3-0e00-f287-2218-130e11dd9931@itc.rwth-aachen.de>
Message-ID: <20171011172358.GB6383@megas.kitware.com>

On Wed, Oct 11, 2017 at 18:46:02 +0200, Paul Kapinos wrote:
> We did an 'make VERBOSE=1' and what we see is for example (note the -DDEBUG flag!):

This is likely due to:

    https://gitlab.kitware.com/vtk/vtk/blob/master/ThirdParty/hdf5/vtkhdf5/CMakeLists.txt#L381

> Configure line was:
> ------------------------------------------------------------------------------
> cmake  -DPARAVIEW_USE_MPI=ON           \
>                      -DPARAVIEW_USE_VISITBRIDGE=ON               \
>                          -DVISIT_BUILD_READER_CGNS=OFF          \
>                          -DPARAVIEW_ENABLE_CGNS=OFF             \
>                      -DPARAVIEW_BUILD_QT_GUI=OFF     \
>                      -DVTK_USE_X=OFF                 \
>    -DOPENGL_INCLUDE_DIR=IGNORE                       \
>    -DOPENGL_xmesa_INCLUDE_DIR=IGNORE                            \
>    -DOPENGL_gl_LIBRARY=IGNORE                        \
>    -DOSMESA_INCLUDE_DIR=${INST}/include        \
>    -DOSMESA_LIBRARY=${INST}/lib/libOSMesa.so   \
>                      -DVTK_OPENGL_HAS_OSMESA=ON                 \
>                      -DVTK_USE_OFFSCREEN=OFF                    \
>                      -DCMAKE_INSTALL_PREFIX=${INST}     ../ParaView-v${VER}

Without any build type given, CMake usually defaults to the empty
configuration which basically amounts to Debug. I forget if VTK/ParaView
reset it if it is empty. It seems they do if that conditional is firing.

--Ben

From wascott at sandia.gov  Wed Oct 11 14:24:33 2017
From: wascott at sandia.gov (Scott, W Alan)
Date: Wed, 11 Oct 2017 18:24:33 +0000
Subject: [Paraview-developers] Lights
Message-ID: <661aba084f2e4f1fb43d78e8b26aaad8@ES01AMSNLNT.srn.sandia.gov>

Dave Karelitz was showing me the can in ParaView, and I wonder if our lights model is incorrect.  Here is how to replicate:


  *   Open can.exo.  Apply.  Last frame.  Color by Solid Color.  Reset.
  *   Now, rotate the can.

What you will notice is that the lights are not attached to the scene (i.e., stationary), but attached to the camera (i.e., moving).  This is really obvious if you turn on OSPRay and shadows.

Isn't this wrong?  The data should remain stationary, the lights (other than a headlight) should stay stationary, and the camera should move around the scene?

Alan

--------------------------------------------------------
W. Alan Scott
ParaView Support Manager

SAIC
Sandia National Laboratories, MS 0807
Org 9326 - Building 880 A1-K
(505) 284-0932   FAX (505) 284-5619

The most exciting phrase to hear in science
is not "Eureka!" but "That's funny..."  -- Isaac Asimov
---------------------------------------------------------

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

From dave.demarle at kitware.com  Wed Oct 11 14:36:14 2017
From: dave.demarle at kitware.com (David E DeMarle)
Date: Wed, 11 Oct 2017 14:36:14 -0400
Subject: [Paraview-developers] Lights
In-Reply-To: <661aba084f2e4f1fb43d78e8b26aaad8@ES01AMSNLNT.srn.sandia.gov>
References: <661aba084f2e4f1fb43d78e8b26aaad8@ES01AMSNLNT.srn.sandia.gov>
Message-ID: <CANjZAi_CVbgy9cB8YJDQa+krqGCSC1=dcPn-wYJONcFHL6Zqwg@mail.gmail.com>

I don't think so. ParaView uses vtkLightKit, for which all 5 of the lights
are camera relative, ie they are placed to illuminate the scene from
various directions but move with the camera.
It is "about right" for most things and has served us well for many years.

With the new light inspector panel you will find in master you can insert
scene (or other) lights if you have a need to do so and finely control them
as well.

David E DeMarle
Kitware, Inc.
Principal Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909 <(518)%20881-4909>

On Wed, Oct 11, 2017 at 2:24 PM, Scott, W Alan <wascott at sandia.gov> wrote:

> Dave Karelitz was showing me the can in ParaView, and I wonder if our
> lights model is incorrect.  Here is how to replicate:
>
>
>
>    - Open can.exo.  Apply.  Last frame.  Color by Solid Color.  Reset.
>    - Now, rotate the can.
>
>
>
> What you will notice is that the lights are not attached to the scene
> (i.e., stationary), but attached to the camera (i.e., moving).  This is
> really obvious if you turn on OSPRay and shadows.
>
>
>
> Isn?t this wrong?  The data should remain stationary, the lights (other
> than a headlight) should stay stationary, and the camera should move around
> the scene?
>
>
>
> Alan
>
>
>
> --------------------------------------------------------
>
> W. Alan Scott
>
> ParaView Support Manager
>
>
>
> SAIC
>
> Sandia National Laboratories, MS 0807
>
> Org 9326 - Building 880 A1-K
>
> (505) 284-0932   FAX (505) 284-5619
>
>
>
> The most exciting phrase to hear in science
>
> is not "Eureka!" but "That's funny..."  -- Isaac Asimov
>
> ---------------------------------------------------------
>
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensou
> rce/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/20171011/49e33d47/attachment.html>

From paul.melis at surfsara.nl  Thu Oct 12 09:07:01 2017
From: paul.melis at surfsara.nl (Paul Melis)
Date: Thu, 12 Oct 2017 15:07:01 +0200
Subject: [Paraview-developers] xdisplay-test + display=1 => segfault
In-Reply-To: <CADHSJjDf+pVHPRrYfWBp3RnpETZ4WVKchrqvzkhk57L3_sXBFQ@mail.gmail.com>
References: <1DB406F67241344CB6F3A199E54EF09D125F1AD2@MBX2010-E01.ad.fz-juelich.de>
 <CADHSJjDcE67TbGVXKP++mON3Ay5Ao7-fTVpNA9W8sLO2f2i=eg@mail.gmail.com>
 <1DB406F67241344CB6F3A199E54EF09D125F1C7D@MBX2010-E01.ad.fz-juelich.de>
 <CADHSJjAyLPqg6998rdi0z4BbuH-_bXS+LNP-C632nnkHGpjeXg@mail.gmail.com>
 <1DB406F67241344CB6F3A199E54EF09D125F1DD4@MBX2010-E01.ad.fz-juelich.de>
 <CADHSJjCu+x1c-oskjPW3crCRkPAZHQfQ3eN4STEjPSXnBhqV0A@mail.gmail.com>
 <CADHSJjDf+pVHPRrYfWBp3RnpETZ4WVKchrqvzkhk57L3_sXBFQ@mail.gmail.com>
Message-ID: <20853cb9-1f87-0673-2bf5-2e9ac72595ee@surfsara.nl>

Hi Utkarsh,

On 15-05-17 16:05, Utkarsh Ayachit wrote:
> It seems that the workaround for this for now is to have users start 
> their X servers with the ?-noreset? option.  Alternatively, you could 
> use EGL enabled server executables and this will be totally overcome.

Sorry for hijacking the thread, but I'm wondering if the issue I'm 
seeing is caused by the same nvidia driver bug and can be worked around 
with the -noreset option here.

When running pvserver --use-offscreen-rendering (with the official 5.4.1 
linux binaries on RHEL7) and connecting remotely with the client (again 
official linux bins) I get a segfault in the PV server, as well as in 
the X server. The message indicates an issue with the version of the 
OpenGL context, but NVidia OpenGL is available and new enough (375.26) 
for OpenGL 3.2. The X crash also strongly suggests something NVidia 
related. See below for more info.

The EGL-based server option sounds very interesting, but do you think 
that for now using -noreset might solve the issue below as well?

Regards,
Paul



[paulm at gcn64 bin]$ DISPLAY=:0.0 ./pvserver --use-offscreen-rendering
Waiting for client...
Connection URL: cs://gcn64.bullx:11111
Accepting connection(s): gcn64.bullx:11111
Client connected.
Warning: In 
/home/buildslave/dashboards/buildbot/paraview-pvbinsdash-linux-shared-release_superbuild/build/superbuild/paraview/src/VTK/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx, 
line 838
vtkXOpenGLRenderWindow (0x1e1fe30): VTK is designed to work with OpenGL 
version 3.2 but it appears it has been given a context that does not 
support 3.2. VTK will run in a compatibility mode designed to work with 
earlier versions of OpenGL but some features may not work.

Segmentation fault (core dumped)

-----------------------------------------------------------------------

[2629129.832] (II) config/udev: Adding input device PC Speaker 
(/dev/input/event3)
[2629129.832] (II) No input driver specified, ignoring this device.
[2629129.832] (II) This device may have been added with another device file.
[2629130.998] (EE)
[2629130.998] (EE) Backtrace:
[2629130.998] (EE) 0: /usr/bin/X (xorg_backtrace+0x55) [0x2b6390bf79a5]
[2629130.998] (EE) 1: /usr/bin/X (0x2b6390a45000+0x1b6cb9) [0x2b6390bfbcb9]
[2629130.998] (EE) 2: /usr/lib64/libc.so.6 (0x2b6393110000+0x35250) 
[0x2b6393145250]
[2629130.998] (EE) 3: /usr/lib64/libnvidia-glcore.so.375.26 
(0x2b63969f5000+0xded56f) [0x2b63977e256f]
[2629130.998] (EE) 4: /usr/lib64/libnvidia-glcore.so.375.26 
(0x2b63969f5000+0x315edf) [0x2b6396d0aedf]
[2629130.998] (EE) 5: /usr/lib64/libnvidia-glcore.so.375.26 
(0x2b63969f5000+0xe3a715) [0x2b639782f715]
[2629130.998] (EE) 6: /usr/lib64/libnvidia-glcore.so.375.26 
(0x2b63969f5000+0xca4499) [0x2b6397699499]
[2629130.998] (EE) 7: /usr/lib64/libnvidia-glcore.so.375.26 
(0x2b63969f5000+0x104654d) [0x2b6397a3b54d]
[2629130.998] (EE) 8: /usr/lib64/libnvidia-glcore.so.375.26 
(0x2b63969f5000+0x101e68d) [0x2b6397a1368d]
[2629130.998] (EE) 9: /usr/lib64/xorg/modules/extensions/libglx.so 
(0x2b6395975000+0x812f27) [0x2b6396187f27]
[2629130.998] (EE)
[2629130.998] (EE) Segmentation fault at address 0x48
[2629130.998] (EE)
Fatal server error:
[2629130.998] (EE) Caught signal 11 (Segmentation fault). Server aborting
[2629130.998] (EE)
[2629130.998] (EE)
Please consult the The X.Org Foundation support
          at http://wiki.x.org
  for help.
[2629130.998] (EE) Please also check the log file at 
"/var/log/Xorg.0.log" for additional information.
[2629130.998] (EE)
[2629131.095] (EE)name of display: :0.0

  Server terminated with error (1). Closing log file.

-----------------------------------------------------------------------

display: :0  screen: 0
direct rendering: Yes
server glx vendor string: NVIDIA Corporation
server glx version string: 1.4
server glx extensions:
     GLX_ARB_context_flush_control, GLX_ARB_create_context,
     GLX_ARB_create_context_profile, GLX_ARB_create_context_robustness,
     GLX_ARB_fbconfig_float, GLX_ARB_multisample, GLX_EXT_buffer_age,
     GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile,
     GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, GLX_EXT_libglvnd,
     GLX_EXT_stereo_tree, GLX_EXT_swap_control, GLX_EXT_swap_control_tear,
     GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, 
GLX_EXT_visual_rating,
     GLX_NV_copy_image, GLX_NV_delay_before_swap, GLX_NV_float_buffer,
     GLX_NV_multisample_coverage, GLX_NV_robustness_video_memory_purge,
     GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_swap_control,
     GLX_SGI_video_sync
client glx vendor string: NVIDIA Corporation
client glx version string: 1.4
client glx extensions:
     GLX_ARB_context_flush_control, GLX_ARB_create_context,
     GLX_ARB_create_context_profile, GLX_ARB_create_context_robustness,
     GLX_ARB_fbconfig_float, GLX_ARB_get_proc_address, GLX_ARB_multisample,
     GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile,
     GLX_EXT_create_context_es_profile, GLX_EXT_fbconfig_packed_float,
     GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, GLX_EXT_stereo_tree,
     GLX_EXT_swap_control, GLX_EXT_swap_control_tear,
     GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, 
GLX_EXT_visual_rating,
     GLX_NV_copy_buffer, GLX_NV_copy_image, GLX_NV_delay_before_swap,
     GLX_NV_float_buffer, GLX_NV_multisample_coverage, 
GLX_NV_present_video,
     GLX_NV_robustness_video_memory_purge, GLX_NV_swap_group,
     GLX_NV_video_capture, GLX_NV_video_out, GLX_SGIX_fbconfig,
     GLX_SGIX_pbuffer, GLX_SGI_swap_control, GLX_SGI_video_sync
GLX version: 1.4
GLX extensions:
     GLX_ARB_context_flush_control, GLX_ARB_create_context,
     GLX_ARB_create_context_profile, GLX_ARB_create_context_robustness,
     GLX_ARB_fbconfig_float, GLX_ARB_get_proc_address, GLX_ARB_multisample,
     GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile,
     GLX_EXT_create_context_es_profile, GLX_EXT_framebuffer_sRGB,
     GLX_EXT_import_context, GLX_EXT_stereo_tree, GLX_EXT_swap_control,
     GLX_EXT_swap_control_tear, GLX_EXT_texture_from_pixmap,
     GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_NV_copy_image,
     GLX_NV_delay_before_swap, GLX_NV_float_buffer,
     GLX_NV_multisample_coverage, GLX_NV_robustness_video_memory_purge,
     GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_swap_control,
     GLX_SGI_video_sync
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: Tesla K40m/PCIe/SSE2
OpenGL core profile version string: 4.3.0 NVIDIA 375.26
OpenGL core profile shading language version string: 4.30 NVIDIA via Cg 
compiler





-- 

Paul Melis
| Visualization group leader & developer | SURFsara |
| Science Park 140 | 1098 XG Amsterdam |
| T 020 800 1312 | paul.melis at surfsara.nl | www.surfsara.nl |

From cory.quammen at kitware.com  Thu Oct 12 09:44:48 2017
From: cory.quammen at kitware.com (Cory Quammen)
Date: Thu, 12 Oct 2017 09:44:48 -0400
Subject: [Paraview-developers] Dashboard whoas
In-Reply-To: <CADHSJjCYx82cgBZ3wbuT_t-2kTL8VN1dXUbkunW5dRh8jzJPew@mail.gmail.com>
References: <CAB5Fpx43O1QP9bQLDmvWrEPvEC8SEgF1fdgjWJu-teA4tHkaMg@mail.gmail.com>
 <CAB5Fpx4Fw+hdt7FYBst+r3-dpV2_P5sW7fCCxuKn9hPvn3YU4A@mail.gmail.com>
 <CAMaOp+HAye+dtYm1t4DxsN2+hkSWmqmDwrfabAxrw8LCpcf4jg@mail.gmail.com>
 <CADHSJjCJnTjxUa1rL79N1kLX24LrMK5BKxxeRWbCzxMYb=-65g@mail.gmail.com>
 <CADHSJjD_C1JOGzeUY1-jhTKXqZ5kv1HySEQCmAsN71kok15++A@mail.gmail.com>
 <CAMaOp+E6Yw3GBs=nZ0Vvg4Dg5kCcC9mV2EGeNfu=uuMe58K1FQ@mail.gmail.com>
 <CADHSJjCYx82cgBZ3wbuT_t-2kTL8VN1dXUbkunW5dRh8jzJPew@mail.gmail.com>
Message-ID: <CAB5Fpx6g02HtzxTUERrga=UNv=zpEuy_XET0ZbE1RLN++Vc4Sg@mail.gmail.com>

Thank you, Utkarsh, for cleaning up many of the issues over the past few
days!

On Tue, Oct 10, 2017 at 8:54 AM, Utkarsh Ayachit <
utkarsh.ayachit at kitware.com> wrote:

> Dashboards should be in much better shape this morning. Please rebase
> all your ongoing branches on the latest master before testing since
> the changes in master which update VTK are extensive and cause all of
> ParaView to rebuild. Testing old branches will force the dashboard
> machines to do a complete rebuild as they switch between branches.
>
>
>
>
> On Mon, Oct 9, 2017 at 3:40 PM, Andy Bauer <andy.bauer at kitware.com> wrote:
> > I wasn't planning to get to that until tomorrow anyway. I'll check on the
> > status before working on it though.
> >
> > On Mon, Oct 9, 2017 at 3:37 PM, Utkarsh Ayachit
> > <utkarsh.ayachit at kitware.com> wrote:
> >>
> >> Andy,
> >>
> >> This MR may address vall issues too, not sure:
> >> https://gitlab.kitware.com/paraview/paraview/merge_requests/1957
> >> Just FYI.
> >>
> >> Utkarsh
> >>
> >> On Mon, Oct 9, 2017 at 1:08 PM, Utkarsh Ayachit
> >> <utkarsh.ayachit at kitware.com> wrote:
> >> > On Mon, Oct 9, 2017 at 10:51 AM, Andy Bauer <andy.bauer at kitware.com>
> >> > wrote:
> >> >>
> >> >> I don't see any coprocessing errors on Vall. Is this something that
> >> >> gets
> >> >> hit after/without sphinx?
> >> >>
> >> >
> >> > That's correct. e.g.
> >> > https://open.cdash.org/viewBuildError.php?buildid=5094399
> >> >
> >> > The Sphinx is now fixed in master, so you'll see it once buildbot gets
> >> > around to building `master`. In the mean time, look at any MR. Since
> we
> >> > don't build docs on MRs, it will skip the Sphinx issue.
> >
> >
>



-- 
Cory Quammen
Staff R&D Engineer
Kitware, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171012/0bfd8d77/attachment.html>

From kapinos at itc.rwth-aachen.de  Mon Oct 16 11:58:26 2017
From: kapinos at itc.rwth-aachen.de (Paul Kapinos)
Date: Mon, 16 Oct 2017 17:58:26 +0200
Subject: [Paraview-developers] Define NDEBUG in VTK Submodule (WAS: 100%
	CPU usage once again)
In-Reply-To: <89a4a97c938b4c75ad7436fc1ff26ec3@ES08AMSNLNT.srn.sandia.gov>
References: <89a4a97c938b4c75ad7436fc1ff26ec3@ES08AMSNLNT.srn.sandia.gov>
Message-ID: <bf91cbd8-4bf0-e5d8-5ec3-bfb2596fee72@itc.rwth-aachen.de>

Hi,

(a)
When adding -DCMAKE_BUILD_TYPE=Release to the cmake flags then the build get the
 -DNDEBUG flag instead of -DDEBUG, and VTK is build without debug information.

Hence: adding '-DCMAKE_BUILD_TYPE=Release' is solution/workaround for 'VTK is
build with debug' issue. Maybe you would like to add some defaults to CMAKE
files in ParaView (if building VTK without debug is what by default should happen).

(b)
On the original issue ("100% CPU usage") adding of this flag does not change
anything. Processes of non-debug build just spin on other MPI calls (cf.
'pstack' below, there are no debug informations anymore but we still can see
that there is a PMPI_Bcast() call from
vtkMPICommunicator::BroadcastVoidArray(void*, long long, int, int). It looks
like debug version of VTK just add some more MPI calls but did not change the
general behaviour of software - (busy) waiting on (blocking) MPI calls.

Well, we do not want to start the discussion about 'how to program MPI
applications'. I just cite Jeff  Squyres [8]:
> That being said, if an MPI application is waiting a long time for messages,
> perhaps its message passing algorithm should be re-designed to be a bit more
> efficient in terms of communication and computation overlap.
Yes busy waiting can be avoided at algorithmic level, cf. [12]

(3)
Meanwhile there was some progress on Open MPI:
- it has been told that the 'mpi_yield_when_idle' option *will really help* even
if top show 100%CPU,
> since the process is only yielding, the other running processes will get most
> of their time slices,
So setting this parameter is really recommendable,

- Gilles Gouaillardet developed a patch which solve the 100%-spinning issue for
latest Open MPI, cf. [13] [14], (tested for v3.0.0, patch need some patches to
apply on this version).

There is some uncertainness about this feature '-mca mpi_poll_when_idle true'
will flow into the mainstream Open MPI and if so it will not be prior 3.1.

Maybe you would like to update the WiKi with latest results.

Many thanks for your support
Paul Kapinos

[8] http://blogs.cisco.com/performance/polling-vs-blocking-message-passingprogress
[12] https://stackoverflow.com/questions/14560714/probe-seems-to-consume-the-cpu
[13] https://www.mail-archive.com/devel at lists.open-mpi.org//msg20408.html
[14] https://www.mail-archive.com/devel at lists.open-mpi.org//msg20413.html


------------------------------------------------------------------------------
Thread 1 (Thread 0x7efe3499c780 (LWP 25519)):
#0  0x00007efe1af78599 in opal_progress () from
/opt/MPI/openmpi-1.10.4/linux/gcc_4.8.5/lib/libopen-pal.so.13
#1  0x00007efe23d8b865 in ompi_request_default_wait () from
/opt/MPI/openmpi-1.10.4/linux/gcc_4.8.5/lib/libmpi.so.12
#2  0x00007efe0b57fa20 in ompi_coll_tuned_bcast_intra_generic () from
/opt/MPI/openmpi-1.10.4/linux/gcc_4.8.5/lib/openmpi/mca_coll_tuned.so
#3  0x00007efe0b57fef7 in ompi_coll_tuned_bcast_intra_binomial () from
/opt/MPI/openmpi-1.10.4/linux/gcc_4.8.5/lib/openmpi/mca_coll_tuned.so
#4  0x00007efe0b57478c in ompi_coll_tuned_bcast_intra_dec_fixed () from
/opt/MPI/openmpi-1.10.4/linux/gcc_4.8.5/lib/openmpi/mca_coll_tuned.so
#5  0x00007efe23d9fad0 in PMPI_Bcast () from
/opt/MPI/openmpi-1.10.4/linux/gcc_4.8.5/lib/libmpi.so.12
#6  0x00007efe30a86ee0 in vtkMPICommunicator::BroadcastVoidArray(void*, long
long, int, int) () from
/usr/local_rwth/sw/paraview/5.4.1-gcc_4.8.5-openmpi_1.10.4/lib/paraview-5.4/libvtkParallelMPI-pv5.4.so.1
#7  0x00007efe3084c933 in vtkMultiProcessController::BroadcastProcessRMIs(int,
int) () from
/usr/local_rwth/sw/paraview/5.4.1-gcc_4.8.5-openmpi_1.10.4/lib/paraview-5.4/libvtkParallelCore-pv5.4.so.1
#8  0x00007efe3084cfb5 in vtkMultiProcessController::ProcessRMIs(int, int) ()
from
/usr/local_rwth/sw/paraview/5.4.1-gcc_4.8.5-openmpi_1.10.4/lib/paraview-5.4/libvtkParallelCore-pv5.4.so.1
#9  0x0000000000401751 in main ()
------------------------------------------------------------------------------




On 10/11/2017 06:48 PM, Moreland, Kenneth wrote:
> What happens if you add -DCMAKE_BUILD_TYPE=Release to the cmake flags in your configure line?
> 
> -Ken
> 
> -----Original Message-----
> From: Paul Kapinos [mailto:kapinos at itc.rwth-aachen.de] 
> Sent: Wednesday, October 11, 2017 10:46 AM
> To: Moreland, Kenneth <kmorel at sandia.gov>; paraview-developers at paraview.org; Ayachit, Utkarsh (External Contacts) <utkarsh.ayachit at kitware.com>
> Subject: [EXTERNAL] Re: Define NDEBUG in VTK Submodule (WAS: 100% CPU usage once again)
> 
> We did an 'make VERBOSE=1' and what we see is for example (note the -DDEBUG flag!):
> ------------------------------------------------------------------------------
> cd
> /w0/tmp/pk224850/PARAVIEW_BUILD/5.4.1-gcc_4.8.5-intelmpi_5.1.3.181/VTK/ThirdParty/hdf5/vtkhdf5/hl/src
> && /usr/bin/gcc  -DDEBUG -DMPICH_IGNORE_CXX_SEEK -DVTK_IN_VTK -D_BSD_SOURCE
> -D_DEFAULT_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_LARGEFILE64_SOURCE
> -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=199506L -Dhdf5_hl_EXPORTS
> -I/w0/tmp/pk224850/PARAVIEW_BUILD/5.4.1-gcc_4.8.5-intelmpi_5.1.3.181
> -I/w0/tmp/pk224850/PARAVIEW_BUILD/5.4.1-gcc_4.8.5-intelmpi_5.1.3.181/VTK/ThirdParty/hdf5/vtkhdf5
> -I/w0/tmp/pk224850/PARAVIEW_BUILD/ParaView-v5.4.1/VTK/ThirdParty/hdf5/vtkhdf5/hl/src
> -I/w0/tmp/pk224850/PARAVIEW_BUILD/ParaView-v5.4.1/VTK/ThirdParty/hdf5/vtkhdf5/src
> -I/w0/tmp/pk224850/PARAVIEW_BUILD/5.4.1-gcc_4.8.5-intelmpi_5.1.3.181/VTK/ThirdParty/hdf5
> -I/w0/tmp/pk224850/PARAVIEW_BUILD/ParaView-v5.4.1/VTK/ThirdParty/hdf5
> -I/w0/tmp/pk224850/PARAVIEW_BUILD/5.4.1-gcc_4.8.5-intelmpi_5.1.3.181/VTK/ThirdParty/zlib
> -I/w0/tmp/pk224850/PARAVIEW_BUILD/ParaView-v5.4.1/VTK/ThirdParty/zlib
> -I/w0/tmp/pk224850/PARAVIEW_BUILD/5.4.1-gcc_4.8.5-intelmpi_5.1.3.181/bin
> -I/w0/tmp/pk224850/PARAVIEW_BUILD/5.4.1-gcc_4.8.5-intelmpi_5.1.3.181/VTK/ThirdParty/hdf5/vtkhdf5/src
>  -w -w -std=c99 -finline-functions -fno-common -w -Wextra -Wundef -Wshadow
> -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings
> -Wconversion -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes
> -Wmissing-declarations -Wredundant-decls -Wnested-externs -Winline
> -fmessage-length=0 -g -fPIC   -Wall   -o CMakeFiles/vtkhdf5_hl.dir/H5DS.c.o   -c
> /w0/tmp/pk224850/PARAVIEW_BUILD/ParaView-v5.4.1/VTK/ThirdParty/hdf5/vtkhdf5/hl/src/H5DS.c
> ------------------------------------------------------------------------------
> 
> Configure line was:
> ------------------------------------------------------------------------------
> cmake  -DPARAVIEW_USE_MPI=ON           \
>                      -DPARAVIEW_USE_VISITBRIDGE=ON               \
>                          -DVISIT_BUILD_READER_CGNS=OFF          \
>                          -DPARAVIEW_ENABLE_CGNS=OFF             \
>                      -DPARAVIEW_BUILD_QT_GUI=OFF     \
>                      -DVTK_USE_X=OFF                 \
>    -DOPENGL_INCLUDE_DIR=IGNORE                       \
>    -DOPENGL_xmesa_INCLUDE_DIR=IGNORE                            \
>    -DOPENGL_gl_LIBRARY=IGNORE                        \
>    -DOSMESA_INCLUDE_DIR=${INST}/include        \
>    -DOSMESA_LIBRARY=${INST}/lib/libOSMesa.so   \
>                      -DVTK_OPENGL_HAS_OSMESA=ON                 \
>                      -DVTK_USE_OFFSCREEN=OFF                    \
>                      -DCMAKE_INSTALL_PREFIX=${INST}     ../ParaView-v${VER}
> ${GCCB}  2>&1 | tee log.$START.01.cmake.txt
> ------------------------------------------------------------------------------
> 
> 
> 
> 
> On 10/11/2017 06:39 PM, Moreland, Kenneth wrote:
>> That's weird. I thought CMake was supposed to automatically add the -DNDEBUG flag whenever you compile anything under Release mode.
>>
>> At any rate, I'll hand that question off to Utkarsh or one of the ParaView team at Kitware. They would be better than me at answering build questions like this.
>>
>> -Ken
>>
>> -----Original Message-----
>> From: Paul Kapinos [mailto:kapinos at itc.rwth-aachen.de] 
>> Sent: Wednesday, October 11, 2017 10:19 AM
>> To: Moreland, Kenneth <kmorel at sandia.gov>; paraview-developers at paraview.org
>> Subject: [EXTERNAL] Re: [Paraview-developers] 100% CPU usage once again
>>
>> Kenneth, thank you for your message and the update of the wiki!
>>
>> Meanwhile I was able to reproduce the busy waiting with Open MPI (and other
>> MPIs) on a 10-line-example and asked the Open MPI developers about this:
>> https://www.mail-archive.com/devel at lists.open-mpi.org//msg20407.html
>>
>> The spinning processes stuck at MPI_Barrier call in line 40 of
>> 'ParaView-v5.4.1/VTK/Parallel/MPI/vtkMPICommunicator.cxx' file,
>>>     34 static inline void  vtkMPICommunicatorDebugBarrier(MPI_Comm* handle)
>>>     35 {
>>>     36   // If NDEBUG is defined, do nothing.
>>>     37 #ifdef NDEBUG
>>>     38   (void)handle; // to avoid warning about unused parameter
>>>     39 #else
>>>     40   MPI_Barrier(*handle);
>>>     41 #endif
>>>     42 }
>> It seem that ParaView's auto-build VTK version is build without NDEBUG define,
>> or with other words, *with* debug stuff.
>>
>> Q: Is there a way to tell the ParaView's configure to set the VTK's define
>> 'NDEBUG'? Or, more general, how-to tune VTK parameters? :o)
>>
>> Have a nice day,
>>
>> Paul Kapinos
>>
>>
>>
>>
>>
>> On 10/09/2017 11:27 PM, Moreland, Kenneth wrote:
>>> Paul,
>>>
>>> Thanks for the info. I updated the Wiki page with your information. Hopefully I captured everything.
>>>
>>> I'll let someone from Kitware respond about the possibility of changing the binaries that are distributed.
>>>
>>> -Ken
>>>
>>> -----Original Message-----
>>> From: Paraview-developers [mailto:paraview-developers-bounces at paraview.org] On Behalf Of Paul Kapinos
>>> Sent: Monday, October 9, 2017 1:08 AM
>>> To: paraview-developers at paraview.org
>>> Subject: [EXTERNAL] [Paraview-developers] 100% CPU usage once again
>>>
>>> (cross-post from 'paraview at paraview.org' 10/04/2017)
>>>
>>> Dear ParaView developer,
>>>
>>> in [1] you say
>>>> If you have information on disabling the busy wait using a different 
>>>> MPI implementation, please contribute back by documenting it here.
>>>
>>> Here we go.
>>>
>>> a)
>>> It is possible to build 'pvserver' using Intel MPI (and GCC compilers).
>>> By setting I_MPI_WAIT_MODE  environment variable to 'enable' value you can effectively prevent busy waiting, see [2] p.10 (Tested with Intel MPI 5.1(.3.181)).
>>>
>>> Q/FR.1 Could you please provide a version of 'pvserver' build using Intel MPI in official release of ParaView? [4]
>>>
>>>
>>>
>>> b)
>>> It is (obviously) possible to build 'pvserver' using MPICH (and GCC compilers).
>>> Itself, MPICH can be *configured* with '--with-device=ch3:sock' option. This is described to be 'slower' as '--with-device=ch3:nemesis'
>>> For our experiments it turned out, that 'pvserver' compiled and linked using MPICH with 'ch3:sock' configure option did not have the busy waiting aka 100%-CPU behaviour.
>>> Note that this is *configure-time of MPI library* parameter.
>>>
>>>
>>> (Tested with MPICH  3.2)
>>>
>>> Q/FR.2 Could you please provide a version of 'pvserver' build using MPICH *configured with '--with-device=ch3:sock' option* in official release of ParaView? [4] This binary will be very likely be even compatible with 'standard' MPICH installations; we're able to start it even with IntelMPI's 'mpiexec' with success and no busy waiting. However YES you will need to have a MPICH release be build
>>>
>>>
>>>
>>>
>>> c)
>>> It is possible to build 'pvserver' using Open MPI (and GCC compilers).
>>> In [1] you document how-to 'turn off' the busy waiting behaviour in Open MPI (cf. [5],[6]).
>>> Unfortunately this *did not work* in our environment (InfiniBand QDR and Intel OmniPath clusters, OpenMPI 1.10.4).
>>> Note that likely we're not alone, cf. [7].
>>> Note that the switch likely just move the spinning location from MPI library itself to the fabrics library (cf. the screenshots, without 'mpi_yield_when_idle 1' (=default) the 'pvserver' processes spin with 'green' aka user 100%, and with 'mpi_yield_when_idle 1' the processes stays spinning but now with a lot of 'red'
>>> aka kernel time portion.
>>>
>>> Conclusion: the way to disable busy waiting for Open MPI which is documented in [1], is not useful for us. We do not know this is a speciality of our site or a general issue; we think some survey at this point could be useful.
>>>
>>> Q/FR.3 In case you should want to provide precompiled versions ov 'pvserver' for Open MPI, remember that there are ABI changes in major version changes. So you would likely need to compile+link *three* versions of 'pvserver' with Open MPI 1.10.x (still default in Linux), 2.x (current), 3.x (new).
>>>
>>>
>>>
>>> d) In [10] there is a phrase about how-to disable busy waiting on yet another two MPI implementaions,
>>>> ... IBM MPI has the MP_WAIT_MODE and
>>>> the SUPER-UX MPI/XS library has MPISUSPEND to choose the waiting mode, 
>>>> either polling or sleeping.
>>>
>>> Somebody with access to there MPIs could evaluate this, maybe.
>>>
>>> Have a nice day,
>>>
>>> Paul Kapinos
>>>
>>>
>>>
>>> [1]
>>> https://www.paraview.org/Wiki/Setting_up_a_ParaView_Server#Server_processes_always_have_100.25_CPU_usage
>>>
>>> [2]
>>> https://software.intel.com/sites/products/Whitepaper/Clustertools/amplxe_inspxe_interop_with_mpi.pdf
>>>   (cf. p.10)
>>>
>>> [3]
>>> https://wiki.mpich.org/mpich/index.php/Frequently_Asked_Questions#Q:_Why_does_my_MPI_program_run_much_slower_when_I_use_more_processes.3F
>>>
>>> [4] https://www.paraview.org/download/
>>>
>>> [5] http://www.open-mpi.org/faq/?category=running#oversubscribing
>>>
>>> [6] http://www.open-mpi.org/faq/?category=running#force-aggressive-degraded
>>>
>>> [7] https://www.paraview.org/pipermail/paraview/2008-December/010349.html
>>>
>>> [8] http://blogs.cisco.com/performance/polling-vs-blocking-message-passingprogress
>>>
>>> [9] https://www.open-mpi.org/community/lists/users/2010/10/14505.php
>>>
>>> [10] http://comp.parallel.mpi.narkive.com/3oXMDXno/non-busy-waiting-barrier-in-mpi
>>>
>>> [11] http://blogs.cisco.com/performance/polling-vs-blocking-message-passingprogress
>>>
>>> [12] https://stackoverflow.com/questions/14560714/probe-seems-to-consume-the-cpu
>>>
>>>
>>
>>
> 
> 


-- 
Dipl.-Inform. Paul Kapinos   -   High Performance Computing,
RWTH Aachen University, IT Center
Seffenter Weg 23,  D 52074  Aachen (Germany)
Tel: +49 241/80-24915

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4891 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171016/266a7a28/attachment.bin>

From ben.boeckel at kitware.com  Mon Oct 16 12:58:59 2017
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Mon, 16 Oct 2017 12:58:59 -0400
Subject: [Paraview-developers] Define NDEBUG in VTK Submodule (WAS: 100%
 CPU usage once again)
In-Reply-To: <bf91cbd8-4bf0-e5d8-5ec3-bfb2596fee72@itc.rwth-aachen.de>
References: <89a4a97c938b4c75ad7436fc1ff26ec3@ES08AMSNLNT.srn.sandia.gov>
 <bf91cbd8-4bf0-e5d8-5ec3-bfb2596fee72@itc.rwth-aachen.de>
Message-ID: <20171016165859.GA28854@megas.kitware.com>

On Mon, Oct 16, 2017 at 17:58:26 +0200, Paul Kapinos wrote:
> Hence: adding '-DCMAKE_BUILD_TYPE=Release' is solution/workaround for 'VTK is
> build with debug' issue. Maybe you would like to add some defaults to CMAKE
> files in ParaView (if building VTK without debug is what by default should happen).

The default for ParaView is actually Debug. See CMakeLists.txt line 44:

    https://gitlab.kitware.com/paraview/paraview/blob/master/CMakeLists.txt#L44

This was set back in 2013 and doesn't seem to have been modified since
then. Whether this should continue to be the default or not can be
discussed.

--Ben

From jfavre at cscs.ch  Wed Oct 18 09:47:17 2017
From: jfavre at cscs.ch (Favre  Jean)
Date: Wed, 18 Oct 2017 13:47:17 +0000
Subject: [Paraview-developers] failed to install six.pyc
Message-ID: <0EB9B6375711A04B820E6B6F5CCA9F685C9D9941@MBX111.d.ethz.ch>


I am compiling my v5.4.1 with python3 on an Ubuntu system

Python 3.5.2 (default, Sep 14 2017, 22:51:06) 
[GCC 5.4.0 20160609] on linux

It fails during installation with the error:

CMake Error at VTK/ThirdParty/SixPython/cmake_install.cmake:40 (file):
  file INSTALL cannot find
  "/local/apps/ParaView/ParaView-v5.4.1Build-Qt5/lib/site-packages/six.pyc".
Call Stack (most recent call first):
  VTK/cmake_install.cmake:104 (include)
  cmake_install.cmake:64 (include)

I also see the same problem with the git master checkout. Any clue to overcome the problem?

-----------------
Jean

From mvanmoer at illinois.edu  Wed Oct 18 12:30:14 2017
From: mvanmoer at illinois.edu (Van Moer, Mark W)
Date: Wed, 18 Oct 2017 16:30:14 +0000
Subject: [Paraview-developers] [Paraview] Accessing particles generated
	by ParticleTracer
In-Reply-To: <CAC2t4USbro2nhTPFDLFdRqVStBBRonr3uzauu4jkUXLRn21uhQ@mail.gmail.com>
References: <7F781841FF1E044388AFA42B70703A7AE7F4F241@CHIMBX6.ad.uillinois.edu>
 <CAC2t4UTJEm6gPK=NDthHTWuvNXvKOhYNMW_WSf4cAm2nEXpwqg@mail.gmail.com>
 <7F781841FF1E044388AFA42B70703A7AE7F4F326@CHIMBX6.ad.uillinois.edu>
 <CAC2t4USbro2nhTPFDLFdRqVStBBRonr3uzauu4jkUXLRn21uhQ@mail.gmail.com>
Message-ID: <7F781841FF1E044388AFA42B70703A7AE7F55469@CHIMBX6.ad.uillinois.edu>

Hi Mathieu,

Thanks for the suggestions. I tried having a Programmable Filter take the PolyData input, do the check, and write new PolyData output, and that kind of worked, except that particles could reappear after being deleted. That a particle was deleted wasn?t being sent back upstream to the Particle Tracer, upstream state changes aren?t supported as I understand it.

I tried making a plugin by deriving from vtkParticleTracerBase and overriding RequestData() and IntegrateParticles(), however, that doesn?t work because they accesses private members of vtkParticleTracerBase.

I also tried copying vtkParticleTracerBase to a new class and hacking on it directly, but I?m getting link errors when I try to load the plugin, like

undefined symbol: _Z34vtkParticleTracerWithSinkBase_Init_P26vtkClientServerInterpreter

(I was able to hack directly on vtkParticleTracerBase.cxx in the ParaView src tree and it worked as expected, but I would rather get a plugin working.)


-          When making a plugin based on an abstract VTK class, does something need to change in the CMakeLists.txt? I?m just guessing that?s where my issue with the link error is?

Thanks,
Mark



From: Mathieu Westphal [mailto:mathieu.westphal at kitware.com]
Sent: Tuesday, September 26, 2017 9:22 AM
To: Van Moer, Mark W <mvanmoer at illinois.edu>
Cc: ParaView Developers <paraview-developers at paraview.org>; ParaView <paraview at paraview.org>
Subject: Re: [Paraview] Accessing particles generated by ParticleTracer

Hello
Simplest way to go would be to add a Python Programmable Filter after the particle tracer, that process each point and does not copy it when it is too far from an arbitrary point.
This would work, even with paraview release, but will not be so most efficient implementation.
Harder way to go would be to copy(or inherit) the ParticleTracer as a new vtk filter and associated xml proxy plugin. And add a radius check in the code, probably in vtkParticleTracerBase::RequestData:1188

            // if the particle is sent, remove it from the list
-            if (this->SendParticleToAnotherProcess(info,previous,this->OutputPointData))
+            if (this->SendParticleToAnotherProcess(info,previous,this->OutputPointData) || !yourRadiusTest(point2))
            {
              this->ParticleHistories.erase(it);
              particle_good = false;
             }

much more efficient but you will need to know C++ and how to compile ParaView and a ParaView plugin.

Best,

Mathieu Westphal

On Tue, Sep 26, 2017 at 3:53 PM, Van Moer, Mark W <mvanmoer at illinois.edu<mailto:mvanmoer at illinois.edu>> wrote:
Hi Mathieu,

The full science context is, this is a simulation of a binary black hole system. The way the solver works, the black hole locations aren?t actually in the mesh, they?re stored as separate coordinates with an associated radius. The black holes orbit each other during the simulation, creating turbulence in the plasma (and magnetic field). I made a few videos of particles being advected by the plasma velocity. This was basically just the mesh, a seed source, and a Particle Tracer filter. This works fine, except that particles which get within the radius of each black hole end up coagulating and behaving non-physically. If I understand the scientist right, in the simulation itself, they are able to handle this somehow correctly, but that behavior doesn?t get translated to what?s saved in the mesh.

That?s part 1. Part 2 of the vis, and this works, is that the plasma advected particles are used as seeds for streamlines through the magnetic field -- though there are streamlines coming out of non-physically correct particles.

What I?d like is to be able to check of each of the actual particle locations vs the black hole locations and radii and if they?re within that radii, delete them (or hide them, make them transparent, whatever.)  I was hoping this was something I could do with a programmable filter, but I?m open to any suggestions, including hacking on VTK source.

Mark

From: Mathieu Westphal [mailto:mathieu.westphal at kitware.com<mailto:mathieu.westphal at kitware.com>]
Sent: Tuesday, September 26, 2017 2:47 AM
To: Van Moer, Mark W <mvanmoer at illinois.edu<mailto:mvanmoer at illinois.edu>>; ParaView Developers <paraview-developers at paraview.org<mailto:paraview-developers at paraview.org>>
Cc: ParaView <paraview at paraview.org<mailto:paraview at paraview.org>>
Subject: Re: [Paraview] Accessing particles generated by ParticleTracer

Hello
Can you give some context ? At which level of implementation are you trying to do that ?
Best,

Mathieu Westphal

On Tue, Sep 26, 2017 at 12:09 AM, Van Moer, Mark W <mvanmoer at illinois.edu<mailto:mvanmoer at illinois.edu>> wrote:
Looks like I?d have to get at the std::vector<ParticleInformation> ParticleVector that?s inherited from vtkParticleTracerBase? I?m guessing that?s not exposed by the proxy.
Mark

From: Van Moer, Mark W
Sent: Monday, September 25, 2017 2:25 PM
To: ParaView <paraview at paraview.org<mailto:paraview at paraview.org>>
Subject: Accessing particles generated by ParticleTracer

Hi ParaView,

Is it possible to get at the individual particles generated by ParticleTracer? I?ve been handed a mesh with a velocity field and an implied particle sink. I?d like to delete any particles that wander within a certain radius of that sink. My thought was if I could get at the array holding the particles I could check each distance and delete as necessary.

Thanks,
Mark

_______________________________________________
Powered by www.kitware.com<http://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

Search the list archives at: http://markmail.org/search/?q=ParaView

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


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

From mathieu.westphal at kitware.com  Thu Oct 19 03:02:35 2017
From: mathieu.westphal at kitware.com (Mathieu Westphal)
Date: Thu, 19 Oct 2017 09:02:35 +0200
Subject: [Paraview-developers] [Paraview] Accessing particles generated
	by ParticleTracer
In-Reply-To: <7F781841FF1E044388AFA42B70703A7AE7F55469@CHIMBX6.ad.uillinois.edu>
References: <7F781841FF1E044388AFA42B70703A7AE7F4F241@CHIMBX6.ad.uillinois.edu>
 <CAC2t4UTJEm6gPK=NDthHTWuvNXvKOhYNMW_WSf4cAm2nEXpwqg@mail.gmail.com>
 <7F781841FF1E044388AFA42B70703A7AE7F4F326@CHIMBX6.ad.uillinois.edu>
 <CAC2t4USbro2nhTPFDLFdRqVStBBRonr3uzauu4jkUXLRn21uhQ@mail.gmail.com>
 <7F781841FF1E044388AFA42B70703A7AE7F55469@CHIMBX6.ad.uillinois.edu>
Message-ID: <CAC2t4UQhCVseJtv_OWX_Ak9CffngWsmnzgad9WemucBorP0fxw@mail.gmail.com>

Hello

Regarding the Programmable Filter, you are right, there is no way to
specify it upstream,
 you would need to keep a list of previously deleted particle that should
stay deleted, definitelly not a great solution.

Regarding the inheritance, you are right as well, but keep in mind that
ParaView is Open Source and you can contribute to the code of the
vtkParticleStreamer if you want
and add some kind of check in the base class that you could redefine in
your class if you want.

Regarding the plugin loading problem, are you trying to load the plugin in
the paraview release (not good) or in the paraview you build the plugin
with (good).
If this part is ok, then i would suggest first trying the examples plugins
in ParaView source. You will find correctly written CMakeLists and you can
work your way up from there.
"paraview/Examples/Plugins/Filter" seems a good starting point. Just copy
the folder somewhere, build it and check it can be loaded in ParaView.

Let me know if you run into any troubles.

Best,


Mathieu Westphal

On Wed, Oct 18, 2017 at 6:30 PM, Van Moer, Mark W <mvanmoer at illinois.edu>
wrote:

> Hi Mathieu,
>
>
>
> Thanks for the suggestions. I tried having a Programmable Filter take the
> PolyData input, do the check, and write new PolyData output, and that kind
> of worked, except that particles could reappear after being deleted. That a
> particle was deleted wasn?t being sent back upstream to the Particle
> Tracer, upstream state changes aren?t supported as I understand it.
>
>
>
> I tried making a plugin by deriving from vtkParticleTracerBase and
> overriding RequestData() and IntegrateParticles(), however, that doesn?t
> work because they accesses private members of vtkParticleTracerBase.
>
>
>
> I also tried copying vtkParticleTracerBase to a new class and hacking on
> it directly, but I?m getting link errors when I try to load the plugin,
> like
>
>
>
> undefined symbol: _*Z34vtkParticleTracerWithSinkBase_Init*_
> P26vtkClientServerInterpreter
>
>
>
> (I was able to hack directly on vtkParticleTracerBase.cxx in the ParaView
> src tree and it worked as expected, but I would rather get a plugin
> working.)
>
>
>
> -          When making a plugin based on an abstract VTK class, does
> something need to change in the CMakeLists.txt? I?m just guessing that?s
> where my issue with the link error is?
>
>
>
> Thanks,
>
> Mark
>
>
>
>
>
>
>
> *From:* Mathieu Westphal [mailto:mathieu.westphal at kitware.com]
> *Sent:* Tuesday, September 26, 2017 9:22 AM
> *To:* Van Moer, Mark W <mvanmoer at illinois.edu>
> *Cc:* ParaView Developers <paraview-developers at paraview.org>; ParaView <
> paraview at paraview.org>
>
> *Subject:* Re: [Paraview] Accessing particles generated by ParticleTracer
>
>
>
> Hello
>
> Simplest way to go would be to add a Python Programmable Filter after the
> particle tracer, that process each point and does not copy it when it is
> too far from an arbitrary point.
>
> This would work, even with paraview release, but will not be so most
> efficient implementation.
>
> Harder way to go would be to copy(or inherit) the ParticleTracer as a new
> vtk filter and associated xml proxy plugin. And add a radius check in the
> code, probably in vtkParticleTracerBase::RequestData:1188
>
>             // if the particle is sent, remove it from the list
> -            if (this->SendParticleToAnotherProcess(info,previous,this->
> OutputPointData))
>
> +            if (this->SendParticleToAnotherProcess(info,previous,this->OutputPointData)
> || !yourRadiusTest(point2))
>
>             {
>               this->ParticleHistories.erase(it);
>               particle_good = false;
>
>              }
>
>
>
> much more efficient but you will need to know C++ and how to compile
> ParaView and a ParaView plugin.
>
>
>
> Best,
>
>
> Mathieu Westphal
>
>
>
> On Tue, Sep 26, 2017 at 3:53 PM, Van Moer, Mark W <mvanmoer at illinois.edu>
> wrote:
>
> Hi Mathieu,
>
>
>
> The full science context is, this is a simulation of a binary black hole
> system. The way the solver works, the black hole locations aren?t actually
> in the mesh, they?re stored as separate coordinates with an associated
> radius. The black holes orbit each other during the simulation, creating
> turbulence in the plasma (and magnetic field). I made a few videos of
> particles being advected by the plasma velocity. This was basically just
> the mesh, a seed source, and a Particle Tracer filter. This works fine,
> except that particles which get within the radius of each black hole end up
> coagulating and behaving non-physically. If I understand the scientist
> right, in the simulation itself, they are able to handle this somehow
> correctly, but that behavior doesn?t get translated to what?s saved in the
> mesh.
>
>
>
> That?s part 1. Part 2 of the vis, and this works, is that the plasma
> advected particles are used as seeds for streamlines through the magnetic
> field -- though there are streamlines coming out of non-physically correct
> particles.
>
>
>
> What I?d like is to be able to check of each of the actual particle
> locations vs the black hole locations and radii and if they?re within that
> radii, delete them (or hide them, make them transparent, whatever.)  I was
> hoping this was something I could do with a programmable filter, but I?m
> open to any suggestions, including hacking on VTK source.
>
>
>
> Mark
>
>
>
> *From:* Mathieu Westphal [mailto:mathieu.westphal at kitware.com]
> *Sent:* Tuesday, September 26, 2017 2:47 AM
> *To:* Van Moer, Mark W <mvanmoer at illinois.edu>; ParaView Developers <
> paraview-developers at paraview.org>
> *Cc:* ParaView <paraview at paraview.org>
> *Subject:* Re: [Paraview] Accessing particles generated by ParticleTracer
>
>
>
> Hello
>
> Can you give some context ? At which level of implementation are you
> trying to do that ?
>
> Best,
>
>
> Mathieu Westphal
>
>
>
> On Tue, Sep 26, 2017 at 12:09 AM, Van Moer, Mark W <mvanmoer at illinois.edu>
> wrote:
>
> Looks like I?d have to get at the std::vector<ParticleInformation>
> ParticleVector that?s inherited from vtkParticleTracerBase? I?m guessing
> that?s not exposed by the proxy.
>
> Mark
>
>
>
> *From:* Van Moer, Mark W
> *Sent:* Monday, September 25, 2017 2:25 PM
> *To:* ParaView <paraview at paraview.org>
> *Subject:* Accessing particles generated by ParticleTracer
>
>
>
> Hi ParaView,
>
>
>
> Is it possible to get at the individual particles generated by
> ParticleTracer? I?ve been handed a mesh with a velocity field and an
> implied particle sink. I?d like to delete any particles that wander within
> a certain radius of that sink. My thought was if I could get at the array
> holding the particles I could check each distance and delete as necessary.
>
>
>
> Thanks,
>
> Mark
>
>
> _______________________________________________
> 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
>
> Search the list archives at: http://markmail.org/search/?q=ParaView
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/paraview
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171019/c847a438/attachment.html>

From cornelis.bockemuehl at gmail.com  Sun Oct 22 09:25:27 2017
From: cornelis.bockemuehl at gmail.com (=?UTF-8?Q?Cornelis_Bockem=C3=BChl?=)
Date: Sun, 22 Oct 2017 15:25:27 +0200
Subject: [Paraview-developers] Bug found, then stuck...
Message-ID: <CACqg2jf0wG2B8Mx0VrgmnA+OfM+yvXdoYLtQzZaYA5VV0vBeDA@mail.gmail.com>

Dear VTK developers,

First of all: Am I posting this maybe in the wrong mailing list??

Anyway, here I go: In some project I am using the vtkIntersectPolyData
filter. This works as expected many times, but from time to time I had
crashes. I managed to track down these crashes to a little bug in that
class that can be fixed by a very little change:

in vtkIntersectionPolyDataFilter.cxx(14'1), replace

  lineBool = new bool[pd->GetNumberOfCells()];


by


  lineBool = new bool[pd->GetNumberOfCells() + 1];


The crash happened when this array was released (heap corruption), and it
turned out that indeed under some circumstances the program writes one
element more than there is allocated memory. This happens if further down
in the GetSingleLoop function the "else if" branch is chosen inside the "if
-- else if -- else" construct: Here the pd cells array is extended by one
element.

With the above fix the crash goes indeed away, but then later on the
program throws an exception at vtkCellLinks.h(171):

  /**

   * Increment the count of the number of cells using the point.

   */

  void IncrementLinkCount(vtkIdType ptId) { this->Array[ptId].ncells++;};


call stack at this point:


1   vtkCellLinks::IncrementLinkCount
vtkCellLinks.h                          171  0x7feced1c91a
2   vtkCellLinks::BuildLinks
vtkCellLinks.cxx                        153  0x7feced1a89a
3   vtkPolyData::BuildLinks
vtkPolyData.cxx                         1096 0x7fecf022ff1
4   debug_vtkIntersectionPolyDataFilter::Impl::SplitCell
debug_vtkIntersectionPolyDataFilter.cxx 1007 0x7fec0c994e2
5   debug_vtkIntersectionPolyDataFilter::Impl::SplitMesh
debug_vtkIntersectionPolyDataFilter.cxx 630  0x7fec0c971cc
6   debug_vtkIntersectionPolyDataFilter::RequestData
debug_vtkIntersectionPolyDataFilter.cxx 2590 0x7fec0c94531
7   vtkPolyDataAlgorithm::ProcessRequest
vtkPolyDataAlgorithm.cxx                90   0x7fecf556116
8   vtkExecutive::CallAlgorithm
vtkExecutive.cxx                        775  0x7fecf50eb55
9   vtkDemandDrivenPipeline::ExecuteData
vtkDemandDrivenPipeline.cxx             491  0x7fecf50477c
10  vtkCompositeDataPipeline::ExecuteData
vtkCompositeDataPipeline.cxx            179  0x7fecf4fc560
11  vtkDemandDrivenPipeline::ProcessRequest
vtkDemandDrivenPipeline.cxx             274  0x7fecf503343
12  vtkStreamingDemandDrivenPipeline::ProcessRequest
vtkStreamingDemandDrivenPipeline.cxx    328  0x7fecf588f67
13  vtkDemandDrivenPipeline::UpdateData
vtkDemandDrivenPipeline.cxx             444  0x7fecf5042da
14  vtkStreamingDemandDrivenPipeline::Update
vtkStreamingDemandDrivenPipeline.cxx    403  0x7fecf589412
15  vtkStreamingDemandDrivenPipeline::Update
vtkStreamingDemandDrivenPipeline.cxx    366  0x7fecf58916c
16  vtkAlgorithm::Update
vtkAlgorithm.cxx                        1457 0x7fecf4e5348
17  vtkAlgorithm::Update
vtkAlgorithm.cxx                        1451 0x7fecf4e53b3
18  vtkCemTestIntersectionFilter::RequestData
vtkCemTestIntersectionFilter.cxx        252  0x7fec0c84e7f
19  vtkPolyDataAlgorithm::ProcessRequest
vtkPolyDataAlgorithm.cxx                90   0x7fecf556116
20  vtkExecutive::CallAlgorithm
vtkExecutive.cxx                        775  0x7fecf50eb55
... <More>


Note that debug_vtkIntersectionPolyDataFilter is a copy of
vtkIntersectionPolyDataFilter that I prepared to do my testing and add some
debug output stuff etc. without interfering with the original code.

I guess that the exception is again a consequence of adding that "cell" in
GetSingleLoop, but now I must admit that my understanding of the internals
of these geometric object classes is not yet good enough to see what went
wrong! The code that needs checking by an expert seems to me the following

vtkIntersectionPolyDataFilter.cxx(1536..1555):

    //There is one line attached to point. This means the intersection has

    //an open intersection loop (i.e. the surfaces are open and one does not

    //completeley intersect the other.

    //Make an artificial triangle loop in this case

    else if (pointCells->GetNumberOfIds() < 2)

    {

      vtkSmartPointer<vtkPolyData> currentpd =

        vtkSmartPointer<vtkPolyData>::New();

      vtkSmartPointer<vtkCellArray> currentcells =

        vtkSmartPointer<vtkCellArray>::New();

      currentcells = pd->GetLines();

      currentcells->InsertNextCell(2);

      currentcells->InsertCellPoint(nextPt);

      currentcells->InsertCellPoint(startPt);

      nextCell = currentcells->GetNumberOfCells()-1;

      currentpd->SetLines(currentcells);

      currentpd->SetPoints(pd->GetPoints());

      pd->DeepCopy(currentpd);

      pd->BuildLinks();

    }


My guess is that this code is not yet good enough to properly insert the
"cell" into pd...

Any idea?

Regards,
Cornelis

-- 
Cornelis Bockem?hl
Basel, Schweiz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171022/6cb12e5a/attachment.html>

From cory.quammen at kitware.com  Sun Oct 22 10:06:08 2017
From: cory.quammen at kitware.com (Cory Quammen)
Date: Sun, 22 Oct 2017 10:06:08 -0400
Subject: [Paraview-developers] Bug found, then stuck...
In-Reply-To: <CACqg2jf0wG2B8Mx0VrgmnA+OfM+yvXdoYLtQzZaYA5VV0vBeDA@mail.gmail.com>
References: <CACqg2jf0wG2B8Mx0VrgmnA+OfM+yvXdoYLtQzZaYA5VV0vBeDA@mail.gmail.com>
Message-ID: <CAB5Fpx4X_ys+JvbcTKmg_tY7VqmJHtUcYV0Vn3uLZfhwyBcKMg@mail.gmail.com>

Cornelius,

Thank you for the detailed bug report and your findings!
vtk-developers at vtk.org (CC'ed) is a more appropriate list for this problem
as it is VTK code in question, but no worries. I have filed an issue with
your message in the VTK bug tracker for further tracking of this issue:

https://gitlab.kitware.com/vtk/vtk/issues/17153

Thanks!

Cory

On Sun, Oct 22, 2017 at 9:25 AM, Cornelis Bockem?hl <
cornelis.bockemuehl at gmail.com> wrote:

> Dear VTK developers,
>
> First of all: Am I posting this maybe in the wrong mailing list??
>
> Anyway, here I go: In some project I am using the vtkIntersectPolyData
> filter. This works as expected many times, but from time to time I had
> crashes. I managed to track down these crashes to a little bug in that
> class that can be fixed by a very little change:
>
> in vtkIntersectionPolyDataFilter.cxx(14'1), replace
>
>   lineBool = new bool[pd->GetNumberOfCells()];
>
>
> by
>
>
>   lineBool = new bool[pd->GetNumberOfCells() + 1];
>
>
> The crash happened when this array was released (heap corruption), and it
> turned out that indeed under some circumstances the program writes one
> element more than there is allocated memory. This happens if further down
> in the GetSingleLoop function the "else if" branch is chosen inside the "if
> -- else if -- else" construct: Here the pd cells array is extended by one
> element.
>
> With the above fix the crash goes indeed away, but then later on the
> program throws an exception at vtkCellLinks.h(171):
>
>   /**
>
>    * Increment the count of the number of cells using the point.
>
>    */
>
>   void IncrementLinkCount(vtkIdType ptId) { this->Array[ptId].ncells++;};
>
>
> call stack at this point:
>
>
> 1   vtkCellLinks::IncrementLinkCount                     vtkCellLinks.h                          171  0x7feced1c91a
> 2   vtkCellLinks::BuildLinks                             vtkCellLinks.cxx                        153  0x7feced1a89a
> 3   vtkPolyData::BuildLinks                              vtkPolyData.cxx                         1096 0x7fecf022ff1
> 4   debug_vtkIntersectionPolyDataFilter::Impl::SplitCell debug_vtkIntersectionPolyDataFilter.cxx 1007 0x7fec0c994e2
> 5   debug_vtkIntersectionPolyDataFilter::Impl::SplitMesh debug_vtkIntersectionPolyDataFilter.cxx 630  0x7fec0c971cc
> 6   debug_vtkIntersectionPolyDataFilter::RequestData     debug_vtkIntersectionPolyDataFilter.cxx 2590 0x7fec0c94531
> 7   vtkPolyDataAlgorithm::ProcessRequest                 vtkPolyDataAlgorithm.cxx                90   0x7fecf556116
> 8   vtkExecutive::CallAlgorithm                          vtkExecutive.cxx                        775  0x7fecf50eb55
> 9   vtkDemandDrivenPipeline::ExecuteData                 vtkDemandDrivenPipeline.cxx             491  0x7fecf50477c
> 10  vtkCompositeDataPipeline::ExecuteData                vtkCompositeDataPipeline.cxx            179  0x7fecf4fc560
> 11  vtkDemandDrivenPipeline::ProcessRequest              vtkDemandDrivenPipeline.cxx             274  0x7fecf503343
> 12  vtkStreamingDemandDrivenPipeline::ProcessRequest     vtkStreamingDemandDrivenPipeline.cxx    328  0x7fecf588f67
> 13  vtkDemandDrivenPipeline::UpdateData                  vtkDemandDrivenPipeline.cxx             444  0x7fecf5042da
> 14  vtkStreamingDemandDrivenPipeline::Update             vtkStreamingDemandDrivenPipeline.cxx    403  0x7fecf589412
> 15  vtkStreamingDemandDrivenPipeline::Update             vtkStreamingDemandDrivenPipeline.cxx    366  0x7fecf58916c
> 16  vtkAlgorithm::Update                                 vtkAlgorithm.cxx                        1457 0x7fecf4e5348
> 17  vtkAlgorithm::Update                                 vtkAlgorithm.cxx                        1451 0x7fecf4e53b3
> 18  vtkCemTestIntersectionFilter::RequestData            vtkCemTestIntersectionFilter.cxx        252  0x7fec0c84e7f
> 19  vtkPolyDataAlgorithm::ProcessRequest                 vtkPolyDataAlgorithm.cxx                90   0x7fecf556116
> 20  vtkExecutive::CallAlgorithm                          vtkExecutive.cxx                        775  0x7fecf50eb55
> ... <More>
>
>
> Note that debug_vtkIntersectionPolyDataFilter is a copy of
> vtkIntersectionPolyDataFilter that I prepared to do my testing and add some
> debug output stuff etc. without interfering with the original code.
>
> I guess that the exception is again a consequence of adding that "cell" in
> GetSingleLoop, but now I must admit that my understanding of the internals
> of these geometric object classes is not yet good enough to see what went
> wrong! The code that needs checking by an expert seems to me the following
>
> vtkIntersectionPolyDataFilter.cxx(1536..1555):
>
>     //There is one line attached to point. This means the intersection has
>
>     //an open intersection loop (i.e. the surfaces are open and one does not
>
>     //completeley intersect the other.
>
>     //Make an artificial triangle loop in this case
>
>     else if (pointCells->GetNumberOfIds() < 2)
>
>     {
>
>       vtkSmartPointer<vtkPolyData> currentpd =
>
>         vtkSmartPointer<vtkPolyData>::New();
>
>       vtkSmartPointer<vtkCellArray> currentcells =
>
>         vtkSmartPointer<vtkCellArray>::New();
>
>       currentcells = pd->GetLines();
>
>       currentcells->InsertNextCell(2);
>
>       currentcells->InsertCellPoint(nextPt);
>
>       currentcells->InsertCellPoint(startPt);
>
>       nextCell = currentcells->GetNumberOfCells()-1;
>
>       currentpd->SetLines(currentcells);
>
>       currentpd->SetPoints(pd->GetPoints());
>
>       pd->DeepCopy(currentpd);
>
>       pd->BuildLinks();
>
>     }
>
>
> My guess is that this code is not yet good enough to properly insert the
> "cell" into pd...
>
> Any idea?
>
> Regards,
> Cornelis
>
> --
> Cornelis Bockem?hl
> Basel, Schweiz
>
> _______________________________________________
> Powered by 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
>
>


-- 
Cory Quammen
Staff R&D Engineer
Kitware, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171022/0fb28587/attachment-0001.html>

From ben.boeckel at kitware.com  Mon Oct 23 10:52:54 2017
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Mon, 23 Oct 2017 10:52:54 -0400
Subject: [Paraview-developers] 100% CPU usage once again
In-Reply-To: <20171011172041.GA6383@megas.kitware.com>
References: <91a3cc1114784287a3842eb6b899256e@ES08AMSNLNT.srn.sandia.gov>
 <babee0ee-2c10-8a41-2843-834aa4294963@itc.rwth-aachen.de>
 <20171011172041.GA6383@megas.kitware.com>
Message-ID: <20171023145254.GA12003@megas.kitware.com>

On Wed, Oct 11, 2017 at 13:20:41 -0400, Ben Boeckel wrote:
> I'm waiting for the dashboards to settle down so I can get a package
> from it for testing.

OK, packages were made. Could you please test again using these
binaries:

    https://open.cdash.org/viewFiles.php?buildid=5109787

Thanks,

--Ben

From kapinos at itc.rwth-aachen.de  Tue Oct 24 11:54:44 2017
From: kapinos at itc.rwth-aachen.de (Paul Kapinos)
Date: Tue, 24 Oct 2017 17:54:44 +0200
Subject: [Paraview-developers] 100% CPU usage once again
In-Reply-To: <20171023145254.GA12003@megas.kitware.com>
References: <91a3cc1114784287a3842eb6b899256e@ES08AMSNLNT.srn.sandia.gov>
 <babee0ee-2c10-8a41-2843-834aa4294963@itc.rwth-aachen.de>
 <20171011172041.GA6383@megas.kitware.com>
 <20171023145254.GA12003@megas.kitware.com>
Message-ID: <850580fc-3c36-641f-a684-389799c19cae@itc.rwth-aachen.de>

On 10/23/2017 04:52 PM, Ben Boeckel wrote:
> On Wed, Oct 11, 2017 at 13:20:41 -0400, Ben Boeckel wrote:
>> I'm waiting for the dashboards to settle down so I can get a package
>> from it for testing.
> 
> OK, packages were made. Could you please test again using these
> binaries:
> 
>     https://open.cdash.org/viewFiles.php?buildid=5109787
> 
> Thanks,
> 
> --Ben
> 

I hereby confirm that the boxed version of 'pvserver' in this version of
ParaView did *not* consume any CPU cycles in busy waiting; the processes sleep
well.
(However I used Intel MPI's 'mpiexec' to wire-up the MPI processes; but I
strongly assume that original 'mpiexec' from MPICH would offer the same behaviour.

Thanks for support! hope to see this feature in next release of ParaView.

Best

Paul Kapinos





-- 
Dipl.-Inform. Paul Kapinos   -   High Performance Computing,
RWTH Aachen University, IT Center
Seffenter Weg 23,  D 52074  Aachen (Germany)
Tel: +49 241/80-24915

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4891 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171024/cdedcff0/attachment.bin>

From ben.boeckel at kitware.com  Tue Oct 24 12:00:27 2017
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Tue, 24 Oct 2017 12:00:27 -0400
Subject: [Paraview-developers] 100% CPU usage once again
In-Reply-To: <850580fc-3c36-641f-a684-389799c19cae@itc.rwth-aachen.de>
References: <91a3cc1114784287a3842eb6b899256e@ES08AMSNLNT.srn.sandia.gov>
 <babee0ee-2c10-8a41-2843-834aa4294963@itc.rwth-aachen.de>
 <20171011172041.GA6383@megas.kitware.com>
 <20171023145254.GA12003@megas.kitware.com>
 <850580fc-3c36-641f-a684-389799c19cae@itc.rwth-aachen.de>
Message-ID: <20171024160027.GA25766@megas.kitware.com>

On Tue, Oct 24, 2017 at 17:54:44 +0200, Paul Kapinos wrote:
> Thanks for support! hope to see this feature in next release of ParaView.

It has been merged and should be in the next release. Thanks for testing.

--Ben

From M.Deij at marin.nl  Wed Oct 25 04:37:07 2017
From: M.Deij at marin.nl (Deij-van Rijswijk, Menno)
Date: Wed, 25 Oct 2017 08:37:07 +0000
Subject: [Paraview-developers] Catalyst error on SaveScreenshot
Message-ID: <9b1aa66568054bbfa1ba33e1e3b904f0@MAR190n2.marin.local>

Hi,

So far I have linked our co-processing interface to the full source build of paraview, which works. In a bid to reduce the memory footprint and binary size I linked to the Catalyst edition ?Base/Enable-Python/Essentials/Extras/Rendering-Base/Rendering-Base-Python?. The memory footprint is indeed reduced, so it seems worthwhile to use a Catalyst edition. When I try to save an image, however, the pipeline that works fine on the executable linked to the full ParaView build gives an error on the executable linked to the Catalyst build:

  File "<string>", line 2, in <module>
  File "coproc.py", line 180, in DoCoProcessing

  File "/home/mdeij/src/Catalyst/build/lib/site-packages/paraview/coprocessing.py", line 271, in WriteImages
    magnification=view.cpMagnification, quality=quality)
  File "/home/mdeij/src/Catalyst/build/lib/site-packages/paraview/simple.py", line 1071, in SaveScreenshot
    return _SaveScreenshotLegacy(filename, view=view, **params)
  File "/home/mdeij/src/Catalyst/build/lib/site-packages/paraview/simple.py", line 997, in _SaveScreenshotLegacy
    ImageQuality=imageQuality)
  File "/home/mdeij/src/Catalyst/build/lib/site-packages/paraview/simple.py", line 1080, in SaveScreenshot
    options = servermanager.misc.SaveScreenshot()
AttributeError: 'PVModule' object has no attribute 'SaveScreenshot'


Any idea why this happens and how to fix it? Am I using the right Edition(s)?

Thanks and best wishes,


Menno Deij ? van Rijswijk


dr. ir. Menno A. Deij-van Rijswijk | Researcher / Software Engineer | MARIN Software Group
MARIN | T +31 317 49 35 06 | M.Deij at marin.nl<mailto:M.Deij at marin.nl> | www.marin.nl<http://www.marin.nl>

[LinkedIn]<https://www.linkedin.com/company/marin> [YouTube] <http://www.youtube.com/marinmultimedia>  [Twitter] <https://twitter.com/MARIN_nieuws>  [Facebook] <https://www.facebook.com/marin.wageningen>
MARIN news: NAV 2018 Call for papers<http://www.marin.nl/web/News/News-items/NAV-2018-Call-for-papers.htm>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171025/62ff08fe/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image3eb543.PNG
Type: image/png
Size: 293 bytes
Desc: image3eb543.PNG
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171025/62ff08fe/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image38b4d8.PNG
Type: image/png
Size: 331 bytes
Desc: image38b4d8.PNG
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171025/62ff08fe/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image4af09f.PNG
Type: image/png
Size: 333 bytes
Desc: image4af09f.PNG
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171025/62ff08fe/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imageaa4c34.PNG
Type: image/png
Size: 253 bytes
Desc: imageaa4c34.PNG
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171025/62ff08fe/attachment-0003.png>

From utkarsh.ayachit at kitware.com  Wed Oct 25 08:02:23 2017
From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit)
Date: Wed, 25 Oct 2017 08:02:23 -0400
Subject: [Paraview-developers] Catalyst error on SaveScreenshot
In-Reply-To: <9b1aa66568054bbfa1ba33e1e3b904f0@MAR190n2.marin.local>
References: <9b1aa66568054bbfa1ba33e1e3b904f0@MAR190n2.marin.local>
Message-ID: <CADHSJjA_qY_A=kFGnBP9G+BH7F3SmAU1ERKTur4KmCQb_uNayw@mail.gmail.com>

This is indeed a bug. I suspect the Catalyst edition is missing the proxies
used to save screenshot.

I've reported an issue here:
https://gitlab.kitware.com/paraview/paraview/issues/17794

I can put together a quick fix once I get to work.

Utkarsh

On Wed, Oct 25, 2017 at 4:37 AM, Deij-van Rijswijk, Menno <M.Deij at marin.nl>
wrote:

> Hi,
>
>
>
> So far I have linked our co-processing interface to the full source build
> of paraview, which works. In a bid to reduce the memory footprint and
> binary size I linked to the Catalyst edition ?Base/Enable-Python/
> Essentials/Extras/Rendering-Base/Rendering-Base-Python?. The memory
> footprint is indeed reduced, so it seems worthwhile to use a Catalyst
> edition. When I try to save an image, however, the pipeline that works fine
> on the executable linked to the full ParaView build gives an error on the
> executable linked to the Catalyst build:
>
>
>
>   File "<string>", line 2, in <module>
>
>   File "coproc.py", line 180, in DoCoProcessing
>
>
>
>   File "/home/mdeij/src/Catalyst/build/lib/site-packages/paraview/coprocessing.py",
> line 271, in WriteImages
>
>     magnification=view.cpMagnification, quality=quality)
>
>   File "/home/mdeij/src/Catalyst/build/lib/site-packages/paraview/simple.py",
> line 1071, in SaveScreenshot
>
>     return _SaveScreenshotLegacy(filename, view=view, **params)
>
>   File "/home/mdeij/src/Catalyst/build/lib/site-packages/paraview/simple.py",
> line 997, in _SaveScreenshotLegacy
>
>     ImageQuality=imageQuality)
>
>   File "/home/mdeij/src/Catalyst/build/lib/site-packages/paraview/simple.py",
> line 1080, in SaveScreenshot
>
>     options = servermanager.misc.SaveScreenshot()
>
> AttributeError: 'PVModule' object has no attribute 'SaveScreenshot'
>
>
>
>
>
> Any idea why this happens and how to fix it? Am I using the right
> Edition(s)?
>
>
>
> Thanks and best wishes,
>
>
>
>
>
> Menno Deij ? van Rijswijk
>
>
>
> dr. ir. Menno A. Deij-van Rijswijk | Researcher / Software Engineer | MARIN
> Software Group
> MARIN | T +31 317 49 35 06 <+31%20317%20493%20506> | M.Deij at marin.nl |
> www.marin.nl
>
> [image: LinkedIn] <https://www.linkedin.com/company/marin> [image:
> YouTube] <http://www.youtube.com/marinmultimedia> [image: Twitter]
> <https://twitter.com/MARIN_nieuws> [image: Facebook]
> <https://www.facebook.com/marin.wageningen>
> MARIN news: NAV 2018 Call for papers
> <http://www.marin.nl/web/News/News-items/NAV-2018-Call-for-papers.htm>
>
>
> _______________________________________________
> Powered by 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/20171025/de420d77/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imageaa4c34.PNG
Type: image/png
Size: 253 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171025/de420d77/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image38b4d8.PNG
Type: image/png
Size: 331 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171025/de420d77/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image4af09f.PNG
Type: image/png
Size: 333 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171025/de420d77/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image3eb543.PNG
Type: image/png
Size: 293 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171025/de420d77/attachment-0007.png>

From utkarsh.ayachit at kitware.com  Wed Oct 25 10:52:00 2017
From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit)
Date: Wed, 25 Oct 2017 10:52:00 -0400
Subject: [Paraview-developers] Catalyst error on SaveScreenshot
In-Reply-To: <CADHSJjA_qY_A=kFGnBP9G+BH7F3SmAU1ERKTur4KmCQb_uNayw@mail.gmail.com>
References: <9b1aa66568054bbfa1ba33e1e3b904f0@MAR190n2.marin.local>
 <CADHSJjA_qY_A=kFGnBP9G+BH7F3SmAU1ERKTur4KmCQb_uNayw@mail.gmail.com>
Message-ID: <CADHSJjBKuQ-Vsyi_nDOUZ-gdDou_h0VEY0=nNWnc+2N6NqEZug@mail.gmail.com>

Menno,

Here's a fix for the catalyst edition generation code:

  https://gitlab.kitware.com/paraview/paraview/merge_requests/1989

Are you generating your own editions? Let me know if you want me to
pregenerate an updated edition with this fix for you.

Utkarsh

On Wed, Oct 25, 2017 at 8:02 AM, Utkarsh Ayachit <
utkarsh.ayachit at kitware.com> wrote:

> This is indeed a bug. I suspect the Catalyst edition is missing the
> proxies used to save screenshot.
>
> I've reported an issue here: https://gitlab.kitware.
> com/paraview/paraview/issues/17794
>
> I can put together a quick fix once I get to work.
>
> Utkarsh
>
> On Wed, Oct 25, 2017 at 4:37 AM, Deij-van Rijswijk, Menno <M.Deij at marin.nl
> > wrote:
>
>> Hi,
>>
>>
>>
>> So far I have linked our co-processing interface to the full source build
>> of paraview, which works. In a bid to reduce the memory footprint and
>> binary size I linked to the Catalyst edition ?Base/Enable-Python/Essentials
>> /Extras/Rendering-Base/Rendering-Base-Python?. The memory footprint is
>> indeed reduced, so it seems worthwhile to use a Catalyst edition. When I
>> try to save an image, however, the pipeline that works fine on the
>> executable linked to the full ParaView build gives an error on the
>> executable linked to the Catalyst build:
>>
>>
>>
>>   File "<string>", line 2, in <module>
>>
>>   File "coproc.py", line 180, in DoCoProcessing
>>
>>
>>
>>   File "/home/mdeij/src/Catalyst/build/lib/site-packages/paraview/coprocessing.py",
>> line 271, in WriteImages
>>
>>     magnification=view.cpMagnification, quality=quality)
>>
>>   File "/home/mdeij/src/Catalyst/build/lib/site-packages/paraview/simple.py",
>> line 1071, in SaveScreenshot
>>
>>     return _SaveScreenshotLegacy(filename, view=view, **params)
>>
>>   File "/home/mdeij/src/Catalyst/build/lib/site-packages/paraview/simple.py",
>> line 997, in _SaveScreenshotLegacy
>>
>>     ImageQuality=imageQuality)
>>
>>   File "/home/mdeij/src/Catalyst/build/lib/site-packages/paraview/simple.py",
>> line 1080, in SaveScreenshot
>>
>>     options = servermanager.misc.SaveScreenshot()
>>
>> AttributeError: 'PVModule' object has no attribute 'SaveScreenshot'
>>
>>
>>
>>
>>
>> Any idea why this happens and how to fix it? Am I using the right
>> Edition(s)?
>>
>>
>>
>> Thanks and best wishes,
>>
>>
>>
>>
>>
>> Menno Deij ? van Rijswijk
>>
>>
>>
>> dr. ir. Menno A. Deij-van Rijswijk | Researcher / Software Engineer | MARIN
>> Software Group
>> MARIN | T +31 317 49 35 06 <+31%20317%20493%20506> | M.Deij at marin.nl |
>> www.marin.nl
>>
>> [image: LinkedIn] <https://www.linkedin.com/company/marin> [image:
>> YouTube] <http://www.youtube.com/marinmultimedia> [image: Twitter]
>> <https://twitter.com/MARIN_nieuws> [image: Facebook]
>> <https://www.facebook.com/marin.wageningen>
>> MARIN news: NAV 2018 Call for papers
>> <http://www.marin.nl/web/News/News-items/NAV-2018-Call-for-papers.htm>
>>
>>
>> _______________________________________________
>> Powered by 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/20171025/75b8c74b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image38b4d8.PNG
Type: image/png
Size: 331 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171025/75b8c74b/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image3eb543.PNG
Type: image/png
Size: 293 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171025/75b8c74b/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imageaa4c34.PNG
Type: image/png
Size: 253 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171025/75b8c74b/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image4af09f.PNG
Type: image/png
Size: 333 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171025/75b8c74b/attachment-0003.png>

From M.Deij at marin.nl  Thu Oct 26 03:19:41 2017
From: M.Deij at marin.nl (Deij-van Rijswijk, Menno)
Date: Thu, 26 Oct 2017 07:19:41 +0000
Subject: [Paraview-developers] Catalyst error on SaveScreenshot
In-Reply-To: <CADHSJjBKuQ-Vsyi_nDOUZ-gdDou_h0VEY0=nNWnc+2N6NqEZug@mail.gmail.com>
References: <9b1aa66568054bbfa1ba33e1e3b904f0@MAR190n2.marin.local>
 <CADHSJjA_qY_A=kFGnBP9G+BH7F3SmAU1ERKTur4KmCQb_uNayw@mail.gmail.com>
 <CADHSJjBKuQ-Vsyi_nDOUZ-gdDou_h0VEY0=nNWnc+2N6NqEZug@mail.gmail.com>
Message-ID: <f94bbd7240f6499d84d5056af2dafe12@MAR190n2.marin.local>

Hi Utkarsh,

Thanks for your quick reply; I am not generating my own editions but with your fix I can easily patch the catalyze.pi and json manifest files.

Best wishes,


Menno Deij ? van Rijswijk



dr. ir. Menno A. Deij-van Rijswijk | Researcher / Software Engineer | MARIN Software Group
MARIN | T +31 317 49 35 06 | M.Deij at marin.nl<mailto:M.Deij at marin.nl> | www.marin.nl<http://www.marin.nl>

[LinkedIn]<https://www.linkedin.com/company/marin> [YouTube] <http://www.youtube.com/marinmultimedia>  [Twitter] <https://twitter.com/MARIN_nieuws>  [Facebook] <https://www.facebook.com/marin.wageningen>
MARIN news: NAV 2018 Call for papers<http://www.marin.nl/web/News/News-items/NAV-2018-Call-for-papers.htm>
From: Utkarsh Ayachit [mailto:utkarsh.ayachit at kitware.com]
Sent: Wednesday, October 25, 2017 4:52 PM
To: Deij-van Rijswijk, Menno
Cc: paraview-developers at paraview.org
Subject: Re: [Paraview-developers] Catalyst error on SaveScreenshot

Menno,

Here's a fix for the catalyst edition generation code:

  https://gitlab.kitware.com/paraview/paraview/merge_requests/1989

Are you generating your own editions? Let me know if you want me to pregenerate an updated edition with this fix for you.

Utkarsh

On Wed, Oct 25, 2017 at 8:02 AM, Utkarsh Ayachit <utkarsh.ayachit at kitware.com<mailto:utkarsh.ayachit at kitware.com>> wrote:
This is indeed a bug. I suspect the Catalyst edition is missing the proxies used to save screenshot.

I've reported an issue here: https://gitlab.kitware.com/paraview/paraview/issues/17794

I can put together a quick fix once I get to work.

Utkarsh

On Wed, Oct 25, 2017 at 4:37 AM, Deij-van Rijswijk, Menno <M.Deij at marin.nl<mailto:M.Deij at marin.nl>> wrote:
Hi,

So far I have linked our co-processing interface to the full source build of paraview, which works. In a bid to reduce the memory footprint and binary size I linked to the Catalyst edition ?Base/Enable-Python/Essentials/Extras/Rendering-Base/Rendering-Base-Python?. The memory footprint is indeed reduced, so it seems worthwhile to use a Catalyst edition. When I try to save an image, however, the pipeline that works fine on the executable linked to the full ParaView build gives an error on the executable linked to the Catalyst build:

  File "<string>", line 2, in <module>
  File "coproc.py", line 180, in DoCoProcessing

  File "/home/mdeij/src/Catalyst/build/lib/site-packages/paraview/coprocessing.py", line 271, in WriteImages
    magnification=view.cpMagnification, quality=quality)
  File "/home/mdeij/src/Catalyst/build/lib/site-packages/paraview/simple.py", line 1071, in SaveScreenshot
    return _SaveScreenshotLegacy(filename, view=view, **params)
  File "/home/mdeij/src/Catalyst/build/lib/site-packages/paraview/simple.py", line 997, in _SaveScreenshotLegacy
    ImageQuality=imageQuality)
  File "/home/mdeij/src/Catalyst/build/lib/site-packages/paraview/simple.py", line 1080, in SaveScreenshot
    options = servermanager.misc.SaveScreenshot()
AttributeError: 'PVModule' object has no attribute 'SaveScreenshot'


Any idea why this happens and how to fix it? Am I using the right Edition(s)?

Thanks and best wishes,


Menno Deij ? van Rijswijk


dr. ir. Menno A. Deij-van Rijswijk | Researcher / Software Engineer | MARIN Software Group
MARIN | T +31 317 49 35 06<tel:+31%20317%20493%20506> | M.Deij at marin.nl<mailto:M.Deij at marin.nl> | www.marin.nl<http://www.marin.nl>

[LinkedIn]<https://www.linkedin.com/company/marin> [YouTube] <http://www.youtube.com/marinmultimedia>  [Twitter] <https://twitter.com/MARIN_nieuws>  [Facebook] <https://www.facebook.com/marin.wageningen>
MARIN news: NAV 2018 Call for papers<http://www.marin.nl/web/News/News-items/NAV-2018-Call-for-papers.htm>

_______________________________________________
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/20171026/9916b7e1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 293 bytes
Desc: image001.png
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171026/9916b7e1/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 331 bytes
Desc: image002.png
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171026/9916b7e1/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 333 bytes
Desc: image003.png
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171026/9916b7e1/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 253 bytes
Desc: image004.png
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171026/9916b7e1/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imageecfe1e.PNG
Type: image/png
Size: 293 bytes
Desc: imageecfe1e.PNG
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171026/9916b7e1/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imagedf8ee9.PNG
Type: image/png
Size: 331 bytes
Desc: imagedf8ee9.PNG
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171026/9916b7e1/attachment-0013.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image2ec703.PNG
Type: image/png
Size: 333 bytes
Desc: image2ec703.PNG
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171026/9916b7e1/attachment-0014.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imagea7c2a9.PNG
Type: image/png
Size: 253 bytes
Desc: imagea7c2a9.PNG
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171026/9916b7e1/attachment-0015.png>

From M.Deij at marin.nl  Fri Oct 27 06:53:47 2017
From: M.Deij at marin.nl (Deij-van Rijswijk, Menno)
Date: Fri, 27 Oct 2017 10:53:47 +0000
Subject: [Paraview-developers] Problem with vtkMappedUnstructuredGrid with
 VTK_POLYHEDRON cells + writing to XML
Message-ID: <9d93809cfe124c8bb73f46eb36d8961a@MAR190n2.marin.local>

Hi,

I have a mapped unstructured grid which is, in essence, a mapping onto our simulation data structures. It works well for all intents and purposes so far, but now I find that when I write this unstructured grid to XML using vtkXMLPUnstructuredGridWriter, that upon reading the files in ParaView, the VTK_POLYHEDRON cells are not read correctly and are showing as holes in ParaView. Trying to select these cells using the Find Data dialog results in a crash of ParaView.

Looking at the few examples of polyhedral cells in the .vtu file format that are out there, it seems that the ?faces? and ?faceoffsets? arrays need to be filled to support polyhedral cells. However, for a mapped unstructured grid a vtkCellIterator is used during writing, and it looks like the ?faces? and ?faceoffsets? arrays are not written (see vtkXMLUnstructuredDataWriter::WriteCellsInline (around line 567 where it says ?Faces are not supported by this method?) when a cell iterator is used.

Is this correct? Or am I missing something here? If my analysis is correct, I will try and see if I can add the support for Faces and FaceOffsets in the writer when using a cell iterator for polyhedral cells.

Best wishes,


Menno Deij ? van Rijswijk




dr. ir. Menno A. Deij-van Rijswijk | Researcher / Software Engineer | MARIN Software Group
MARIN | T +31 317 49 35 06 | M.Deij at marin.nl<mailto:M.Deij at marin.nl> | www.marin.nl<http://www.marin.nl>

[LinkedIn]<https://www.linkedin.com/company/marin> [YouTube] <http://www.youtube.com/marinmultimedia>  [Twitter] <https://twitter.com/MARIN_nieuws>  [Facebook] <https://www.facebook.com/marin.wageningen>
MARIN news: Verification and validation study of CFD simulations for the flow around a tug<http://www.marin.nl/web/News/News-items/Verification-and-validation-study-of-CFD-simulations-for-the-flow-around-a-tug.htm>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171027/fbf00c0b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image44ff26.PNG
Type: image/png
Size: 293 bytes
Desc: image44ff26.PNG
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171027/fbf00c0b/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imagef31938.PNG
Type: image/png
Size: 331 bytes
Desc: imagef31938.PNG
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171027/fbf00c0b/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imageb18929.PNG
Type: image/png
Size: 333 bytes
Desc: imageb18929.PNG
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171027/fbf00c0b/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imagea653de.PNG
Type: image/png
Size: 253 bytes
Desc: imagea653de.PNG
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171027/fbf00c0b/attachment-0003.png>

From allison.vacanti at kitware.com  Fri Oct 27 10:00:12 2017
From: allison.vacanti at kitware.com (Allie Vacanti)
Date: Fri, 27 Oct 2017 10:00:12 -0400
Subject: [Paraview-developers] Problem with vtkMappedUnstructuredGrid
 with VTK_POLYHEDRON cells + writing to XML
In-Reply-To: <9d93809cfe124c8bb73f46eb36d8961a@MAR190n2.marin.local>
References: <9d93809cfe124c8bb73f46eb36d8961a@MAR190n2.marin.local>
Message-ID: <CA+=e1ovnD6pZ9wsfjCb0ydkHYAhuiXOLwdmvYPnvVxOHz5PpCQ@mail.gmail.com>

On Fri, Oct 27, 2017 at 6:53 AM, Deij-van Rijswijk, Menno <M.Deij at marin.nl>
wrote:

> Is this correct? Or am I missing something here? If my analysis is
> correct, I will try and see if I can add the support for Faces and
> FaceOffsets in the writer when using a cell iterator for polyhedral cells.
>

You are correct, it looks like that functionality is missing for the cell
iterator overload. Feel free to make a merge request and ping me on it if
you make a patch.

Allison
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171027/a6e31961/attachment.html>

From sur.chiranjib at gmail.com  Fri Oct 27 14:21:00 2017
From: sur.chiranjib at gmail.com (Chiranjib Sur)
Date: Fri, 27 Oct 2017 23:51:00 +0530
Subject: [Paraview-developers] [vtkusers] Solidify vtkPolyData
In-Reply-To: <1507156428979-0.post@n5.nabble.com>
References: <1507156428979-0.post@n5.nabble.com>
Message-ID: <CAJk8dSCrUWApuA=L0XVF9Tf1bKt9q1AfiDdUOP3MoWNBm3ieAw@mail.gmail.com>

Hi,
have you tried playing with ISOvalue?

This discussion thread might help you :
https://stackoverflow.com/questions/43682388/thick-surface-with-vtk

I also vote for having such a filter embedded in VTK. This will be simply
great..

I am wondering, if something like this exists in ParaView (posting this
thread to PV mailing list too)


Thanks and regards,
Chiranjib

On Thu, Oct 5, 2017 at 4:03 AM, sebastian_a <seb.an at icloud.com> wrote:

> Hello everyone,
>
> does vtk include a similar filter or is there a method like the Solidify
> Modifier in Blender ( link
> <https://docs.blender.org/manual/en/dev/modeling/
> modifiers/generate/solidify.html>
> )?
>
> Basically I have a non watertight vtkPolyData containing faces which I want
> to solidify by adding opposite faces on their backs.
>
> Thanks a lot, Sebastian
>
>
>
> --
> Sent from: http://vtk.1045678.n5.nabble.com/VTK-Users-f1224199.html
> _______________________________________________
> 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 VTK FAQ at:
> http://www.vtk.org/Wiki/VTK_FAQ
>
> Search the list archives at: http://markmail.org/search/?q=vtkusers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtkusers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171027/21ed3912/attachment.html>

From M.Deij at marin.nl  Mon Oct 30 09:37:16 2017
From: M.Deij at marin.nl (Deij-van Rijswijk, Menno)
Date: Mon, 30 Oct 2017 13:37:16 +0000
Subject: [Paraview-developers] Problem with vtkMappedUnstructuredGrid
 with VTK_POLYHEDRON cells + writing to XML
In-Reply-To: <CA+=e1ovnD6pZ9wsfjCb0ydkHYAhuiXOLwdmvYPnvVxOHz5PpCQ@mail.gmail.com>
References: <9d93809cfe124c8bb73f46eb36d8961a@MAR190n2.marin.local>
 <CA+=e1ovnD6pZ9wsfjCb0ydkHYAhuiXOLwdmvYPnvVxOHz5PpCQ@mail.gmail.com>
Message-ID: <9bfbf761a0e94ff4bc93d8f61c7e7336@MAR190n2.marin.local>

Hi Allison,

Thank you for confirming my suspicions. I have created a merge request to address this issue at https://gitlab.kitware.com/vtk/vtk/merge_requests/3513

Best wishes,


Menno Deij ? van Rijswijk



dr. ir. Menno A. Deij-van Rijswijk | Researcher / Software Engineer | MARIN Software Group
MARIN | T +31 317 49 35 06 | M.Deij at marin.nl<mailto:M.Deij at marin.nl> | www.marin.nl<http://www.marin.nl>

[LinkedIn]<https://www.linkedin.com/company/marin> [YouTube] <http://www.youtube.com/marinmultimedia>  [Twitter] <https://twitter.com/MARIN_nieuws>  [Facebook] <https://www.facebook.com/marin.wageningen>
MARIN news: Iterative errors in unsteady flow simulations: are they really negligible?<http://www.marin.nl/web/News/News-items/Iterative-errors-in-unsteady-flow-simulations-are-they-really-negligible-1.htm>
From: Allie Vacanti [mailto:allison.vacanti at kitware.com]
Sent: Friday, October 27, 2017 4:00 PM
To: Deij-van Rijswijk, Menno
Cc: paraview-developers at paraview.org
Subject: Re: [Paraview-developers] Problem with vtkMappedUnstructuredGrid with VTK_POLYHEDRON cells + writing to XML

On Fri, Oct 27, 2017 at 6:53 AM, Deij-van Rijswijk, Menno <M.Deij at marin.nl<mailto:M.Deij at marin.nl>> wrote:
Is this correct? Or am I missing something here? If my analysis is correct, I will try and see if I can add the support for Faces and FaceOffsets in the writer when using a cell iterator for polyhedral cells.

You are correct, it looks like that functionality is missing for the cell iterator overload. Feel free to make a merge request and ping me on it if you make a patch.

Allison


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171030/3230e958/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image17e09c.PNG
Type: image/png
Size: 293 bytes
Desc: image17e09c.PNG
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171030/3230e958/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imageb49899.PNG
Type: image/png
Size: 331 bytes
Desc: imageb49899.PNG
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171030/3230e958/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image8ebd99.PNG
Type: image/png
Size: 333 bytes
Desc: image8ebd99.PNG
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171030/3230e958/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imagefde119.PNG
Type: image/png
Size: 253 bytes
Desc: imagefde119.PNG
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20171030/3230e958/attachment-0003.png>