From ben.boeckel at kitware.com Tue May 2 16:07:50 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 2 May 2017 16:07:50 -0400 Subject: [Paraview-developers] New fixup tag on the superbuild Message-ID: <20170502200750.GC2418@megas.kitware.com> Hi, Following 5.3.0, the superbuild received some fixes which affect 5.3.0. The superbuild repository now has a v5.3.0-1 tag which contains these fixes. --Ben From Axel.Gerstenberger at Rolls-Royce.com Thu May 4 12:05:08 2017 From: Axel.Gerstenberger at Rolls-Royce.com (Gerstenberger, Axel) Date: Thu, 4 May 2017 16:05:08 +0000 Subject: [Paraview-developers] Calculator parsing bug? Message-ID: <7BA6875C23078842B4E4B47B0D95450D9D8C0C30@GBDOXPR-MBX002.Rolls-Royce.Local> Dear developers, We found an issue with the Paraview Calculator in that it seems to parse variables wrong that start with the same name as a build in function like abs or sin. Moreover, it only happens, if such variable is followed by an opening bracket. This behaviour is present in PV 5.2 and all the way back to PV 3.14. Can you reproduce this and is this a known issue? To try it, just run attached script using pvpython. Regards, Axel Rolls-Royce Deutschland Ltd & Co KG Sitz/Registered Office: Blankenfelde-Mahlow, Deutschland, Registergericht/Court of Register: Amtsgericht Potsdam, HRA 2731 P, Pers?nlich haftende Gesellschafterin/General Partner: Rolls-Royce General Partner Limited, Sitz/Registered Office: Derby, United Kingdom, Register: Registry of Companies Wales and England, 4066556, Directors/Gesch?ftsf?hrer: Paul O?Neil, Alastair McIntosh, Nicole Fehr, Dr. Holger Cartsburg Confidentiality Notice: This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. The data contained in, or attached to, this e-mail, may contain confidential information. If you have received it in error you should notify the sender immediately by reply e-mail, delete the message from your system and contact +44 (0) 3301235850 (Security Operations Centre) if you need assistance. Please do not copy it for any purpose, or disclose its contents to any other person. An e-mail response to this address may be subject to interception or monitoring for operational reasons or for lawful business practices. (c) 2017 Rolls-Royce plc Registered office: 62 Buckingham Gate, London SW1E 6AT Company number: 1003142. Registered in England. -------------- next part -------------- A non-text attachment was scrubbed... Name: TestVTKCalculatorParsingBugForAbsSinTanPlusBrackets.py Type: application/octet-stream Size: 7689 bytes Desc: TestVTKCalculatorParsingBugForAbsSinTanPlusBrackets.py URL: From andy.bauer at kitware.com Thu May 4 12:20:19 2017 From: andy.bauer at kitware.com (Andy Bauer) Date: Thu, 4 May 2017 12:20:19 -0400 Subject: [Paraview-developers] Calculator parsing bug? In-Reply-To: <7BA6875C23078842B4E4B47B0D95450D9D8C0C30@GBDOXPR-MBX002.Rolls-Royce.Local> References: <7BA6875C23078842B4E4B47B0D95450D9D8C0C30@GBDOXPR-MBX002.Rolls-Royce.Local> Message-ID: Hi Axel, This should now be fixed in PV master. I ran pvpython with your attached script from master as of today and it passed whereas it failed (as expected) for PV 5.3. Cheers, Andy On Thu, May 4, 2017 at 12:05 PM, Gerstenberger, Axel < Axel.Gerstenberger at rolls-royce.com> wrote: > Dear developers, > > We found an issue with the Paraview Calculator in that it seems to parse > variables wrong that start with the same name as a build in function like > abs or sin. Moreover, it only happens, if such variable is followed by an > opening bracket. This behaviour is present in PV 5.2 and all the way back > to PV 3.14. > > Can you reproduce this and is this a known issue? > > To try it, just run attached script using pvpython. > > Regards, > Axel > > > > Rolls-Royce Deutschland Ltd & Co KG Sitz/Registered Office: > Blankenfelde-Mahlow, Deutschland, Registergericht/Court of Register: > Amtsgericht Potsdam, HRA 2731 P, Pers?nlich haftende > Gesellschafterin/General Partner: Rolls-Royce General Partner Limited, > Sitz/Registered Office: Derby, United Kingdom, Register: Registry of > Companies Wales and England, 4066556, Directors/Gesch?ftsf?hrer: Paul > O?Neil, Alastair McIntosh, Nicole Fehr, Dr. Holger Cartsburg > Confidentiality Notice: This email and any attachments are confidential to > the intended recipient and may also be privileged. If you are not the > intended recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or distribute > its contents to any other person. > The data contained in, or attached to, this e-mail, may contain > confidential information. If you have received it in error you should > notify the sender immediately by reply e-mail, delete the message from your > system and contact +44 (0) 3301235850 (Security Operations Centre) if you > need assistance. Please do not copy it for any purpose, or disclose its > contents to any other person. > > An e-mail response to this address may be subject to interception or > monitoring for operational reasons or for lawful business practices. > > (c) 2017 Rolls-Royce plc > > Registered office: 62 Buckingham Gate, London SW1E 6AT Company number: > 1003142. Registered in England. > > _______________________________________________ > 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: From cory.quammen at kitware.com Fri May 5 16:31:36 2017 From: cory.quammen at kitware.com (Cory Quammen) Date: Fri, 5 May 2017 16:31:36 -0400 Subject: [Paraview-developers] ParaView 5.4.0-RC1 tagged Message-ID: Dear ParaView developers, ParaView 5.4.0-RC1 has been tagged (tag v5.4.0-RC1). Binaries may tag a while to build as the buildbot test machines that generate the binaries are quite backlogged at the moment. It would help speed up the build process if we could avoid testing other merge requests until the binaries are built. Note that v5.4.0-RC1 has not been merged to the master branch just yet. I will do that after the binaries are built. Thank you, Cory -- Cory Quammen Staff R&D Engineer Kitware, Inc. From adrian.harwood at manchester.ac.uk Sat May 6 03:59:00 2017 From: adrian.harwood at manchester.ac.uk (Adrian Harwood) Date: Sat, 6 May 2017 07:59:00 +0000 Subject: [Paraview-developers] vtkPVVTKExtensionsDefaultModule Message-ID: <0DE2A2AC7B71EC4D86C4D089EB9012E201C0997ACF@MBXP07.ds.man.ac.uk> Hi, I already have the binary of Paraview installed on my Windows system. However, I'm trying to use the vtkCleanToGrid extension from my own post-processor so downloaded the source. The headers require the generated header vtkPVVTKExtensionsDefaultModule.h to resolve the macros. I seem to remember these files being generated during the build process but CMake is complaining about CMake Error at C:/Program Files/CMake/share/cmake-3.6/Modules/FindQt4.cmake:1328 (message): Found unsuitable Qt version "" from NOTFOUND, this code requires Qt 4.x Call Stack (most recent call first): VTK/GUISupport/Qt/CMakeLists.txt:88 (find_package) Despite me having Qt 5.6.2 installed. Since all I want is the module header I was wondering if there was a way of getting this file from somewhere else rather than me messing around with building an application I already have pre-built. Is this file system-dependent or can someone send me their version to use? Thanks, Adrian -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Sat May 6 12:23:17 2017 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Sat, 6 May 2017 12:23:17 -0400 Subject: [Paraview-developers] vtkPVVTKExtensionsDefaultModule In-Reply-To: <0DE2A2AC7B71EC4D86C4D089EB9012E201C0997ACF@MBXP07.ds.man.ac.uk> References: <0DE2A2AC7B71EC4D86C4D089EB9012E201C0997ACF@MBXP07.ds.man.ac.uk> Message-ID: Set `PARAVIEW_QT_VERSION:STRING=5` CMake flag. It's set to 4 by default. Utkarsh On Sat, May 6, 2017 at 3:59 AM, Adrian Harwood wrote: > Hi, > > > > I already have the binary of Paraview installed on my Windows system. > However, I?m trying to use the vtkCleanToGrid extension from my own > post-processor so downloaded the source. The headers require the generated > header vtkPVVTKExtensionsDefaultModule.h to resolve the macros. I seem to > remember these files being generated during the build process but CMake is > complaining about > > > > CMake Error at C:/Program > Files/CMake/share/cmake-3.6/Modules/FindQt4.cmake:1328 (message): > > Found unsuitable Qt version "" from NOTFOUND, this code requires Qt 4.x > > Call Stack (most recent call first): > > VTK/GUISupport/Qt/CMakeLists.txt:88 (find_package) > > > > Despite me having Qt 5.6.2 installed. Since all I want is the module header > I was wondering if there was a way of getting this file from somewhere else > rather than me messing around with building an application I already have > pre-built. > > > > Is this file system-dependent or can someone send me their version to use? > > > > Thanks, > > Adrian > > > > > _______________________________________________ > 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 > From cornelis.bockemuehl at gmail.com Mon May 8 05:25:17 2017 From: cornelis.bockemuehl at gmail.com (=?UTF-8?Q?Cornelis_Bockem=C3=BChl?=) Date: Mon, 8 May 2017 11:25:17 +0200 Subject: [Paraview-developers] Is there a "no view" hint for filters? Message-ID: Hello all, Writing a filter with 3 output ports, I would like to achieve a behaviour that only the first of the ports will show in some 3D render view by default. The second and third are actually table data which the user may want to see or not. With this it makes sense to have them still as output port, but without a default representation. The user may then open a spreadsheet view and choose among the output ports he wants to see in numeric form. I know that in ther server manager xml you can put "hints" for "Representation" or "RepresentationType", e.g. What I would like to use would be something like this: Is there such a thing available? I was trying and searching the source code, but did not find an indication. Regards, Cornelis -- Cornelis Bockem?hl Basel, Schweiz -------------- next part -------------- An HTML attachment was scrubbed... URL: From cory.quammen at kitware.com Mon May 8 09:27:02 2017 From: cory.quammen at kitware.com (Cory Quammen) Date: Mon, 8 May 2017 09:27:02 -0400 Subject: [Paraview-developers] Is there a "no view" hint for filters? In-Reply-To: References: Message-ID: Cornelis, That's not explicitly as far as I know, but what happens if you try setting the view to "none"? My guess would be that you get a new view with whatever your default view type happens to be (usually RenderView). Best, Cory On Mon, May 8, 2017 at 5:25 AM, Cornelis Bockem?hl wrote: > Hello all, > > Writing a filter with 3 output ports, I would like to achieve a behaviour > that only the first of the ports will show in some 3D render view by > default. The second and third are actually table data which the user may > want to see or not. > > With this it makes sense to have them still as output port, but without a > default representation. The user may then open a spreadsheet view and choose > among the output ports he wants to see in numeric form. > > I know that in ther server manager xml you can put "hints" for > "Representation" or "RepresentationType", e.g. > > > > What I would like to use would be something like this: > > > > Is there such a thing available? I was trying and searching the source code, > but did not find an indication. > > 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. From utkarsh.ayachit at kitware.com Mon May 8 09:42:38 2017 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Mon, 8 May 2017 09:42:38 -0400 Subject: [Paraview-developers] Is there a "no view" hint for filters? In-Reply-To: References: Message-ID: Cornelis, As Cory said, it's not supported currently, but should be easy to support. If you want to create an MR, I can provide some hints. The starting point would be [1] and [2]. Making [2] handle "None", rather than trying to create representation called "None" would get us most of way there, I'd think. Utkarsh [1] https://gitlab.kitware.com/paraview/paraview/blob/master/ParaViewCore/ServerManager/Rendering/vtkSMViewProxy.cxx#L353-387 [2] https://gitlab.kitware.com/paraview/paraview/blob/master/ParaViewCore/ServerManager/Rendering/vtkSMViewProxy.cxx#L332-349 On Mon, May 8, 2017 at 9:27 AM, Cory Quammen wrote: > Cornelis, > > That's not explicitly as far as I know, but what happens if you try > setting the view to "none"? My guess would be that you get a new view > with whatever your default view type happens to be (usually > RenderView). > > Best, > Cory > > On Mon, May 8, 2017 at 5:25 AM, Cornelis Bockem?hl > wrote: >> Hello all, >> >> Writing a filter with 3 output ports, I would like to achieve a behaviour >> that only the first of the ports will show in some 3D render view by >> default. The second and third are actually table data which the user may >> want to see or not. >> >> With this it makes sense to have them still as output port, but without a >> default representation. The user may then open a spreadsheet view and choose >> among the output ports he wants to see in numeric form. >> >> I know that in ther server manager xml you can put "hints" for >> "Representation" or "RepresentationType", e.g. >> >> >> >> What I would like to use would be something like this: >> >> >> >> Is there such a thing available? I was trying and searching the source code, >> but did not find an indication. >> >> 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. > _______________________________________________ > 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 From cory.quammen at kitware.com Mon May 8 11:18:03 2017 From: cory.quammen at kitware.com (Cory Quammen) Date: Mon, 8 May 2017 11:18:03 -0400 Subject: [Paraview-developers] ParaView 5.4.0 Release Candidate 1 binaries are available for download Message-ID: On behalf of the ParaView development community, I am happy to announce that binaries and source code for ParaView 5.4.0-RC1 are available to download from http://www.paraview.org/download/ Please let us know if you run into any problems with this release candidate. Thank you, Cory -- Cory Quammen Staff R&D Engineer Kitware, Inc. From cory.quammen at kitware.com Mon May 8 16:51:58 2017 From: cory.quammen at kitware.com (Cory Quammen) Date: Mon, 8 May 2017 16:51:58 -0400 Subject: [Paraview-developers] New blog post: Color legend improvements coming to ParaView 5.4 Message-ID: Folks, I just published a blog post showing some of the enhancements coming to ParaView 5.4.0's color legend: https://blog.kitware.com/color-legend-improvements-coming-to-paraview-5-4/ Enjoy! Cory -- Cory Quammen Staff R&D Engineer Kitware, Inc. From cory.quammen at kitware.com Mon May 8 22:31:05 2017 From: cory.quammen at kitware.com (Cory Quammen) Date: Mon, 8 May 2017 22:31:05 -0400 Subject: [Paraview-developers] [Paraview] ParaView 5.4.0 Release Candidate 1 binaries are available for download In-Reply-To: <9901592F-4C2F-4254-A0CD-AE1DFA4D74F7@pointwise.com> References: <9901592F-4C2F-4254-A0CD-AE1DFA4D74F7@pointwise.com> Message-ID: Zach, Thanks for your report. However, I can't seem to reproduce that on macOS 10.11.6. What version of macOS are you using? Could it be a permissions issue on your system? - Cory On Mon, May 8, 2017 at 5:38 PM, Zach Davis wrote: > Hi Cory, > > I?ve downloaded the latest disk image for ParaView 5.4 RC-1 for macOS; > however, the image won?t open with an error message warning that there are > no mountable file systems. > > Best Regards, > > [image: Pointwise, Inc.] > Zach Davis > Pointwise?, Inc. > Sr. Engineer, Sales & Marketing > 213 South Jennings Avenue > Fort Worth, TX 76104-1107 > > *E*: zach.davis at pointwise.com > *P*: (817) 377-2807 x1202 <(817)%20377-2807> > *F*: (817) 377-2799 > > > > On May 8, 2017, at 10:18 AM, Cory Quammen > wrote: > > On behalf of the ParaView development community, I am happy to > announce that binaries and source code for ParaView 5.4.0-RC1 are > available to download from > > http://www.paraview.org/download/ > > Please let us know if you run into any problems with this release > candidate. > > Thank you, > 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 > > 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 > > > -- Cory Quammen Staff R&D Engineer Kitware, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.goebbert at fz-juelich.de Wed May 10 11:51:35 2017 From: j.goebbert at fz-juelich.de (=?iso-8859-1?Q?=22G=F6bbert=2C_Jens_Henrik=22?=) Date: Wed, 10 May 2017 15:51:35 +0000 Subject: [Paraview-developers] xdisplay-test + display=1 => segfault Message-ID: <1DB406F67241344CB6F3A199E54EF09D125F1AD2@MBX2010-E01.ad.fz-juelich.de> Hello ParaView-Team, we recently have experienced reproducible a segfaults of Xorg on display=1 (on CentOS 7.2 server with two NVIDIA Tesla K40), when used with: --server-- parallel ParaView/5.3.0 session (compiled with VTK_USE_X) over turboVNC(2.1.1) +VirtualGL(2.2.1) --client-- from a Windows7 client with turboVNC(2.1.1) (other versions of turboVNC and VirtualGL led to the same This crash does _NOT_ happen, if the vncviewer(yes: vncVIEWER!) is running on a Linux machine. As soon as ParaView GUI (running on the server with turboVNC+VirtualGL, too) connects to the pvservers running on the same machine, at least one of the pvservers on display=1 crashes (MPI leads then to a stop of the other pvservers). The crash of the pvserver on display 1 leads to a crash of Xorg of display 1 - or it is the other way round. We found that this crash can be avoided by starting the pvservers with the flag "--disable-xdisplay-test" I report this here, as it took some time to stumble over the flag "--disable-xdisplay-test" and this mail might help someone else. It seems as if the xdisplay-test is doing some nasty stuff ... As this bug is related to the OS(=Windows) of the client running turboVNC the xdisplay-test might trigger a bug in turboVNC or Xorg itself... Best, Jens Henrik P.S: We have tested this with older ParaView versions, too (5.2.0 and 5.1.2) and got the same segfaults of Xorg of display 1. The only difference was, that ParaView 5.3.0 results in a segfault when connecting and ParaView 5.2.0+5.1.2 results in segfaults when loading data. ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cory.quammen at kitware.com Wed May 10 13:16:05 2017 From: cory.quammen at kitware.com (Cory Quammen) Date: Wed, 10 May 2017 13:16:05 -0400 Subject: [Paraview-developers] xdisplay-test + display=1 => segfault In-Reply-To: <1DB406F67241344CB6F3A199E54EF09D125F1AD2@MBX2010-E01.ad.fz-juelich.de> References: <1DB406F67241344CB6F3A199E54EF09D125F1AD2@MBX2010-E01.ad.fz-juelich.de> Message-ID: Thanks for reporting, Jens! Cory On Wed, May 10, 2017 at 11:51 AM, "G?bbert, Jens Henrik" wrote: > Hello ParaView-Team, > > we recently have experienced reproducible a segfaults of Xorg on display=1 > (on CentOS 7.2 server with two NVIDIA Tesla K40), when used with: > --server-- > parallel ParaView/5.3.0 session (compiled with VTK_USE_X) > over turboVNC(2.1.1) +VirtualGL(2.2.1) > --client-- > from a Windows7 client > with turboVNC(2.1.1) > (other versions of turboVNC and VirtualGL led to the same > > This crash does _NOT_ happen, if the vncviewer(yes: vncVIEWER!) is running > on a Linux machine. > As soon as ParaView GUI (running on the server with turboVNC+VirtualGL, too) > connects to the pvservers running on the same machine, at least one of the > pvservers on display=1 crashes (MPI leads then to a stop of the other > pvservers). > The crash of the pvserver on display 1 leads to a crash of Xorg of display 1 > - or it is the other way round. > > We found that this crash can be avoided by starting the pvservers with the > flag "--disable-xdisplay-test" > I report this here, as it took some time to stumble over the flag > "--disable-xdisplay-test" and this mail might help someone else. > It seems as if the xdisplay-test is doing some nasty stuff ... > > As this bug is related to the OS(=Windows) of the client running turboVNC > the xdisplay-test might trigger a bug in turboVNC or Xorg itself... > > Best, > Jens Henrik > > P.S: > We have tested this with older ParaView versions, too (5.2.0 and 5.1.2) and > got the same segfaults of Xorg of display 1. > The only difference was, that ParaView 5.3.0 results in a segfault when > connecting and ParaView 5.2.0+5.1.2 results in segfaults when loading data. > > > > > ------------------------------------------------------------------------------------------------ > ------------------------------------------------------------------------------------------------ > Forschungszentrum Juelich GmbH > 52425 Juelich > Sitz der Gesellschaft: Juelich > Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 > Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher > Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), > Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, > Prof. Dr. Sebastian M. Schmidt > ------------------------------------------------------------------------------------------------ > ------------------------------------------------------------------------------------------------ > > > _______________________________________________ > 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. From utkarsh.ayachit at kitware.com Wed May 10 13:24:56 2017 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Wed, 10 May 2017 13:24:56 -0400 Subject: [Paraview-developers] xdisplay-test + display=1 => segfault In-Reply-To: <1DB406F67241344CB6F3A199E54EF09D125F1AD2@MBX2010-E01.ad.fz-juelich.de> References: <1DB406F67241344CB6F3A199E54EF09D125F1AD2@MBX2010-E01.ad.fz-juelich.de> Message-ID: Jens, Can you try closing current render view and creating new view? Does that fail even when you pass `--disable-xdisplay-test`? In my experience, whenever I have seen a crash in pvserver startup which can be circumvented by `--disable-xdisplay-test`, it's been a driver bug with creating multiple opengl contexts. Utkarsh On Wed, May 10, 2017 at 11:51 AM, "G?bbert, Jens Henrik" wrote: > Hello ParaView-Team, > > we recently have experienced reproducible a segfaults of Xorg on display=1 > (on CentOS 7.2 server with two NVIDIA Tesla K40), when used with: > --server-- > parallel ParaView/5.3.0 session (compiled with VTK_USE_X) > over turboVNC(2.1.1) +VirtualGL(2.2.1) > --client-- > from a Windows7 client > with turboVNC(2.1.1) > (other versions of turboVNC and VirtualGL led to the same > > This crash does _NOT_ happen, if the vncviewer(yes: vncVIEWER!) is running > on a Linux machine. > As soon as ParaView GUI (running on the server with turboVNC+VirtualGL, too) > connects to the pvservers running on the same machine, at least one of the > pvservers on display=1 crashes (MPI leads then to a stop of the other > pvservers). > The crash of the pvserver on display 1 leads to a crash of Xorg of display 1 > - or it is the other way round. > > We found that this crash can be avoided by starting the pvservers with the > flag "--disable-xdisplay-test" > I report this here, as it took some time to stumble over the flag > "--disable-xdisplay-test" and this mail might help someone else. > It seems as if the xdisplay-test is doing some nasty stuff ... > > As this bug is related to the OS(=Windows) of the client running turboVNC > the xdisplay-test might trigger a bug in turboVNC or Xorg itself... > > Best, > Jens Henrik > > P.S: > We have tested this with older ParaView versions, too (5.2.0 and 5.1.2) and > got the same segfaults of Xorg of display 1. > The only difference was, that ParaView 5.3.0 results in a segfault when > connecting and ParaView 5.2.0+5.1.2 results in segfaults when loading data. > > > > > ------------------------------------------------------------------------------------------------ > ------------------------------------------------------------------------------------------------ > Forschungszentrum Juelich GmbH > 52425 Juelich > Sitz der Gesellschaft: Juelich > Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 > Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher > Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), > Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, > Prof. Dr. Sebastian M. Schmidt > ------------------------------------------------------------------------------------------------ > ------------------------------------------------------------------------------------------------ > > > _______________________________________________ > 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 > From wascott at sandia.gov Wed May 10 18:31:22 2017 From: wascott at sandia.gov (Scott, W Alan) Date: Wed, 10 May 2017 22:31:22 +0000 Subject: [Paraview-developers] Performance on a large volume rendered job Message-ID: <3ba6ad6c11da45e49db9c1c454b7d419@ES01AMSNLNT.srn.sandia.gov> G'Day all, I am looking at the performance of a very large volume rendered fire. My user has been using lots of nodes, and we wanted to understand if these nodes are needed. Here is my result: Dataset: 1296 files, 1.3 GByte each, 18 TBytes total, 67 million cells, 468 timesteps. These viz runs are taking around 12 hours with a reasonable number of nodes. When hitting play, TimerLog says each frame uses the following time: 2 nodes - died 4 nodes/ 64 cores and ranks - 79 seconds/frame, node memory 65% full 8 nodes/ 128 cores and ranks - 64 seconds/frame, node memory 41% full 16 nodes/ 128 cores and ranks - 59 seconds/frame, node memory 23% full 24 nodes/ 192 cores and ranks - 53 seconds/frame, node memory unknown. For 16 nodes, timer log says we spent: 37 seconds - Regenerate Kd-Tree 15 seconds - Redistributing data 7 seconds - OpenGL Rendering For 8 nodes, timer log says we spent: 39 seconds - Regenerate Kd-Tree 17 seconds - Redistributing data 13 seconds - OpenGL Rendering So, we are getting scaling with increased memory, but not increased cpu. More specifically, the Regenerate Kd-Tree is not speeding up as you halve each nodes work (which is a surprise), and ditto redistributing data. OpenGL Rendering is linearly changing speeds. Last, he majority of our time is regenerating the Kd-Tree. What is this tree, why do we need it, what does it do? I have had this dataset in a debugger, and frankly, it was really hard to figure out where time was being spent. Any ideas how to proceed? Is there something we could do to increase information from the timer log? Thanks team! Alan -------------------------------------------------------- W. Alan Scott ParaView Support Manager SAIC Sandia National Laboratories, MS 0822 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: From j.goebbert at fz-juelich.de Thu May 11 04:37:53 2017 From: j.goebbert at fz-juelich.de (=?iso-8859-1?Q?=22G=F6bbert=2C_Jens_Henrik=22?=) Date: Thu, 11 May 2017 08:37:53 +0000 Subject: [Paraview-developers] xdisplay-test + display=1 => segfault In-Reply-To: References: <1DB406F67241344CB6F3A199E54EF09D125F1AD2@MBX2010-E01.ad.fz-juelich.de>, Message-ID: <1DB406F67241344CB6F3A199E54EF09D125F1C7D@MBX2010-E01.ad.fz-juelich.de> Hello Utkarsh, thank you for the hint. I checked if ParaView/5.3.0 (connected to 12 pvservers on the same node) crashes, if I close the render view and open a new one. This is not the case - I can close and open render views multiple times without problems (as long as I have called pvserver with "--disable-xdisplay-test"). Best, Jens Henrik P.S: In this context I would like to mention this bugreport: If using VirtualGL and NVIDIA driver in non-GLVND style ParaView 5.3.0 segfaults on startup (even without pvservers).This is not the case with the driver in GLVND style. "Segfault with ParaView 5.3.0RC2" - https://github.com/VirtualGL/virtualgl/issues/44 ________________________________________ From: Utkarsh Ayachit [utkarsh.ayachit at kitware.com] Sent: Wednesday, May 10, 2017 7:24 PM To: G?bbert, Jens Henrik Cc: paraview-developers at paraview.org Subject: Re: [Paraview-developers] xdisplay-test + display=1 => segfault Jens, Can you try closing current render view and creating new view? Does that fail even when you pass `--disable-xdisplay-test`? In my experience, whenever I have seen a crash in pvserver startup which can be circumvented by `--disable-xdisplay-test`, it's been a driver bug with creating multiple opengl contexts. Utkarsh On Wed, May 10, 2017 at 11:51 AM, "G?bbert, Jens Henrik" wrote: > Hello ParaView-Team, > > we recently have experienced reproducible a segfaults of Xorg on display=1 > (on CentOS 7.2 server with two NVIDIA Tesla K40), when used with: > --server-- > parallel ParaView/5.3.0 session (compiled with VTK_USE_X) > over turboVNC(2.1.1) +VirtualGL(2.2.1) > --client-- > from a Windows7 client > with turboVNC(2.1.1) > (other versions of turboVNC and VirtualGL led to the same > > This crash does _NOT_ happen, if the vncviewer(yes: vncVIEWER!) is running > on a Linux machine. > As soon as ParaView GUI (running on the server with turboVNC+VirtualGL, too) > connects to the pvservers running on the same machine, at least one of the > pvservers on display=1 crashes (MPI leads then to a stop of the other > pvservers). > The crash of the pvserver on display 1 leads to a crash of Xorg of display 1 > - or it is the other way round. > > We found that this crash can be avoided by starting the pvservers with the > flag "--disable-xdisplay-test" > I report this here, as it took some time to stumble over the flag > "--disable-xdisplay-test" and this mail might help someone else. > It seems as if the xdisplay-test is doing some nasty stuff ... > > As this bug is related to the OS(=Windows) of the client running turboVNC > the xdisplay-test might trigger a bug in turboVNC or Xorg itself... > > Best, > Jens Henrik > > P.S: > We have tested this with older ParaView versions, too (5.2.0 and 5.1.2) and > got the same segfaults of Xorg of display 1. > The only difference was, that ParaView 5.3.0 results in a segfault when > connecting and ParaView 5.2.0+5.1.2 results in segfaults when loading data. > > > > > ------------------------------------------------------------------------------------------------ > ------------------------------------------------------------------------------------------------ > Forschungszentrum Juelich GmbH > 52425 Juelich > Sitz der Gesellschaft: Juelich > Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 > Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher > Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), > Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, > Prof. Dr. Sebastian M. Schmidt > ------------------------------------------------------------------------------------------------ > ------------------------------------------------------------------------------------------------ > > > _______________________________________________ > 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 > From david.tuckey at eleves.ec-nantes.fr Thu May 11 07:45:14 2017 From: david.tuckey at eleves.ec-nantes.fr (David Tuckey) Date: Thu, 11 May 2017 13:45:14 +0200 (CEST) Subject: [Paraview-developers] Interacting with our data and an HTC Vive Message-ID: <529940768.986155.1494503114915.JavaMail.zimbra@eleves.ec-nantes.fr> Hello, I am currently working on scientific visualisation in virtual reality and am looking for ways to enhance the Paraview capabilities in this domain. I am using for my current tests a HTC Vive, but I am considering using a zSpace or a workbench in further works. The first goal is to be able to grab a plane and move it around in the virtual world to do live clipping of the objects, or move around a point to display live the streamlines at its location. A problem I am facing is that when objects in the scene are at the same location, I am never sure which one I will grab. Also while doing tests on VTK with OpenVR enabled, I could move around the representation of a basic vtkPlaneWidget without any effect on the position of it's bouding points or normal vector. I have two solutions in mind. 1) The first solution is to modify ParaView's (and so VTK's) OpenVR scripts to allow better interaction and live pipeline modification. I am new to VTK/ParaView source code, but I guess that would mean modifying the vtkOpenVRRenderWindowInteractor, the vtkRenderWindowInteractor3D and a few other interaction classes. Developping ParaView's built in OpenVR solution may reveal itself difficult for specific interaction tasks. Do you have any idea of where I should start from ? 2) The second solution would be to transfer the geometries after each modification to another software (such as a Unity pre-built scene), do the interaction in this software, and send back to ParaView the modification instructions. I thought I could archive this by using sockets in a Python script. Developping a new application on Unity allows easier interaction and the use on different hardware, but adds a new communication steps that could slow down the process. Do you have any advice about that ? I am not sure which one of the two solutions is the best. Thank you for any help. David Tuckey Student at Ecole Centrale de Nantes -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Thu May 11 09:21:49 2017 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Thu, 11 May 2017 09:21:49 -0400 Subject: [Paraview-developers] xdisplay-test + display=1 => segfault In-Reply-To: <1DB406F67241344CB6F3A199E54EF09D125F1C7D@MBX2010-E01.ad.fz-juelich.de> References: <1DB406F67241344CB6F3A199E54EF09D125F1AD2@MBX2010-E01.ad.fz-juelich.de> <1DB406F67241344CB6F3A199E54EF09D125F1C7D@MBX2010-E01.ad.fz-juelich.de> Message-ID: Jens, One final thing, can you ensure that you're doing remote rendering when you're closing/creating render views i.e. make sure your Remote Render Threshold is set to 0 before you try the test I suggested. On Thu, May 11, 2017 at 4:37 AM, "G?bbert, Jens Henrik" wrote: > Hello Utkarsh, > > thank you for the hint. > I checked if ParaView/5.3.0 (connected to 12 pvservers on the same node) crashes, if I close the render view and open a new one. This is not the case - I can close and open render views multiple times without problems (as long as I have called pvserver with "--disable-xdisplay-test"). > > Best, > Jens Henrik > > P.S: > In this context I would like to mention this bugreport: > If using VirtualGL and NVIDIA driver in non-GLVND style ParaView 5.3.0 segfaults on startup (even without pvservers).This is not the case with the driver in GLVND style. > "Segfault with ParaView 5.3.0RC2" - https://github.com/VirtualGL/virtualgl/issues/44 > > ________________________________________ > From: Utkarsh Ayachit [utkarsh.ayachit at kitware.com] > Sent: Wednesday, May 10, 2017 7:24 PM > To: G?bbert, Jens Henrik > Cc: paraview-developers at paraview.org > Subject: Re: [Paraview-developers] xdisplay-test + display=1 => segfault > > Jens, > > Can you try closing current render view and creating new view? Does > that fail even when you pass `--disable-xdisplay-test`? In my > experience, whenever I have seen a crash in pvserver startup which can > be circumvented by `--disable-xdisplay-test`, it's been a driver bug > with creating multiple opengl contexts. > > Utkarsh > > On Wed, May 10, 2017 at 11:51 AM, "G?bbert, Jens Henrik" > wrote: >> Hello ParaView-Team, >> >> we recently have experienced reproducible a segfaults of Xorg on display=1 >> (on CentOS 7.2 server with two NVIDIA Tesla K40), when used with: >> --server-- >> parallel ParaView/5.3.0 session (compiled with VTK_USE_X) >> over turboVNC(2.1.1) +VirtualGL(2.2.1) >> --client-- >> from a Windows7 client >> with turboVNC(2.1.1) >> (other versions of turboVNC and VirtualGL led to the same >> >> This crash does _NOT_ happen, if the vncviewer(yes: vncVIEWER!) is running >> on a Linux machine. >> As soon as ParaView GUI (running on the server with turboVNC+VirtualGL, too) >> connects to the pvservers running on the same machine, at least one of the >> pvservers on display=1 crashes (MPI leads then to a stop of the other >> pvservers). >> The crash of the pvserver on display 1 leads to a crash of Xorg of display 1 >> - or it is the other way round. >> >> We found that this crash can be avoided by starting the pvservers with the >> flag "--disable-xdisplay-test" >> I report this here, as it took some time to stumble over the flag >> "--disable-xdisplay-test" and this mail might help someone else. >> It seems as if the xdisplay-test is doing some nasty stuff ... >> >> As this bug is related to the OS(=Windows) of the client running turboVNC >> the xdisplay-test might trigger a bug in turboVNC or Xorg itself... >> >> Best, >> Jens Henrik >> >> P.S: >> We have tested this with older ParaView versions, too (5.2.0 and 5.1.2) and >> got the same segfaults of Xorg of display 1. >> The only difference was, that ParaView 5.3.0 results in a segfault when >> connecting and ParaView 5.2.0+5.1.2 results in segfaults when loading data. >> >> >> >> >> ------------------------------------------------------------------------------------------------ >> ------------------------------------------------------------------------------------------------ >> Forschungszentrum Juelich GmbH >> 52425 Juelich >> Sitz der Gesellschaft: Juelich >> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 >> Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher >> Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), >> Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, >> Prof. Dr. Sebastian M. Schmidt >> ------------------------------------------------------------------------------------------------ >> ------------------------------------------------------------------------------------------------ >> >> >> _______________________________________________ >> 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 >> From utkarsh.ayachit at kitware.com Thu May 11 09:32:08 2017 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Thu, 11 May 2017 09:32:08 -0400 Subject: [Paraview-developers] Is there a "no view" hint for filters? In-Reply-To: References: Message-ID: Cornelis. Jakub just contributed support for this here: https://gitlab.kitware.com/paraview/paraview/merge_requests/1562 It's been merged in `master` and will be available in 5.4-RC2. Utkarsh On Mon, May 8, 2017 at 5:25 AM, Cornelis Bockem?hl wrote: > Hello all, > > Writing a filter with 3 output ports, I would like to achieve a behaviour > that only the first of the ports will show in some 3D render view by > default. The second and third are actually table data which the user may > want to see or not. > > With this it makes sense to have them still as output port, but without a > default representation. The user may then open a spreadsheet view and choose > among the output ports he wants to see in numeric form. > > I know that in ther server manager xml you can put "hints" for > "Representation" or "RepresentationType", e.g. > > > > What I would like to use would be something like this: > > > > Is there such a thing available? I was trying and searching the source code, > but did not find an indication. > > 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 > From j.goebbert at fz-juelich.de Thu May 11 09:34:02 2017 From: j.goebbert at fz-juelich.de (=?iso-8859-1?Q?=22G=F6bbert=2C_Jens_Henrik=22?=) Date: Thu, 11 May 2017 13:34:02 +0000 Subject: [Paraview-developers] xdisplay-test + display=1 => segfault In-Reply-To: References: <1DB406F67241344CB6F3A199E54EF09D125F1AD2@MBX2010-E01.ad.fz-juelich.de> <1DB406F67241344CB6F3A199E54EF09D125F1C7D@MBX2010-E01.ad.fz-juelich.de>, Message-ID: <1DB406F67241344CB6F3A199E54EF09D125F1DD4@MBX2010-E01.ad.fz-juelich.de> Hi Utkarsh, you are right - I forgot to set the threshold to 0 before testing. Now it crashes when opening a new render view. We tested different versions of the NVIDIA driver already - they all behave the same way. Any hints how to track this error down? Best, Jens Henrik ________________________________________ From: Utkarsh Ayachit [utkarsh.ayachit at kitware.com] Sent: Thursday, May 11, 2017 3:21 PM To: G?bbert, Jens Henrik Cc: paraview-developers at paraview.org Subject: Re: [Paraview-developers] xdisplay-test + display=1 => segfault Jens, One final thing, can you ensure that you're doing remote rendering when you're closing/creating render views i.e. make sure your Remote Render Threshold is set to 0 before you try the test I suggested. On Thu, May 11, 2017 at 4:37 AM, "G?bbert, Jens Henrik" wrote: > Hello Utkarsh, > > thank you for the hint. > I checked if ParaView/5.3.0 (connected to 12 pvservers on the same node) crashes, if I close the render view and open a new one. This is not the case - I can close and open render views multiple times without problems (as long as I have called pvserver with "--disable-xdisplay-test"). > > Best, > Jens Henrik > > P.S: > In this context I would like to mention this bugreport: > If using VirtualGL and NVIDIA driver in non-GLVND style ParaView 5.3.0 segfaults on startup (even without pvservers).This is not the case with the driver in GLVND style. > "Segfault with ParaView 5.3.0RC2" - https://github.com/VirtualGL/virtualgl/issues/44 > > ________________________________________ > From: Utkarsh Ayachit [utkarsh.ayachit at kitware.com] > Sent: Wednesday, May 10, 2017 7:24 PM > To: G?bbert, Jens Henrik > Cc: paraview-developers at paraview.org > Subject: Re: [Paraview-developers] xdisplay-test + display=1 => segfault > > Jens, > > Can you try closing current render view and creating new view? Does > that fail even when you pass `--disable-xdisplay-test`? In my > experience, whenever I have seen a crash in pvserver startup which can > be circumvented by `--disable-xdisplay-test`, it's been a driver bug > with creating multiple opengl contexts. > > Utkarsh > > On Wed, May 10, 2017 at 11:51 AM, "G?bbert, Jens Henrik" > wrote: >> Hello ParaView-Team, >> >> we recently have experienced reproducible a segfaults of Xorg on display=1 >> (on CentOS 7.2 server with two NVIDIA Tesla K40), when used with: >> --server-- >> parallel ParaView/5.3.0 session (compiled with VTK_USE_X) >> over turboVNC(2.1.1) +VirtualGL(2.2.1) >> --client-- >> from a Windows7 client >> with turboVNC(2.1.1) >> (other versions of turboVNC and VirtualGL led to the same >> >> This crash does _NOT_ happen, if the vncviewer(yes: vncVIEWER!) is running >> on a Linux machine. >> As soon as ParaView GUI (running on the server with turboVNC+VirtualGL, too) >> connects to the pvservers running on the same machine, at least one of the >> pvservers on display=1 crashes (MPI leads then to a stop of the other >> pvservers). >> The crash of the pvserver on display 1 leads to a crash of Xorg of display 1 >> - or it is the other way round. >> >> We found that this crash can be avoided by starting the pvservers with the >> flag "--disable-xdisplay-test" >> I report this here, as it took some time to stumble over the flag >> "--disable-xdisplay-test" and this mail might help someone else. >> It seems as if the xdisplay-test is doing some nasty stuff ... >> >> As this bug is related to the OS(=Windows) of the client running turboVNC >> the xdisplay-test might trigger a bug in turboVNC or Xorg itself... >> >> Best, >> Jens Henrik >> >> P.S: >> We have tested this with older ParaView versions, too (5.2.0 and 5.1.2) and >> got the same segfaults of Xorg of display 1. >> The only difference was, that ParaView 5.3.0 results in a segfault when >> connecting and ParaView 5.2.0+5.1.2 results in segfaults when loading data. >> >> >> >> >> ------------------------------------------------------------------------------------------------ >> ------------------------------------------------------------------------------------------------ >> Forschungszentrum Juelich GmbH >> 52425 Juelich >> Sitz der Gesellschaft: Juelich >> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 >> Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher >> Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), >> Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, >> Prof. Dr. Sebastian M. Schmidt >> ------------------------------------------------------------------------------------------------ >> ------------------------------------------------------------------------------------------------ >> >> >> _______________________________________________ >> 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 >> From cornelis.bockemuehl at gmail.com Thu May 11 09:36:37 2017 From: cornelis.bockemuehl at gmail.com (=?UTF-8?Q?Cornelis_Bockem=C3=BChl?=) Date: Thu, 11 May 2017 15:36:37 +0200 Subject: [Paraview-developers] Is there a "no view" hint for filters? In-Reply-To: References: Message-ID: Wow - that's called "service"! ;-) Even if I know it was not implemented because of my request it comes very welcome for my project. Regards - and thanks for both the implementation (to Jakub) and the hint (to Utkarsh) Cornelis 2017-05-11 15:32 GMT+02:00 Utkarsh Ayachit : > Cornelis. > > Jakub just contributed support for this here: > https://gitlab.kitware.com/paraview/paraview/merge_requests/1562 > > It's been merged in `master` and will be available in 5.4-RC2. > > Utkarsh > > On Mon, May 8, 2017 at 5:25 AM, Cornelis Bockem?hl > wrote: > > Hello all, > > > > Writing a filter with 3 output ports, I would like to achieve a behaviour > > that only the first of the ports will show in some 3D render view by > > default. The second and third are actually table data which the user may > > want to see or not. > > > > With this it makes sense to have them still as output port, but without a > > default representation. The user may then open a spreadsheet view and > choose > > among the output ports he wants to see in numeric form. > > > > I know that in ther server manager xml you can put "hints" for > > "Representation" or "RepresentationType", e.g. > > > > > > > > What I would like to use would be something like this: > > > > > > > > Is there such a thing available? I was trying and searching the source > code, > > but did not find an indication. > > > > 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 > > > -- Cornelis Bockem?hl Basel, Schweiz -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Thu May 11 09:45:39 2017 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Thu, 11 May 2017 09:45:39 -0400 Subject: [Paraview-developers] Is there a "no view" hint for filters? In-Reply-To: References: Message-ID: To be fair, Jakub did this independently of my hint :). On Thu, May 11, 2017 at 9:36 AM, Cornelis Bockem?hl wrote: > Wow - that's called "service"! ;-) > > Even if I know it was not implemented because of my request it comes very > welcome for my project. > > Regards - and thanks for both the implementation (to Jakub) and the hint (to > Utkarsh) > Cornelis > > > 2017-05-11 15:32 GMT+02:00 Utkarsh Ayachit : >> >> Cornelis. >> >> Jakub just contributed support for this here: >> https://gitlab.kitware.com/paraview/paraview/merge_requests/1562 >> >> It's been merged in `master` and will be available in 5.4-RC2. >> >> Utkarsh >> >> On Mon, May 8, 2017 at 5:25 AM, Cornelis Bockem?hl >> wrote: >> > Hello all, >> > >> > Writing a filter with 3 output ports, I would like to achieve a >> > behaviour >> > that only the first of the ports will show in some 3D render view by >> > default. The second and third are actually table data which the user may >> > want to see or not. >> > >> > With this it makes sense to have them still as output port, but without >> > a >> > default representation. The user may then open a spreadsheet view and >> > choose >> > among the output ports he wants to see in numeric form. >> > >> > I know that in ther server manager xml you can put "hints" for >> > "Representation" or "RepresentationType", e.g. >> > >> > >> > >> > What I would like to use would be something like this: >> > >> > >> > >> > Is there such a thing available? I was trying and searching the source >> > code, >> > but did not find an indication. >> > >> > 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 >> > > > > > > -- > Cornelis Bockem?hl > Basel, Schweiz From cornelis.bockemuehl at gmail.com Thu May 11 09:51:41 2017 From: cornelis.bockemuehl at gmail.com (=?UTF-8?Q?Cornelis_Bockem=C3=BChl?=) Date: Thu, 11 May 2017 15:51:41 +0200 Subject: [Paraview-developers] Is there a "no view" hint for filters? In-Reply-To: References: Message-ID: I mean the hint that you gave to me - about the fact that somebody has done it! 2017-05-11 15:45 GMT+02:00 Utkarsh Ayachit : > To be fair, Jakub did this independently of my hint :). > > On Thu, May 11, 2017 at 9:36 AM, Cornelis Bockem?hl > wrote: > > Wow - that's called "service"! ;-) > > > > Even if I know it was not implemented because of my request it comes very > > welcome for my project. > > > > Regards - and thanks for both the implementation (to Jakub) and the hint > (to > > Utkarsh) > > Cornelis > > > > > > 2017-05-11 15:32 GMT+02:00 Utkarsh Ayachit >: > >> > >> Cornelis. > >> > >> Jakub just contributed support for this here: > >> https://gitlab.kitware.com/paraview/paraview/merge_requests/1562 > >> > >> It's been merged in `master` and will be available in 5.4-RC2. > >> > >> Utkarsh > >> > >> On Mon, May 8, 2017 at 5:25 AM, Cornelis Bockem?hl > >> wrote: > >> > Hello all, > >> > > >> > Writing a filter with 3 output ports, I would like to achieve a > >> > behaviour > >> > that only the first of the ports will show in some 3D render view by > >> > default. The second and third are actually table data which the user > may > >> > want to see or not. > >> > > >> > With this it makes sense to have them still as output port, but > without > >> > a > >> > default representation. The user may then open a spreadsheet view and > >> > choose > >> > among the output ports he wants to see in numeric form. > >> > > >> > I know that in ther server manager xml you can put "hints" for > >> > "Representation" or "RepresentationType", e.g. > >> > > >> > > >> > > >> > What I would like to use would be something like this: > >> > > >> > > >> > > >> > Is there such a thing available? I was trying and searching the source > >> > code, > >> > but did not find an indication. > >> > > >> > 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 > >> > > > > > > > > > > > -- > > Cornelis Bockem?hl > > Basel, Schweiz > -- Cornelis Bockem?hl Basel, Schweiz -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mark.Olesen at esi-group.com Fri May 12 13:07:53 2017 From: Mark.Olesen at esi-group.com (Mark Olesen) Date: Fri, 12 May 2017 17:07:53 +0000 Subject: [Paraview-developers] minimizing memory for reader (or catalyst) Message-ID: I am reworking a reader module to see how I can improve memory usage and performance by using internal caching and I would like to see if my concept has major flaws or other things to worry about. The final target will be in-situ usage, but I'll practicing a bit with the paraview reader module. I have concluded that since the basic simulation data do not lend themselves to normal zero-copy techniques, and I'm not completely convinced that the vtkMappedUnstructuredGrid approach will work either (I need to deal with possible on-the-fly polyhedral decomposition too), my approach like an inside-out version of vtkMappedUnstructuredGrid. 1) Query my simulation to obtain all the sizing data. 2) Allocate a vtkUnstructuredGrid with the appropriate sizing and pass the underlying VTK data contents back for filling in. This easiest to done by the simulation, since it knows its own data structures and minimizes the ABI connection. Only the size of vtkIdType is needed by the simulation itself and the interface code is templated on variants of that. 3) Finally update the vtkUnstructuredGrid Eg, ... query simulation for sizing // get pointers for/from unstructured grid: vtkSmartPointer cells = vtkmesh->GetCells(); cells->GetData()->SetNumberOfTuples(nConnectivity); .... other arrays and sizing // wrap the WritePointer with a pass-through list-container (no allocation) UList ul_cells ( cells->WritePointer(sizing.nFieldCells(), sizing.nConnectivity()), sizing.nConnectivity() ); // fill with contents in a form that VTK would expect sizing.populateInternal(myMesh, ul_cellTypes,ul_cells, ul_cellLocations,ul_faces, ul_faceLocations, myMapping); // update VTK side of things: vtkmesh->SetCells(cellTypes, cellLocations, cells, faceLocations, faces); This seems to work OK and is more-or-less an en bloc alternative to vtkMappedUnstructuredGrid. The next stage is where it gets interesting, or at least where I get quite confused. Assuming that the mesh doesn't change very often during a simulation, I would like to re-use the VTK grid entirely. For this, I'm using hashtable with a (std::string, vtkSmartPointer) key/value pair that handles deletion nicely. On the first time through, I create the vtk-mesh and store as a SmartPointer in the hash before attaching it to the ParaView output: vtkMultiBlockDataSet* output = vtkMultiBlockDataSet::SafeDownCast(outputVector->GetInformationObject(0)->Get(vtkMultiBlockDataSet::DATA_OBJECT()); ... block->SetBlock(datasetNo, dataset) I assume that this simply increases the RefCount, or does paraview make a deep-copy of the data returned on the output vector? On further calls, I can simply do the same type of thing (adding to the output object), but with the grid retrieved from the hashtable cache. So what happens when I start modify the cached values (presuming that paraview has a shallow copy of the data)? For example, there are topology changes that I would like to handle. If I access my pointer from the cache, make the modifications and then add it back to the output vector, what state is the data in? Am I modifying (corrupting) data that is currently in use by paraview? Or does the paraview hold off until I complete the action? During this modification time, do I have two copied of the data, or are they always shallow copies referencing the same data? Any good pointers to understanding this would be very greatly appreciated! I've scoured the wiki and other locations, but without much success. Cheers, /mark From utkarsh.ayachit at kitware.com Sat May 13 12:11:57 2017 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Sat, 13 May 2017 12:11:57 -0400 Subject: [Paraview-developers] xdisplay-test + display=1 => segfault In-Reply-To: <1DB406F67241344CB6F3A199E54EF09D125F1DD4@MBX2010-E01.ad.fz-juelich.de> References: <1DB406F67241344CB6F3A199E54EF09D125F1AD2@MBX2010-E01.ad.fz-juelich.de> <1DB406F67241344CB6F3A199E54EF09D125F1C7D@MBX2010-E01.ad.fz-juelich.de> <1DB406F67241344CB6F3A199E54EF09D125F1DD4@MBX2010-E01.ad.fz-juelich.de> Message-ID: Let me try to contact NVidia developers and see if they can provide some info. What driver versions did you try this with? Utkarsh On Thu, May 11, 2017 at 9:34 AM, "G?bbert, Jens Henrik" < j.goebbert at fz-juelich.de> wrote: > Hi Utkarsh, > > you are right - I forgot to set the threshold to 0 before testing. > Now it crashes when opening a new render view. > > We tested different versions of the NVIDIA driver already - they all > behave the same way. > Any hints how to track this error down? > > Best, > Jens Henrik > > ________________________________________ > From: Utkarsh Ayachit [utkarsh.ayachit at kitware.com] > Sent: Thursday, May 11, 2017 3:21 PM > To: G?bbert, Jens Henrik > Cc: paraview-developers at paraview.org > Subject: Re: [Paraview-developers] xdisplay-test + display=1 => segfault > > Jens, > > One final thing, can you ensure that you're doing remote rendering > when you're closing/creating render views i.e. make sure your Remote > Render Threshold is set to 0 before you try the test I suggested. > > On Thu, May 11, 2017 at 4:37 AM, "G?bbert, Jens Henrik" > wrote: > > Hello Utkarsh, > > > > thank you for the hint. > > I checked if ParaView/5.3.0 (connected to 12 pvservers on the same node) > crashes, if I close the render view and open a new one. This is not the > case - I can close and open render views multiple times without problems > (as long as I have called pvserver with "--disable-xdisplay-test"). > > > > Best, > > Jens Henrik > > > > P.S: > > In this context I would like to mention this bugreport: > > If using VirtualGL and NVIDIA driver in non-GLVND style ParaView 5.3.0 > segfaults on startup (even without pvservers).This is not the case with the > driver in GLVND style. > > "Segfault with ParaView 5.3.0RC2" - https://github.com/VirtualGL/ > virtualgl/issues/44 > > > > ________________________________________ > > From: Utkarsh Ayachit [utkarsh.ayachit at kitware.com] > > Sent: Wednesday, May 10, 2017 7:24 PM > > To: G?bbert, Jens Henrik > > Cc: paraview-developers at paraview.org > > Subject: Re: [Paraview-developers] xdisplay-test + display=1 => segfault > > > > Jens, > > > > Can you try closing current render view and creating new view? Does > > that fail even when you pass `--disable-xdisplay-test`? In my > > experience, whenever I have seen a crash in pvserver startup which can > > be circumvented by `--disable-xdisplay-test`, it's been a driver bug > > with creating multiple opengl contexts. > > > > Utkarsh > > > > On Wed, May 10, 2017 at 11:51 AM, "G?bbert, Jens Henrik" > > wrote: > >> Hello ParaView-Team, > >> > >> we recently have experienced reproducible a segfaults of Xorg on > display=1 > >> (on CentOS 7.2 server with two NVIDIA Tesla K40), when used with: > >> --server-- > >> parallel ParaView/5.3.0 session (compiled with VTK_USE_X) > >> over turboVNC(2.1.1) +VirtualGL(2.2.1) > >> --client-- > >> from a Windows7 client > >> with turboVNC(2.1.1) > >> (other versions of turboVNC and VirtualGL led to the same > >> > >> This crash does _NOT_ happen, if the vncviewer(yes: vncVIEWER!) is > running > >> on a Linux machine. > >> As soon as ParaView GUI (running on the server with turboVNC+VirtualGL, > too) > >> connects to the pvservers running on the same machine, at least one of > the > >> pvservers on display=1 crashes (MPI leads then to a stop of the other > >> pvservers). > >> The crash of the pvserver on display 1 leads to a crash of Xorg of > display 1 > >> - or it is the other way round. > >> > >> We found that this crash can be avoided by starting the pvservers with > the > >> flag "--disable-xdisplay-test" > >> I report this here, as it took some time to stumble over the flag > >> "--disable-xdisplay-test" and this mail might help someone else. > >> It seems as if the xdisplay-test is doing some nasty stuff ... > >> > >> As this bug is related to the OS(=Windows) of the client running > turboVNC > >> the xdisplay-test might trigger a bug in turboVNC or Xorg itself... > >> > >> Best, > >> Jens Henrik > >> > >> P.S: > >> We have tested this with older ParaView versions, too (5.2.0 and 5.1.2) > and > >> got the same segfaults of Xorg of display 1. > >> The only difference was, that ParaView 5.3.0 results in a segfault when > >> connecting and ParaView 5.2.0+5.1.2 results in segfaults when loading > data. > >> > >> > >> > >> > >> ------------------------------------------------------------ > ------------------------------------ > >> ------------------------------------------------------------ > ------------------------------------ > >> Forschungszentrum Juelich GmbH > >> 52425 Juelich > >> Sitz der Gesellschaft: Juelich > >> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 > >> Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher > >> Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), > >> Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, > >> Prof. Dr. Sebastian M. Schmidt > >> ------------------------------------------------------------ > ------------------------------------ > >> ------------------------------------------------------------ > ------------------------------------ > >> > >> > >> _______________________________________________ > >> 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: From utkarsh.ayachit at kitware.com Mon May 15 10:05:29 2017 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Mon, 15 May 2017 10:05:29 -0400 Subject: [Paraview-developers] xdisplay-test + display=1 => segfault In-Reply-To: References: <1DB406F67241344CB6F3A199E54EF09D125F1AD2@MBX2010-E01.ad.fz-juelich.de> <1DB406F67241344CB6F3A199E54EF09D125F1C7D@MBX2010-E01.ad.fz-juelich.de> <1DB406F67241344CB6F3A199E54EF09D125F1DD4@MBX2010-E01.ad.fz-juelich.de> Message-ID: 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. Utkarsh On Sat, May 13, 2017 at 12:11 PM, Utkarsh Ayachit < utkarsh.ayachit at kitware.com> wrote: > Let me try to contact NVidia developers and see if they can provide some > info. What driver versions did you try this with? > > Utkarsh > > On Thu, May 11, 2017 at 9:34 AM, "G?bbert, Jens Henrik" < > j.goebbert at fz-juelich.de> wrote: > >> Hi Utkarsh, >> >> you are right - I forgot to set the threshold to 0 before testing. >> Now it crashes when opening a new render view. >> >> We tested different versions of the NVIDIA driver already - they all >> behave the same way. >> Any hints how to track this error down? >> >> Best, >> Jens Henrik >> >> ________________________________________ >> From: Utkarsh Ayachit [utkarsh.ayachit at kitware.com] >> Sent: Thursday, May 11, 2017 3:21 PM >> To: G?bbert, Jens Henrik >> Cc: paraview-developers at paraview.org >> Subject: Re: [Paraview-developers] xdisplay-test + display=1 => segfault >> >> Jens, >> >> One final thing, can you ensure that you're doing remote rendering >> when you're closing/creating render views i.e. make sure your Remote >> Render Threshold is set to 0 before you try the test I suggested. >> >> On Thu, May 11, 2017 at 4:37 AM, "G?bbert, Jens Henrik" >> wrote: >> > Hello Utkarsh, >> > >> > thank you for the hint. >> > I checked if ParaView/5.3.0 (connected to 12 pvservers on the same >> node) crashes, if I close the render view and open a new one. This is not >> the case - I can close and open render views multiple times without >> problems (as long as I have called pvserver with "--disable-xdisplay-test"). >> > >> > Best, >> > Jens Henrik >> > >> > P.S: >> > In this context I would like to mention this bugreport: >> > If using VirtualGL and NVIDIA driver in non-GLVND style ParaView 5.3.0 >> segfaults on startup (even without pvservers).This is not the case with the >> driver in GLVND style. >> > "Segfault with ParaView 5.3.0RC2" - https://github.com/VirtualGL/v >> irtualgl/issues/44 >> > >> > ________________________________________ >> > From: Utkarsh Ayachit [utkarsh.ayachit at kitware.com] >> > Sent: Wednesday, May 10, 2017 7:24 PM >> > To: G?bbert, Jens Henrik >> > Cc: paraview-developers at paraview.org >> > Subject: Re: [Paraview-developers] xdisplay-test + display=1 => segfault >> > >> > Jens, >> > >> > Can you try closing current render view and creating new view? Does >> > that fail even when you pass `--disable-xdisplay-test`? In my >> > experience, whenever I have seen a crash in pvserver startup which can >> > be circumvented by `--disable-xdisplay-test`, it's been a driver bug >> > with creating multiple opengl contexts. >> > >> > Utkarsh >> > >> > On Wed, May 10, 2017 at 11:51 AM, "G?bbert, Jens Henrik" >> > wrote: >> >> Hello ParaView-Team, >> >> >> >> we recently have experienced reproducible a segfaults of Xorg on >> display=1 >> >> (on CentOS 7.2 server with two NVIDIA Tesla K40), when used with: >> >> --server-- >> >> parallel ParaView/5.3.0 session (compiled with VTK_USE_X) >> >> over turboVNC(2.1.1) +VirtualGL(2.2.1) >> >> --client-- >> >> from a Windows7 client >> >> with turboVNC(2.1.1) >> >> (other versions of turboVNC and VirtualGL led to the same >> >> >> >> This crash does _NOT_ happen, if the vncviewer(yes: vncVIEWER!) is >> running >> >> on a Linux machine. >> >> As soon as ParaView GUI (running on the server with >> turboVNC+VirtualGL, too) >> >> connects to the pvservers running on the same machine, at least one of >> the >> >> pvservers on display=1 crashes (MPI leads then to a stop of the other >> >> pvservers). >> >> The crash of the pvserver on display 1 leads to a crash of Xorg of >> display 1 >> >> - or it is the other way round. >> >> >> >> We found that this crash can be avoided by starting the pvservers with >> the >> >> flag "--disable-xdisplay-test" >> >> I report this here, as it took some time to stumble over the flag >> >> "--disable-xdisplay-test" and this mail might help someone else. >> >> It seems as if the xdisplay-test is doing some nasty stuff ... >> >> >> >> As this bug is related to the OS(=Windows) of the client running >> turboVNC >> >> the xdisplay-test might trigger a bug in turboVNC or Xorg itself... >> >> >> >> Best, >> >> Jens Henrik >> >> >> >> P.S: >> >> We have tested this with older ParaView versions, too (5.2.0 and >> 5.1.2) and >> >> got the same segfaults of Xorg of display 1. >> >> The only difference was, that ParaView 5.3.0 results in a segfault when >> >> connecting and ParaView 5.2.0+5.1.2 results in segfaults when loading >> data. >> >> >> >> >> >> >> >> >> >> ------------------------------------------------------------ >> ------------------------------------ >> >> ------------------------------------------------------------ >> ------------------------------------ >> >> Forschungszentrum Juelich GmbH >> >> 52425 Juelich >> >> Sitz der Gesellschaft: Juelich >> >> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 >> >> Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher >> >> Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), >> >> Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, >> >> Prof. Dr. Sebastian M. Schmidt >> >> ------------------------------------------------------------ >> ------------------------------------ >> >> ------------------------------------------------------------ >> ------------------------------------ >> >> >> >> >> >> _______________________________________________ >> >> 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: From j.goebbert at fz-juelich.de Mon May 15 12:00:50 2017 From: j.goebbert at fz-juelich.de (=?Windows-1252?Q?=22G=F6bbert=2C_Jens_Henrik=22?=) Date: Mon, 15 May 2017 16:00:50 +0000 Subject: [Paraview-developers] xdisplay-test + display=1 => segfault In-Reply-To: References: <1DB406F67241344CB6F3A199E54EF09D125F1AD2@MBX2010-E01.ad.fz-juelich.de> <1DB406F67241344CB6F3A199E54EF09D125F1C7D@MBX2010-E01.ad.fz-juelich.de> <1DB406F67241344CB6F3A199E54EF09D125F1DD4@MBX2010-E01.ad.fz-juelich.de> , Message-ID: <1DB406F67241344CB6F3A199E54EF09D125FEBDD@MBX2010-E01.ad.fz-juelich.de> Hi Utkarsh, thanks you for the hints! I will compile ParaView then with EGL and check if that fixes the problem. Probably EGL would be the better solution anyway. Currently I get errors when linking pvpython: /homeb/zam/goebbert/workspace/paraview/pv_compile/build/lib/libvtkIOVisItBridge-pv5.3.so.1: undefined reference to `gluTessEndPolygon' It seems as if libGL is still required - but this is a different story. I have to check it. Best, Jens Henrik P.S: We are currently running on Nvidia driver version 375.26 (with GLVND style) ------------------------------------------------------------------------------------- Dipl.-Ing. Jens Henrik Goebbert Institute for Advanced Simulation (IAS) J?lich Supercomputing Centre (JSC) Wilhelm-Johnen-Stra?e, 52425 J?lich, Germany phone: +49 2461 61-96498 email: j.goebbert at fz-juelich.de http://www.fz-juelich.de/ias/jsc ________________________________ From: Utkarsh Ayachit [utkarsh.ayachit at kitware.com] Sent: Monday, May 15, 2017 4:05 PM To: G?bbert, Jens Henrik Cc: paraview-developers at paraview.org Subject: Re: [Paraview-developers] xdisplay-test + display=1 => segfault 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. Utkarsh On Sat, May 13, 2017 at 12:11 PM, Utkarsh Ayachit > wrote: Let me try to contact NVidia developers and see if they can provide some info. What driver versions did you try this with? Utkarsh On Thu, May 11, 2017 at 9:34 AM, "G?bbert, Jens Henrik" > wrote: Hi Utkarsh, you are right - I forgot to set the threshold to 0 before testing. Now it crashes when opening a new render view. We tested different versions of the NVIDIA driver already - they all behave the same way. Any hints how to track this error down? Best, Jens Henrik ________________________________________ From: Utkarsh Ayachit [utkarsh.ayachit at kitware.com] Sent: Thursday, May 11, 2017 3:21 PM To: G?bbert, Jens Henrik Cc: paraview-developers at paraview.org Subject: Re: [Paraview-developers] xdisplay-test + display=1 => segfault Jens, One final thing, can you ensure that you're doing remote rendering when you're closing/creating render views i.e. make sure your Remote Render Threshold is set to 0 before you try the test I suggested. On Thu, May 11, 2017 at 4:37 AM, "G?bbert, Jens Henrik" > wrote: > Hello Utkarsh, > > thank you for the hint. > I checked if ParaView/5.3.0 (connected to 12 pvservers on the same node) crashes, if I close the render view and open a new one. This is not the case - I can close and open render views multiple times without problems (as long as I have called pvserver with "--disable-xdisplay-test"). > > Best, > Jens Henrik > > P.S: > In this context I would like to mention this bugreport: > If using VirtualGL and NVIDIA driver in non-GLVND style ParaView 5.3.0 segfaults on startup (even without pvservers).This is not the case with the driver in GLVND style. > "Segfault with ParaView 5.3.0RC2" - https://github.com/VirtualGL/virtualgl/issues/44 > > ________________________________________ > From: Utkarsh Ayachit [utkarsh.ayachit at kitware.com] > Sent: Wednesday, May 10, 2017 7:24 PM > To: G?bbert, Jens Henrik > Cc: paraview-developers at paraview.org > Subject: Re: [Paraview-developers] xdisplay-test + display=1 => segfault > > Jens, > > Can you try closing current render view and creating new view? Does > that fail even when you pass `--disable-xdisplay-test`? In my > experience, whenever I have seen a crash in pvserver startup which can > be circumvented by `--disable-xdisplay-test`, it's been a driver bug > with creating multiple opengl contexts. > > Utkarsh > > On Wed, May 10, 2017 at 11:51 AM, "G?bbert, Jens Henrik" > > wrote: >> Hello ParaView-Team, >> >> we recently have experienced reproducible a segfaults of Xorg on display=1 >> (on CentOS 7.2 server with two NVIDIA Tesla K40), when used with: >> --server-- >> parallel ParaView/5.3.0 session (compiled with VTK_USE_X) >> over turboVNC(2.1.1) +VirtualGL(2.2.1) >> --client-- >> from a Windows7 client >> with turboVNC(2.1.1) >> (other versions of turboVNC and VirtualGL led to the same >> >> This crash does _NOT_ happen, if the vncviewer(yes: vncVIEWER!) is running >> on a Linux machine. >> As soon as ParaView GUI (running on the server with turboVNC+VirtualGL, too) >> connects to the pvservers running on the same machine, at least one of the >> pvservers on display=1 crashes (MPI leads then to a stop of the other >> pvservers). >> The crash of the pvserver on display 1 leads to a crash of Xorg of display 1 >> - or it is the other way round. >> >> We found that this crash can be avoided by starting the pvservers with the >> flag "--disable-xdisplay-test" >> I report this here, as it took some time to stumble over the flag >> "--disable-xdisplay-test" and this mail might help someone else. >> It seems as if the xdisplay-test is doing some nasty stuff ... >> >> As this bug is related to the OS(=Windows) of the client running turboVNC >> the xdisplay-test might trigger a bug in turboVNC or Xorg itself... >> >> Best, >> Jens Henrik >> >> P.S: >> We have tested this with older ParaView versions, too (5.2.0 and 5.1.2) and >> got the same segfaults of Xorg of display 1. >> The only difference was, that ParaView 5.3.0 results in a segfault when >> connecting and ParaView 5.2.0+5.1.2 results in segfaults when loading data. >> >> >> >> >> ------------------------------------------------------------------------------------------------ >> ------------------------------------------------------------------------------------------------ >> Forschungszentrum Juelich GmbH >> 52425 Juelich >> Sitz der Gesellschaft: Juelich >> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 >> Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher >> Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), >> Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, >> Prof. Dr. Sebastian M. Schmidt >> ------------------------------------------------------------------------------------------------ >> ------------------------------------------------------------------------------------------------ >> >> >> _______________________________________________ >> 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: From ben.boeckel at kitware.com Mon May 15 13:16:57 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 15 May 2017 13:16:57 -0400 Subject: [Paraview-developers] xdisplay-test + display=1 => segfault In-Reply-To: <1DB406F67241344CB6F3A199E54EF09D125FEBDD@MBX2010-E01.ad.fz-juelich.de> References: <1DB406F67241344CB6F3A199E54EF09D125F1AD2@MBX2010-E01.ad.fz-juelich.de> <1DB406F67241344CB6F3A199E54EF09D125F1C7D@MBX2010-E01.ad.fz-juelich.de> <1DB406F67241344CB6F3A199E54EF09D125F1DD4@MBX2010-E01.ad.fz-juelich.de> <1DB406F67241344CB6F3A199E54EF09D125FEBDD@MBX2010-E01.ad.fz-juelich.de> Message-ID: <20170515171657.GB26202@megas.kitware.com> On Mon, May 15, 2017 at 16:00:50 +0000, "G?bbert, Jens Henrik" wrote: > I will compile ParaView then with EGL and check if that fixes the > problem. Probably EGL would be the better solution anyway. > > Currently I get errors when linking pvpython: > /homeb/zam/goebbert/workspace/paraview/pv_compile/build/lib/libvtkIOVisItBridge-pv5.3.so.1: undefined reference to `gluTessEndPolygon' > It seems as if libGL is still required - but this is a different > story. I have to check it. This isn't libGL, but libGLU. Searching `master`, I see no reference to it anymore. Are you compiling with the `v5.3.0-1` tag in the superbuild (if you're building the 5.3.0 ParaView release)? --Ben From cory.quammen at kitware.com Mon May 15 15:11:15 2017 From: cory.quammen at kitware.com (Cory Quammen) Date: Mon, 15 May 2017 15:11:15 -0400 Subject: [Paraview-developers] ParaView 5.4.0-RC2 tagged Message-ID: Dear ParaView developers, ParaView 5.4.0-RC2 has been tagged (tag "v5.4.0-RC2"). Binaries for this release candidate are being built and will be posted to the ParaView downloads web page tomorrow. Thank you, Cory -- Cory Quammen Staff R&D Engineer Kitware, Inc. From andy.bauer at kitware.com Mon May 15 17:12:30 2017 From: andy.bauer at kitware.com (Andy Bauer) Date: Mon, 15 May 2017 17:12:30 -0400 Subject: [Paraview-developers] minimizing memory for reader (or catalyst) In-Reply-To: References: Message-ID: Hi Mark, You're very brave to try and play around with vtkCellArray and how it's used inside of VTK/PV :) One thing to keep in mind is that both the reader and the Catalyst adaptor are expected to provide a separate data sets for each time step in a time varying data set. If you're trying to modify the data you could get into trouble with things like particle paths that needs the data set at more than one time step at a time (e.g. particle paths uses the current and the previous time step to update the particle locations and for in situ it caches the pointer to the previous time step). Other filters like temporal statistics will be fine since that is done in a single pass through the data and with only computing results from a single time step at a time. Since your data set topology will often change over time you would want a separate vtkDataSet for each "static" topology data set that you could then shallow copy. You may want to look at the CxxSOADataArray example as this is a computationally efficient improvement on the vtkMappedArray stuff ( https://gitlab.kitware.com/paraview/paraview/tree/master/Examples/Catalyst/CxxSOADataArrayExample ). I inlined some more responses below trying to address some specific questions. Cheers, Andy On Fri, May 12, 2017 at 1:07 PM, Mark Olesen wrote: > I am reworking a reader module to see how I can improve memory usage and > performance by using internal caching and I would like to see if my concept > has major flaws or other things to worry about. The final target will be > in-situ usage, but I'll practicing a bit with the paraview reader module. > > I have concluded that since the basic simulation data do not lend > themselves to normal zero-copy techniques, and I'm not completely convinced > that the vtkMappedUnstructuredGrid approach will work either (I need to > deal with possible on-the-fly polyhedral decomposition too), my approach > like an inside-out version of vtkMappedUnstructuredGrid. > > 1) Query my simulation to obtain all the sizing data. > 2) Allocate a vtkUnstructuredGrid with the appropriate sizing and pass the > underlying VTK data contents back for filling in. This easiest to done by > the simulation, since it knows its own data structures and minimizes the > ABI connection. Only the size of vtkIdType is needed by the simulation > itself and the interface code is templated on variants of that. > 3) Finally update the vtkUnstructuredGrid > > Eg, > ... query simulation for sizing > // get pointers for/from unstructured grid: > vtkSmartPointer cells = vtkmesh->GetCells(); > cells->GetData()->SetNumberOfTuples(nConnectivity); > .... other arrays and sizing > > // wrap the WritePointer with a pass-through list-container (no > allocation) > UList ul_cells > ( > cells->WritePointer(sizing.nFieldCells(), > sizing.nConnectivity()), > sizing.nConnectivity() > ); > > // fill with contents in a form that VTK would expect > sizing.populateInternal(myMesh, ul_cellTypes,ul_cells, > ul_cellLocations,ul_faces, ul_faceLocations, myMapping); > > // update VTK side of things: > vtkmesh->SetCells(cellTypes, cellLocations, cells, faceLocations, > faces); > > This seems to work OK and is more-or-less an en bloc alternative to > vtkMappedUnstructuredGrid. > > The next stage is where it gets interesting, or at least where I get quite > confused. Assuming that the mesh doesn't change very often during a > simulation, I would like to re-use the VTK grid entirely. For this, I'm > using hashtable with a (std::string, vtkSmartPointer) > key/value pair that handles deletion nicely. > > On the first time through, I create the vtk-mesh and store as a > SmartPointer in the hash before attaching it to the ParaView output: > vtkMultiBlockDataSet* output = vtkMultiBlockDataSet:: > SafeDownCast(outputVector->GetInformationObject(0)->Get( > vtkMultiBlockDataSet::DATA_OBJECT()); > ... > block->SetBlock(datasetNo, dataset) > > I assume that this simply increases the RefCount, or does paraview make a > deep-copy of the data returned on the output vector? > On further calls, I can simply do the same type of thing (adding to the > output object), but with the grid retrieved from the hashtable cache. > Yes, for this it would just increase the reference count of dataset and NOT do a deep-copy of the data. > > So what happens when I start modify the cached values (presuming that > paraview has a shallow copy of the data)? > For example, there are topology changes that I would like to handle. If I > access my pointer from the cache, make the modifications and then add it > back to the output vector, what state is the data in? Am I modifying > (corrupting) data that is currently in use by paraview? Or does the > paraview hold off until I complete the action? During this modification > time, do I have two copied of the data, or are they always shallow copies > referencing the same data? > Shallow-copy will allow some of the data to be different. For example, shallow-copying a vtkUnstructuredGrid would initially have them looking identical. The source and target unstructured grids would be sharing references to the same arrays but some of the data members (e.g. PointData, CellData, FieldData) would be separate. Thus, after the shallow copy you could add in another point data array to the target unstructured grid and this would not affect the source unstructured grid. Similarly, you could replace an array in the target grid and not affect the source grid but if you went and got a specific array from the target grid and changed some values in there that change would also be reflected in the source grid. > > Any good pointers to understanding this would be very greatly appreciated! > I've scoured the wiki and other locations, but without much success. > > Cheers, > /mark > _______________________________________________ > 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: From j.goebbert at fz-juelich.de Tue May 16 03:55:41 2017 From: j.goebbert at fz-juelich.de (=?iso-8859-1?Q?=22G=F6bbert=2C_Jens_Henrik=22?=) Date: Tue, 16 May 2017 07:55:41 +0000 Subject: [Paraview-developers] xdisplay-test + display=1 => segfault In-Reply-To: <20170515171657.GB26202@megas.kitware.com> References: <1DB406F67241344CB6F3A199E54EF09D125F1AD2@MBX2010-E01.ad.fz-juelich.de> <1DB406F67241344CB6F3A199E54EF09D125F1C7D@MBX2010-E01.ad.fz-juelich.de> <1DB406F67241344CB6F3A199E54EF09D125F1DD4@MBX2010-E01.ad.fz-juelich.de> <1DB406F67241344CB6F3A199E54EF09D125FEBDD@MBX2010-E01.ad.fz-juelich.de>, <20170515171657.GB26202@megas.kitware.com> Message-ID: <1DB406F67241344CB6F3A199E54EF09D125FFDDF@MBX2010-E01.ad.fz-juelich.de> Hi Ben, in our easybuild-script for ParaView we download the source from the link of the webpage http://www.paraview.org/paraview-downloads/download.php?submit=Download&version=v5.3&type=source&os=all&downloadFile=ParaView-v5.3.0.tar.gz This seems to have a dependency to OpenGL if compiled for EGL in libvtkIOVisItBridge. I disable VISITBRIDGE for now (see attachement) Best, Jens Henrik ________________________________________ From: Ben Boeckel [ben.boeckel at kitware.com] Sent: Monday, May 15, 2017 7:16 PM To: G?bbert, Jens Henrik Cc: Utkarsh Ayachit; paraview-developers at paraview.org Subject: Re: [Paraview-developers] xdisplay-test + display=1 => segfault On Mon, May 15, 2017 at 16:00:50 +0000, "G?bbert, Jens Henrik" wrote: > I will compile ParaView then with EGL and check if that fixes the > problem. Probably EGL would be the better solution anyway. > > Currently I get errors when linking pvpython: > /homeb/zam/goebbert/workspace/paraview/pv_compile/build/lib/libvtkIOVisItBridge-pv5.3.so.1: undefined reference to `gluTessEndPolygon' > It seems as if libGL is still required - but this is a different > story. I have to check it. This isn't libGL, but libGLU. Searching `master`, I see no reference to it anymore. Are you compiling with the `v5.3.0-1` tag in the superbuild (if you're building the 5.3.0 ParaView release)? --Ben ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ -------------- next part -------------- A non-text attachment was scrubbed... Name: ParaView-5.3.0-intel-para-2017a-EGL.eb Type: application/octet-stream Size: 8737 bytes Desc: ParaView-5.3.0-intel-para-2017a-EGL.eb URL: From dlawrie at ara.co.uk Tue May 16 06:40:45 2017 From: dlawrie at ara.co.uk (David Lawrie) Date: Tue, 16 May 2017 10:40:45 +0000 Subject: [Paraview-developers] Question about SubProxy Message-ID: Hi All, I am trying to create a simple filter that uses the SubProxy approach as a learning exercise as I believe it will be useful in a more complex filter I will need to create later. Currently I am trying to create a filter which has a Contour sub-filter, exposes a couple of the properties then runs the contour filter using the user set values. In my XML I have the following subproxy block In my filter header I have included the following lines to provide storage for the sub-proxy and my constructor sets it to NULL at creation. vtkSetObjectMacro(ContourProxy, vtkPVContourFilter); vtkPVContourFilter* ContourProxy; So far so good, the gui does have the elements which are exposed, however the drop down box is empty and as far as I can tell the ContourProxy variable remains NULL. Presumably I have to create the vtkPVContourFilter object somewhere, however I am unsure as to how/where. Can anyone provide some guidance on what steps I am missing? Thanks. ********************************************************************** Please consider the environment. Only print this email if absolutely necessary. This email contains information that is private and confidential and is intended only for the addressee. If you are not the intended recipient please delete it and notify us immediately by e-mailing the sender. Note: All email sent to or from this address may be accessed by someone other than the recipient, for system management and security reasons. Aircraft Research Association Ltd. Registered in England, Registration No 503668 Registered Office: Manton Lane, Bedford MK41 7PF England VAT No GB 196351245 ********************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Tue May 16 10:07:23 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 16 May 2017 10:07:23 -0400 Subject: [Paraview-developers] xdisplay-test + display=1 => segfault In-Reply-To: <1DB406F67241344CB6F3A199E54EF09D125FFDDF@MBX2010-E01.ad.fz-juelich.de> References: <1DB406F67241344CB6F3A199E54EF09D125F1AD2@MBX2010-E01.ad.fz-juelich.de> <1DB406F67241344CB6F3A199E54EF09D125F1C7D@MBX2010-E01.ad.fz-juelich.de> <1DB406F67241344CB6F3A199E54EF09D125F1DD4@MBX2010-E01.ad.fz-juelich.de> <1DB406F67241344CB6F3A199E54EF09D125FEBDD@MBX2010-E01.ad.fz-juelich.de> <20170515171657.GB26202@megas.kitware.com> <1DB406F67241344CB6F3A199E54EF09D125FFDDF@MBX2010-E01.ad.fz-juelich.de> Message-ID: <20170516140723.GA29298@megas.kitware.com> On Tue, May 16, 2017 at 07:55:41 +0000, "G?bbert, Jens Henrik" wrote: > in our easybuild-script for ParaView we download the source from the link of the webpage > http://www.paraview.org/paraview-downloads/download.php?submit=Download&version=v5.3&type=source&os=all&downloadFile=ParaView-v5.3.0.tar.gz > > This seems to have a dependency to OpenGL if compiled for EGL in libvtkIOVisItBridge. > I disable VISITBRIDGE for now (see attachement) Ah, yes, VisItBridge in 5.3.0 requires libGLU if you enable the GMV reader, so you can also just disable that bit (VISIT_BUILD_READER_GMV). This is fine since the GMVReader plugin in ParaView itself already supports reading in this file format (the VisIt GMV reader is removed in 5.4.0). --Ben From cory.quammen at kitware.com Tue May 16 16:14:42 2017 From: cory.quammen at kitware.com (Cory Quammen) Date: Tue, 16 May 2017 16:14:42 -0400 Subject: [Paraview-developers] ParaView 5.4.0 Release Candidate 2 binaries are available for download Message-ID: On behalf of the ParaView development community, I am pleased to announce that binaries and source code for ParaView 5.4.0-RC2 are available to download from http://www.paraview.org/download/ There was a slight problem building the Linux binary and the AcuSolveReaderPlugin, so those are not yet available, but they will be uploaded as soon as possible. I will reply to this email when they are available for download. Please let us know if you run into any problems with this release candidate. Thank you, Cory -- Cory Quammen Staff R&D Engineer Kitware, Inc. From j.goebbert at fz-juelich.de Tue May 16 16:23:52 2017 From: j.goebbert at fz-juelich.de (=?iso-8859-1?Q?=22G=F6bbert=2C_Jens_Henrik=22?=) Date: Tue, 16 May 2017 20:23:52 +0000 Subject: [Paraview-developers] xdisplay-test + display=1 => segfault In-Reply-To: <20170516140723.GA29298@megas.kitware.com> References: <1DB406F67241344CB6F3A199E54EF09D125F1AD2@MBX2010-E01.ad.fz-juelich.de> <1DB406F67241344CB6F3A199E54EF09D125F1C7D@MBX2010-E01.ad.fz-juelich.de> <1DB406F67241344CB6F3A199E54EF09D125F1DD4@MBX2010-E01.ad.fz-juelich.de> <1DB406F67241344CB6F3A199E54EF09D125FEBDD@MBX2010-E01.ad.fz-juelich.de> <20170515171657.GB26202@megas.kitware.com> <1DB406F67241344CB6F3A199E54EF09D125FFDDF@MBX2010-E01.ad.fz-juelich.de>, <20170516140723.GA29298@megas.kitware.com> Message-ID: <1DB406F67241344CB6F3A199E54EF09D1260117B@MBX2010-E01.ad.fz-juelich.de> Thanks, Ben! ________________________________________ From: Ben Boeckel [ben.boeckel at kitware.com] Sent: Tuesday, May 16, 2017 4:07 PM To: G?bbert, Jens Henrik Cc: Utkarsh Ayachit; paraview-developers at paraview.org Subject: Re: [Paraview-developers] xdisplay-test + display=1 => segfault On Tue, May 16, 2017 at 07:55:41 +0000, "G?bbert, Jens Henrik" wrote: > in our easybuild-script for ParaView we download the source from the link of the webpage > http://www.paraview.org/paraview-downloads/download.php?submit=Download&version=v5.3&type=source&os=all&downloadFile=ParaView-v5.3.0.tar.gz > > This seems to have a dependency to OpenGL if compiled for EGL in libvtkIOVisItBridge. > I disable VISITBRIDGE for now (see attachement) Ah, yes, VisItBridge in 5.3.0 requires libGLU if you enable the GMV reader, so you can also just disable that bit (VISIT_BUILD_READER_GMV). This is fine since the GMVReader plugin in ParaView itself already supports reading in this file format (the VisIt GMV reader is removed in 5.4.0). --Ben ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ From utkarsh.ayachit at kitware.com Wed May 17 09:58:14 2017 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Wed, 17 May 2017 09:58:14 -0400 Subject: [Paraview-developers] Question about SubProxy In-Reply-To: References: Message-ID: David, I am correct is assuming that you have ProxyProperty on the filter proxy that you are expecting have this Contour proxy be set on? In that case, I don't think that's what you want. Here's what I'd suggest: 1. Remove the ProxyProperty from your filter XML. 2. Change your XML as follows: Note the *command* attribute on SubProxy. On Tue, May 16, 2017 at 6:40 AM, David Lawrie wrote: > Hi All, > > > > I am trying to create a simple filter that uses the SubProxy approach as > a learning exercise as I believe it will be useful in a more complex > filter I will need to create later. > > > > Currently I am trying to create a filter which has a Contour sub-filter, > exposes a couple of the properties then runs the contour filter using the > user set values. > > > > In my XML I have the following subproxy block > > > > > > > > > > > > > > > > > > > > > > In my filter header I have included the following lines to provide storage > for the sub-proxy and my constructor sets it to NULL at creation. > > > > vtkSetObjectMacro(ContourProxy, vtkPVContourFilter); > > vtkPVContourFilter* ContourProxy; > > > > So far so good, the gui does have the elements which are exposed, however > the drop down box is empty and as far as I can tell the ContourProxy > variable remains NULL. Presumably I have to create the vtkPVContourFilter > object somewhere, however I am unsure as to how/where. > > > > Can anyone provide some guidance on what steps I am missing? > > > > Thanks. > > ********************************************************************** > > Please consider the environment. Only print this email if absolutely > necessary. > > This email contains information that is private and confidential and is > intended only for the addressee. > If you are not the intended recipient please delete it and notify us > immediately by e-mailing the sender. > Note: All email sent to or from this address may be accessed by someone > other than the recipient, for > system management and security reasons. > Aircraft Research Association Ltd. Registered in England, Registration No > 503668 Registered Office: > Manton Lane, Bedford MK41 7PF England VAT No GB 196351245 > > ********************************************************************** > > _______________________________________________ > 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: From dave.demarle at kitware.com Wed May 17 10:24:59 2017 From: dave.demarle at kitware.com (David E DeMarle) Date: Wed, 17 May 2017 10:24:59 -0400 Subject: [Paraview-developers] ParaView 5.4.0 Release Candidate 2 binaries are available for download In-Reply-To: References: Message-ID: Cory can you summarize what changed between RC1 and RC2? thanks David E DeMarle Kitware, Inc. Principal Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Tue, May 16, 2017 at 4:14 PM, Cory Quammen wrote: > On behalf of the ParaView development community, I am pleased to > announce that binaries and source code for ParaView 5.4.0-RC2 are > available to download from > > http://www.paraview.org/download/ > > There was a slight problem building the Linux binary and the > AcuSolveReaderPlugin, so those are not yet available, but they will be > uploaded as soon as possible. I will reply to this email when they are > available for download. > > Please let us know if you run into any problems with this release > candidate. > > Thank you, > 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: From cory.quammen at kitware.com Wed May 17 10:47:36 2017 From: cory.quammen at kitware.com (Cory Quammen) Date: Wed, 17 May 2017 10:47:36 -0400 Subject: [Paraview-developers] ParaView 5.4.0 Release Candidate 2 binaries are available for download In-Reply-To: References: Message-ID: Sure thing. Here is the commit log summary between RC1 and RC2 with some manual editing for clarity and brevity. * 2ef0dbe - CGNS: add option to not load mesh * ffb19d9 - CGNS: improve support for families. * 8359a42 - Adding a source that can create a variety of unstructured cell types * 461812e - Use source name for root node in multiblock inspector * cb5fd0e - add option to expand the multiblock inspector tree fully. * 77daa78 - Don't show inspector for non-composite datasets. * 75fb814 - Fix sphinx API generation * 240dd21 - ParaViewWeb: Provide main camera ref for local rendering * 47f2053 - Add required libharu for PDF export * c137764 - Enable HiDPI display mode where appropriate, including Macs with Retina displays * 917b5b5 - Fix flash when doing selection in render view. * cce243e - Better default position for multiblock inspector. * 2d4c4a9 - Fix coloring for pieces in multipiece. * f7262b5 - Deprecate pqMultiBlockInspectorPanel. * ed18919 - Add pqMultiBlockInspectorWidget. * 616e636 - Enhancements to pqCompositeDataInformationTreeModel. * 5d6805a - Add ability to save/restore expand state for tree view in multi block inspector * 1c93a86 - Add support for parallel batch processing from python * 7373430 - Sphinx: handle python 2 or 3 * 7a0c0ca - Add an option to load state to fail when file is not in data directory * 9e0910b - Added backwards compatibility for color legend AspectRatio and Position2 properties * c3cbd98 - Disable NSHighResolutionCapable Info.plist setting when building with Qt4 * 94d8c76 - doxygen: address warnings * 6b7dfa8 - Add possibility to turn off automatic display of filter output. * 8406965 - Clarify assert messages * 27fada4 - Capture pv center of rotation as an extra property in ParaViewWeb protocols * aa70a34 - sphinx_apidoc: do not encode the text * ad5cefd - Improving documentation for Stream Tracer filters * 0cb1d56 - Make window location names consistent between representations * 02457f0 - expand the bounds text to show 6 digits * 3e5eb34 - Make color legend editor dialog title consistent with tooltip for button that opens it * 420a213 - Change defaults for ScalarBarLength and ScalarBarThickness * 8d985c8 - Set color legend location to AnyLocation when loading older state files * ed43e77 - XML conversion for removed scalar bar Position2 property * dedfeda - Replace Position2 property with ScalarBarLength * 00cf94b - Restore defining scalar bar length by a scalar * dc15e88 - Small perf improvement to pqProxyInformationWidget. * 081e80a - Add support for reading BC patches for structured grids. * 5cb1ec1 - Fix segfault in pqFlatTreeView. * 4efcef2 - Add `vtkBlockColors` correctly for datasets with multi-pieces. * 9793648 - Better handling of NGON_n/NFACE_n unstructured CGNS meshes On Wed, May 17, 2017 at 10:24 AM, David E DeMarle wrote: > Cory can you summarize what changed between RC1 and RC2? > > thanks > > David E DeMarle > Kitware, Inc. > Principal Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > On Tue, May 16, 2017 at 4:14 PM, Cory Quammen > wrote: >> >> On behalf of the ParaView development community, I am pleased to >> announce that binaries and source code for ParaView 5.4.0-RC2 are >> available to download from >> >> http://www.paraview.org/download/ >> >> There was a slight problem building the Linux binary and the >> AcuSolveReaderPlugin, so those are not yet available, but they will be >> uploaded as soon as possible. I will reply to this email when they are >> available for download. >> >> Please let us know if you run into any problems with this release >> candidate. >> >> Thank you, >> 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 > > -- Cory Quammen Staff R&D Engineer Kitware, Inc. From cory.quammen at kitware.com Wed May 17 23:10:33 2017 From: cory.quammen at kitware.com (Cory Quammen) Date: Wed, 17 May 2017 23:10:33 -0400 Subject: [Paraview-developers] ParaView 5.4.0 Release Candidate 2 binaries are available for download In-Reply-To: References: Message-ID: ParaView 5.4.0-RC2 binaries for Linux are now available on the downloads page. http://www.paraview.org/download/ Thank you, Cory On Tue, May 16, 2017 at 4:14 PM, Cory Quammen wrote: > On behalf of the ParaView development community, I am pleased to > announce that binaries and source code for ParaView 5.4.0-RC2 are > available to download from > > http://www.paraview.org/download/ > > There was a slight problem building the Linux binary and the > AcuSolveReaderPlugin, so those are not yet available, but they will be > uploaded as soon as possible. I will reply to this email when they are > available for download. > > Please let us know if you run into any problems with this release candidate. > > Thank you, > Cory > > -- > Cory Quammen > Staff R&D Engineer > Kitware, Inc. -- Cory Quammen Staff R&D Engineer Kitware, Inc. From wascott at sandia.gov Thu May 18 14:26:17 2017 From: wascott at sandia.gov (Scott, W Alan) Date: Thu, 18 May 2017 18:26:17 +0000 Subject: [Paraview-developers] Beauty Message-ID: <862ba27979df45c89e12189aba8cf529@ES01AMSNLNT.srn.sandia.gov> I am testing ParaView for the release, and wanted to complement Cory for his extraordinary color legend. Color legends are really hard to get to work correctly, and the new color legend really is spectacular. If people haven't yet seen it, take a look. Good job Cory! Alan -------------------------------------------------------- W. Alan Scott ParaView Support Manager SAIC Sandia National Laboratories, MS 0822 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: From cory.quammen at kitware.com Thu May 18 14:34:52 2017 From: cory.quammen at kitware.com (Cory Quammen) Date: Thu, 18 May 2017 14:34:52 -0400 Subject: [Paraview-developers] Beauty In-Reply-To: <862ba27979df45c89e12189aba8cf529@ES01AMSNLNT.srn.sandia.gov> References: <862ba27979df45c89e12189aba8cf529@ES01AMSNLNT.srn.sandia.gov> Message-ID: Thanks, Allen! That's really nice to hear. A couple more tweaks are coming before the 5.4.0 final based on suggestions from folks like you who have tried it out. Stay tuned. - Cory On Thu, May 18, 2017 at 2:26 PM, Scott, W Alan wrote: > I am testing ParaView for the release, and wanted to complement Cory for his > extraordinary color legend. Color legends are really hard to get to work > correctly, and the new color legend really is spectacular. If people > haven?t yet seen it, take a look. > > > > Good job Cory! > > > > Alan > > > > -------------------------------------------------------- > > W. Alan Scott > > ParaView Support Manager > > > > SAIC > > Sandia National Laboratories, MS 0822 > > 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/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. From ken.martin at kitware.com Fri May 19 15:43:54 2017 From: ken.martin at kitware.com (Ken Martin) Date: Fri, 19 May 2017 15:43:54 -0400 Subject: [Paraview-developers] Interacting with our data and an HTC Vive In-Reply-To: <529940768.986155.1494503114915.JavaMail.zimbra@eleves.ec-nantes.fr> References: <529940768.986155.1494503114915.JavaMail.zimbra@eleves.ec-nantes.fr> Message-ID: Both of those options sound fairly challenging unless you have worked with VTK a lot. I do believe there have been some experiments integrating ParaView to Unity or Unreal. There is some effort going on right now to improve widgets and interaction in OpenVR/VTK/PV as well but I wouldn't subject someone to that unless they had a lot of VTK dev experience as it can get into the guts of VTK fairly quickly. On Thu, May 11, 2017 at 7:45 AM, David Tuckey < david.tuckey at eleves.ec-nantes.fr> wrote: > Hello, > > I am currently working on scientific visualisation in virtual reality > and am looking for ways to enhance the Paraview capabilities in this > domain. I am using for my current tests a HTC Vive, but I am considering > using a zSpace or a workbench in further works. The first goal is to be > able to grab a plane and move it around in the virtual world to do live > clipping of the objects, or move around a point to display live the > streamlines at its location. > > A problem I am facing is that when objects in the scene are at the same > location, I am never sure which one I will grab. Also while doing tests > on VTK with OpenVR enabled, I could move around the representation of a > basic vtkPlaneWidget without any effect on the position of it's bouding > points or normal vector. > > I have two solutions in mind. > > 1) The first solution is to modify ParaView's (and so VTK's) OpenVR > scripts to allow better interaction and live pipeline modification. I am > new to VTK/ParaView source code, but I guess that would mean modifying > the vtkOpenVRRenderWindowInteractor, the vtkRenderWindowInteractor3D and > a few other interaction classes. Developping ParaView's built in OpenVR > solution may reveal itself difficult for specific interaction tasks. Do > you have any idea of where I should start from ? > > 2) The second solution would be to transfer the geometries after each > modification to another software (such as a Unity pre-built scene), do > the interaction in this software, and send back to ParaView the > modification instructions. I thought I could archive this by using > sockets in a Python script. Developping a new application on Unity > allows easier interaction and the use on different hardware, but adds a > new communication steps that could slow down the process. Do you have > any advice about that ? > > I am not sure which one of the two solutions is the best. > > Thank you for any help. > > > David Tuckey > Student at Ecole Centrale de Nantes > > _______________________________________________ > 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 > > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikhil.j.shetty at gmail.com Fri May 19 16:05:07 2017 From: nikhil.j.shetty at gmail.com (Nikhil Shetty) Date: Fri, 19 May 2017 14:05:07 -0600 Subject: [Paraview-developers] Interacting with our data and an HTC Vive In-Reply-To: References: <529940768.986155.1494503114915.JavaMail.zimbra@eleves.ec-nantes.fr> Message-ID: Hi Ken, Please let me know if you would like contributions to the work you mention to improve widgets and interactions with OpenVR/VTK/PV. If you could point me to the branch on GitLab then I can take a play with it, give feedback and contribute. Regards Nikhil On Fri, May 19, 2017 at 1:43 PM, Ken Martin wrote: > Both of those options sound fairly challenging unless you have worked with > VTK a lot. I do believe there have been some experiments integrating > ParaView to Unity or Unreal. There is some effort going on right now to > improve widgets and interaction in OpenVR/VTK/PV as well but I wouldn't > subject someone to that unless they had a lot of VTK dev experience as it > can get into the guts of VTK fairly quickly. > > > > On Thu, May 11, 2017 at 7:45 AM, David Tuckey nantes.fr> wrote: > >> Hello, >> >> I am currently working on scientific visualisation in virtual reality >> and am looking for ways to enhance the Paraview capabilities in this >> domain. I am using for my current tests a HTC Vive, but I am considering >> using a zSpace or a workbench in further works. The first goal is to be >> able to grab a plane and move it around in the virtual world to do live >> clipping of the objects, or move around a point to display live the >> streamlines at its location. >> >> A problem I am facing is that when objects in the scene are at the same >> location, I am never sure which one I will grab. Also while doing tests >> on VTK with OpenVR enabled, I could move around the representation of a >> basic vtkPlaneWidget without any effect on the position of it's bouding >> points or normal vector. >> >> I have two solutions in mind. >> >> 1) The first solution is to modify ParaView's (and so VTK's) OpenVR >> scripts to allow better interaction and live pipeline modification. I am >> new to VTK/ParaView source code, but I guess that would mean modifying >> the vtkOpenVRRenderWindowInteractor, the vtkRenderWindowInteractor3D and >> a few other interaction classes. Developping ParaView's built in OpenVR >> solution may reveal itself difficult for specific interaction tasks. Do >> you have any idea of where I should start from ? >> >> 2) The second solution would be to transfer the geometries after each >> modification to another software (such as a Unity pre-built scene), do >> the interaction in this software, and send back to ParaView the >> modification instructions. I thought I could archive this by using >> sockets in a Python script. Developping a new application on Unity >> allows easier interaction and the use on different hardware, but adds a >> new communication steps that could slow down the process. Do you have >> any advice about that ? >> >> I am not sure which one of the two solutions is the best. >> >> Thank you for any help. >> >> >> David Tuckey >> Student at Ecole Centrale de Nantes >> >> _______________________________________________ >> 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 >> >> > > > -- > Ken Martin PhD > Distinguished Engineer > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > > This communication, including all attachments, contains confidential and > legally privileged information, and it is intended only for the use of the > addressee. Access to this email by anyone else is unauthorized. If you are > not the intended recipient, any disclosure, copying, distribution or any > action taken in reliance on it is prohibited and may be unlawful. If you > received this communication in error please notify us immediately and > destroy the original message. Thank you. > > _______________________________________________ > 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 > > -- - Nikhil -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Tue May 23 13:47:16 2017 From: dave.demarle at kitware.com (David E DeMarle) Date: Tue, 23 May 2017 12:47:16 -0500 Subject: [Paraview-developers] the one about the file dialog box not showing? Message-ID: Has anyone seen a behavior (in 5.2) where ParaView works except for the fact that File->Open doesn't show a dialog and the rest of the gui then becomes unresponsive? Other dialogs are fine. In case it matters, this is PVGUI running through vglrun. Will try 5.1 and 5.3 shortly, 5.4 has other issues. thanks for any ideas, David E DeMarle Kitware, Inc. Principal Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 -------------- next part -------------- An HTML attachment was scrubbed... URL: From shawn.waldon at kitware.com Tue May 23 13:50:54 2017 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Tue, 23 May 2017 13:50:54 -0400 Subject: [Paraview-developers] the one about the file dialog box not showing? In-Reply-To: References: Message-ID: Dave, There is an issue (fixed in master but I'm not sure which version it was introduced) where the file dialog would be very slow for directories with many (thousands) of files. I'm not sure if it is related though. Shawn On Tue, May 23, 2017 at 1:47 PM, David E DeMarle wrote: > Has anyone seen a behavior (in 5.2) where ParaView works except for the > fact that File->Open > doesn't show a dialog and the rest of the gui then becomes unresponsive? > Other dialogs are fine. > > In case it matters, this is PVGUI running through vglrun. > > Will try 5.1 and 5.3 shortly, 5.4 has other issues. > > thanks for any ideas, > > David E DeMarle > Kitware, Inc. > Principal Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 <(518)%20881-4909> > > _______________________________________________ > 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: From Mark.Olesen at esi-group.com Wed May 24 11:04:53 2017 From: Mark.Olesen at esi-group.com (Mark Olesen) Date: Wed, 24 May 2017 15:04:53 +0000 Subject: [Paraview-developers] minimizing memory for reader (or catalyst) In-Reply-To: References: , Message-ID: Thank Andy for the extra information - the first tests (in paraview) seems to look pretty good. I had a smile on my face watching it run! For general documentation's sake, here's the bookkeeping organization that I use. With more comments below. //- Bookkeeping for internal caching. // Retain an original copy of the geometry as well as a shallow copy // with the output fields. // The original copy is reused for different timesteps etc. template class foamVtkCaching { public: typedef DataType dataType; //- The geometry, without any cell/point data vtkSmartPointer vtkgeom; //- The shallow-copy of geometry, plus additional data vtkSmartPointer dataset; //- Return a shallow copy of vtkgeom for manipulation vtkSmartPointer getCopy() const { auto copy = vtkSmartPointer::New(); copy->ShallowCopy(vtkgeom); return copy; } //- Make a shallow copy of vtkgeom into dataset void reuse() { dataset = vtkSmartPointer::New(); dataset->ShallowCopy(vtkgeom); } //- Set the geometry and make a shallow copy to dataset void set(vtkSmartPointer geom) { vtkgeom = geom; reuse(); } }; Following your comment > Shallow-copy will allow some of the data to be different. For example, shallow-copying a vtkUnstructuredGrid would initially have them looking identical. The source and target unstructured grids would be sharing references to the same arrays but some of the data members (e.g. PointData, CellData, FieldData) would be separate. Thus, after the shallow copy you could add in another point data array to the target unstructured grid and this would not affect the source unstructured grid. Similarly, you could replace an array in the target grid and not affect the source grid but if you went and got a specific array from the target grid and changed some values in there that change would also be reflected in the source grid. Case 1: Completely new geometry (eg, on startup, or topology changes). ==== Create vtkUnstructuredGrid, vtkPolyData as geometry only (no cell/point data). Use the set() method to make cached copy and a shallow copy of that as my 'dataset'. Add all cell/point data onto the 'dataset'. Case 2: Moving points, no topology change. ==== Use the getCopy() method to make a shallow copy of the geometry structure. Replace the points with the newly moved ones. Call set() to cache this 'moved' geometry and create the 'dataset' for adding cell/point data etc. Case 3: No change ==== Simply use the reuse() method to make a shallow copy of the cached geometry as my 'dataset'. At the moment, it seems to work OK. Thanks again for the pointers, and have no worries - I'll certainly be back with more questions! Cheers, /mark From cory.quammen at kitware.com Wed May 24 16:18:46 2017 From: cory.quammen at kitware.com (Cory Quammen) Date: Wed, 24 May 2017 16:18:46 -0400 Subject: [Paraview-developers] ParaView 5.4.0-RC3 tagged Message-ID: Dear ParaView developers, ParaView 5.4.0-RC3 has been tagged (tag "v5.4.0-RC3"). Binaries for this release candidate are being built and will be posted to the ParaView downloads web page when they are finished. If no major problems are found with this release candidate, we will use 5.4.0-RC3 as the 5.4.0 final release. Notable changes since v5.4.0-RC2 include: * 675c115 - Add vtkSMIntVectorProperty SetStatus support in vtkSMPropertyHelper class * 754122f - Remove unnecessary "UnstructuredGridBaseRepresentation" * a30c0a1 - Add option to disable use of floating point buffers. * 7f885eb - Fix title placement when axis isn't visible * 80f6c75 - Label, tick, and title placement improvements * b957457 - Change default color bar thickness to 16 * 95223db - Fix #17420: Specify override when exposing sub-proxy property * a57c127 - Fix extra render in pqColorMapEditor. * 2b8aef9 - Fix #17447: Update example visualizations * 5df9239 - Fix typo in ScalarBarRepresentation's WindowLocation domain * a7efb19 - Fix #17448: Uniform font sizes in examples dialog * cacaddb - Add support for CubeStereo * a63e217 - Make detailed file information an option * 50f0700 - HaloCenterFinder: use a format string which matches the type * 4acb692 - Add LZ4 compressor type to the Configure Writer dialog. * ea80990 - Avoid remote rendering when making selections if not needed. * bb7a8b1 - Update ExodusModeShapes to test for #17416. * fe2b1ec - Replace ParaView palette icon with tomviz one * aabe378 - Use vtkTypeMacro to avoid missing override warnings. * e3861c7 - allow specific extensions x{d}mf{2,3} for XDMF{2,3} * 74d92b3 - Fix initialization order warnings in vtkCGNSReader. * 393dc90 - Avoid too many updates from slider widgets. * 853aab7 - BUG: Cannot do fresh CMake configuration on macOS * 69f93d7 - Update XML for new Extract Time Steps mode * 80d3467 - Update VTK for extract time steps change * ff3e6cd - Guard dictionary acccess by checking key present * df1134a - Bring back selection support to pqMultiBlockInspectorWidget. Thank you, Cory -- Cory Quammen Staff R&D Engineer Kitware, Inc. From cory.quammen at kitware.com Fri May 26 08:56:40 2017 From: cory.quammen at kitware.com (Cory Quammen) Date: Fri, 26 May 2017 08:56:40 -0400 Subject: [Paraview-developers] ParaView 5.4.0 Release Candidate 3 binaries are available for download Message-ID: On behalf of the ParaView development community, I am happy to announce that binaries and source code for ParaView 5.4.0-RC3 are available to download from http://www.paraview.org/download/ Please let us know if you encounter any problems with this release candidate. Unless we run into a major roadblock, this will be the last release candidate before the 5.4.0 final release. Best regards, Cory -- Cory Quammen Staff R&D Engineer Kitware, Inc. From markus.moser at rwth-aachen.de Tue May 30 10:08:00 2017 From: markus.moser at rwth-aachen.de (Mizael Moser, Markus Klaus) Date: Tue, 30 May 2017 14:08:00 +0000 Subject: [Paraview-developers] Parallel structured grid reader doesn"t produce subextent Message-ID: <1496097056093.19755@rwth-aachen.de> Dear ParaView developers, I'm having trouble to parallelize my ParaView reader plugin. I want to read HDF5 files and the grid is a structured grid. The plugin works perfectly fine if run in serial, and if i run it in parallel the solution is also correct but instead of dividing the dataset in x subsets, it reads the whole dataset x times(for each processor 1 time). I found the wiki for a structured grid parallel reader (http://www.paraview.org/Wiki/Writing_ParaView_Readers) and used it as orientation. My RequestInformation looks like this: //Reading basic information //Reading in the extent from the file int extent[6]; //storing the extent in the array vtkInformation* outInfo=outputVector->GetInformationObject(0); outInfo->Set(CAN_HANDLE_PIECE_REQUEST(),1); outInfo ->Set(vtkStreamingDemandDrivenPipeline::WHOLE_EXTENT(),extent,6); RequestData looks like this: vtkProcessModule *ParInfo; vtkInformation *outInfo = outputVector->GetInformationObject(0); vtkMultiBlockDataSet* multiBlock = vtkMultiBlockDataSet::SafeDownCast(outInfo->Get(vtkDataObject::DATA_OBJECT())); int subext[6]; outInfo->Get(vtkStreamingDemandDrivenPipeline::UPDATE_EXTENT(),subext); cout<<"Num of Processors = "<GetNumberOfLocalPartitions()<GetPartitionId() << " " <Get(vtkStreamingDemandDrivenPipeline::UPDATE_EXTENT(),subext);" should produce the sub-extent for the rank or am i wrong? What am I doing wrong, or what do I have to do to get the sub-extent? Thank you very much in advance, Markus Moser Markus Moser Student assistant Chair of Fluid Mechanics and Institute of Aerodynamics W?llnerstra?e 5a RWTH Aachen University 52062 Aachen Germany -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Tue May 30 10:30:48 2017 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Tue, 30 May 2017 10:30:48 -0400 Subject: [Paraview-developers] Parallel structured grid reader doesn"t produce subextent In-Reply-To: <1496097056093.19755@rwth-aachen.de> References: <1496097056093.19755@rwth-aachen.de> Message-ID: Use * outInfo->Set(CAN_PRODUCE_SUB_EXTENT(), 1) * instead of *outInfo->Set(CAN_HANDLE_PIECE_REQUEST(),1)*. Alternatively, you can create a *vtkExtentTranslator* instance yourself in RequestData to convert *UPDATE_PIECE_NUMBER(), UPDATE_NUMBER_OF_PIECES() * to sub-extents in *RequestData*. The latter may be better since it looks like your reader is producing a vtkMultiBlockDataSet. If I remember correctly, the extent-based request only works for structured datasets eg. vtkStructuredGrid, vtkImageData etc. Utkarsh On Tue, May 30, 2017 at 10:08 AM, Mizael Moser, Markus Klaus < markus.moser at rwth-aachen.de> wrote: > Dear ParaView developers, > > I'm having trouble to parallelize my ParaView reader plugin. I want to > read HDF5 files and the grid is a structured grid. The plugin works > perfectly fine if run in serial, and if i run it in parallel the solution > is also correct but instead of dividing the dataset in x subsets, it reads > the whole dataset x times(for each processor 1 time). > > > I found the wiki for a structured grid parallel reader ( > http://www.paraview.org/Wiki/Writing_ParaView_Readers) and used it as > orientation. > > > My RequestInformation looks like this: > > > //Reading basic information > > //Reading in the extent from the file > > int extent[6]; > > //storing the extent in the array > > vtkInformation* outInfo=outputVector->GetInformationObject(0); > > outInfo->Set(CAN_HANDLE_PIECE_REQUEST(),1); > > outInfo ->Set(vtkStreamingDemandDrivenPipeline::WHOLE_EXTENT(),extent,6); > > > > RequestData looks like this: > > > vtkProcessModule *ParInfo; > vtkInformation *outInfo = outputVector->GetInformationObject(0); > vtkMultiBlockDataSet* multiBlock = vtkMultiBlockDataSet:: > SafeDownCast(outInfo->Get(vtkDataObject::DATA_OBJECT())); > > int subext[6]; > outInfo->Get(vtkStreamingDemandDrivenPipeline::UPDATE_EXTENT(),subext); > > cout<<"Num of Processors = "<GetNumberOfLocalPartitions()< > cout<< "subext from rank"<< ParInfo->GetPartitionId() << " " > < > //Reading the grid and the data-set > > Lets say the extent is 50x120x150 and i start the server with > mpirun -np 2 pvs and connecting the client i get the following "output": > > Num of Processors = 2 > Num of Processors = 2 > subext from rank0 0 50 0 120 0 150 > subext from rank1 0 50 0 120 0 150 > But at the end the Dataset is still visualized correctly. > > > Normally "outInfo->Get(vtkStreamingDemandDrivenPipeline::UPDATE_EXTENT(),subext);" > should produce the sub-extent for the rank or am i wrong? > > What am I doing wrong, or what do I have to do to get the sub-extent? > > > Thank you very much in advance, > Markus Moser > > > Markus Moser > Student assistant > > Chair of Fluid Mechanics and Institute of Aerodynamics > > W?llnerstra?e 5a > RWTH Aachen University > > 52062 Aachen > Germany > > > > > > > _______________________________________________ > 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: From kriolog at gmail.com Tue May 30 23:59:15 2017 From: kriolog at gmail.com (Maxim Torgonskiy) Date: Tue, 30 May 2017 23:59:15 -0400 Subject: [Paraview-developers] Paraview offscreen rendering and graphical unit tests Message-ID: Hello, I need to launch paraview graphical tests in a docker image (debian stretch). I'm trying to perform this with osmesa and I use its custom version from the manual (http://www.paraview.org/Wiki/ParaView/ParaView_And_Mesa_3D) as well as the libosmesa6-dev package. When I launch ctest with the default paraview test directory, the 800 (rendering-related) tests from 2100 are failed. When I use cdash config from https://open.cdash.org/buildSummary.php?buildid=4918000 the situation is approximately the same. If it's possible, could you please share me the missing part of the puzzle (your current docker image, custom test direcrory [/home/kitware/Dashboards/MyTests/ExternalData], etc) so that I can repeat the result presented on the cdash board? And is there any method to check that osmesa actually works in docker itself and with paraview. A quick google search gives me nothing. Thanks, Maxim From jfavre at cscs.ch Wed May 31 05:33:07 2017 From: jfavre at cscs.ch (Favre Jean) Date: Wed, 31 May 2017 09:33:07 +0000 Subject: [Paraview-developers] OSPRay Based Volume rendering Message-ID: <0EB9B6375711A04B820E6B6F5CCA9F68438ED03A@MBX111.d.ethz.ch> I am showing some vtkImageData grid, using PV5.4 RC3. Using "Smart" mode, the Scalar Opacity Unit slider works well. Switching to "OSPRay Based" mode, that same slider has no more effect, and I don't see any GUI setting to change the sampling rate. Should there be any? Jean From shawn.waldon at kitware.com Wed May 31 09:44:11 2017 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Wed, 31 May 2017 09:44:11 -0400 Subject: [Paraview-developers] Paraview offscreen rendering and graphical unit tests In-Reply-To: References: Message-ID: Hi Maxim, The dashboard machine amber8 isn't a docker container. It is Ubuntu machine with an OSMesa built according to the instructions on the wiki. It would help if you would share the errors you are getting from the tests so we have a better idea of what is going wrong. Without having any hint what is wrong it is hard to guess. A way to test if your OSMesa is working in Docker? Try running `ctest -R vtkRendering` and see if those tests pass. If they do, then OSMesa is working and something else is going wrong. HTH, Shawn On Tue, May 30, 2017 at 11:59 PM, Maxim Torgonskiy wrote: > Hello, > > I need to launch paraview graphical tests in a docker image (debian > stretch). I'm trying to perform this with osmesa and I use its custom > version from the manual > (http://www.paraview.org/Wiki/ParaView/ParaView_And_Mesa_3D) as well > as the libosmesa6-dev package. When I launch ctest with the default > paraview test directory, the 800 (rendering-related) tests from 2100 > are failed. When I use cdash config from > https://open.cdash.org/buildSummary.php?buildid=4918000 the situation > is approximately the same. > If it's possible, could you please share me the missing part of the > puzzle (your current docker image, custom test direcrory > [/home/kitware/Dashboards/MyTests/ExternalData], etc) so that I can > repeat the result presented on the cdash board? And is there any > method to check that osmesa actually works in docker itself and with > paraview. A quick google search gives me nothing. > > Thanks, > Maxim > _______________________________________________ > 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: From joseph.g.hennessey2.ctr at mail.mil Wed May 31 13:28:40 2017 From: joseph.g.hennessey2.ctr at mail.mil (Hennessey, Joseph G CTR USARMY RDECOM ARL (US)) Date: Wed, 31 May 2017 17:28:40 +0000 Subject: [Paraview-developers] Problem with superbuild for ParaView 5.4.0-RC3 and non internet attached systems Message-ID: <10A03274360DCF47A6EE78C9952A31CA91EA192D@UCOLHPUD.easf.csd.disa.mil> Hello, I have noticed that for vtk-m, in the superbuild, there is no longer a compressed file for download, instead there is only a git repository. This will cause problems for those of us building on systems without Internet access, as we will no longer be able to use previously downloaded versions on those systems without Internet access. (this is also the case for the aculsolve reader as well) Thanks, Joe ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Joseph G. Hennessey Ph.D., SAIC Team SAIC Army Research Lab DOD Supercomputing Resource Center -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5615 bytes Desc: not available URL: From kriolog at gmail.com Wed May 31 23:48:39 2017 From: kriolog at gmail.com (Maxim Torgonskiy) Date: Wed, 31 May 2017 23:48:39 -0400 Subject: [Paraview-developers] Paraview offscreen rendering and graphical unit tests In-Reply-To: References: Message-ID: Thanks Shawn, I've launched 'ctest -R vtkRendering' in my docker image and it works (99% tests passed, 1 tests failed out of 257). The only failed test is ' 789 - vtkRenderingCoreCxx-TestFollowerPicking (Failed)'. If someone finds this helpful, I've build it in the docker debian:stretch with the system llvm-dev, mesa 13.0.3 and paraview 5.3.0 (release from archive). The configuration arguments are the following: mesa (identical to wiki): =================================== CXXFLAGS="-O2 -g -DDEFAULT_SOFTWARE_DEPTH_BITS=31" \ CFLAGS="-O2 -g -DDEFAULT_SOFTWARE_DEPTH_BITS=31" \ --disable-xvmc \ --disable-glx \ --disable-dri \ --with-dri-drivers="" \ --with-gallium-drivers="swrast" \ --disable-shared-glapi \ --disable-egl \ --with-egl-platforms="" \ --enable-gallium-osmesa \ --enable-gallium-llvm=yes \ --enable-llvm-shared-libs \ --disable-gles1 \ --disable-gles2 \ --prefix=$installdir =================================== paraview: =================================== -DCMAKE_BUILD_TYPE:STRING=Release \ -DCMAKE_INSTALL_PREFIX:PATH=$installdir \ -DBUILD_SHARED_LIBS:BOOL=ON \ -DBUILD_TESTING:BOOL=ON \ \# -DPARAVIEW_ENABLE_PYTHON:BOOL=ON \ -DPARAVIEW_ENABLE_PYTHON:BOOL=OFF \ -DPARAVIEW_ENABLE_WEB:BOOL=OFF \ -DPARAVIEW_BUILD_QT_GUI:BOOL=OFF \ -DPARAVIEW_BUILD_PLUGIN_GMVReader:BOOL=OFF \ -DVTK_USE_X:BOOL=OFF \ -DOPENGL_INCLUDE_DIR:PATH= \ -DOPENGL_gl_LIBRARY:FILEPATH= \ -DOPENGL_glu_LIBRARY:FILEPATH= \ -DVTK_OPENGL_HAS_OSMESA:BOOL=ON \ -DOSMESA_INCLUDE_DIR:PATH=$installdir_osmesa/include \ -DOSMESA_LIBRARY:FILEPATH=$installdir_osmesa/lib/libOSMesa.so =================================== Thanks, Maxim 2017-05-31 9:44 GMT-04:00 Shawn Waldon : > Hi Maxim, > > The dashboard machine amber8 isn't a docker container. It is Ubuntu machine > with an OSMesa built according to the instructions on the wiki. > > It would help if you would share the errors you are getting from the tests > so we have a better idea of what is going wrong. Without having any hint > what is wrong it is hard to guess. > > A way to test if your OSMesa is working in Docker? Try running `ctest -R > vtkRendering` and see if those tests pass. If they do, then OSMesa is > working and something else is going wrong. > > HTH, > Shawn > > On Tue, May 30, 2017 at 11:59 PM, Maxim Torgonskiy > wrote: >> >> Hello, >> >> I need to launch paraview graphical tests in a docker image (debian >> stretch). I'm trying to perform this with osmesa and I use its custom >> version from the manual >> (http://www.paraview.org/Wiki/ParaView/ParaView_And_Mesa_3D) as well >> as the libosmesa6-dev package. When I launch ctest with the default >> paraview test directory, the 800 (rendering-related) tests from 2100 >> are failed. When I use cdash config from >> https://open.cdash.org/buildSummary.php?buildid=4918000 the situation >> is approximately the same. >> If it's possible, could you please share me the missing part of the >> puzzle (your current docker image, custom test direcrory >> [/home/kitware/Dashboards/MyTests/ExternalData], etc) so that I can >> repeat the result presented on the cdash board? And is there any >> method to check that osmesa actually works in docker itself and with >> paraview. A quick google search gives me nothing. >> >> Thanks, >> Maxim >> _______________________________________________ >> 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 > >