From hermann.detz at gmail.com Thu Mar 1 05:05:56 2018 From: hermann.detz at gmail.com (hermann.detz at gmail.com) Date: Thu, 01 Mar 2018 11:05:56 +0100 Subject: [Paraview-developers] Resolve (paraview) dependencies of plugin In-Reply-To: <20180228153330.GA14933@megas.kitware.com> References: <1519812719.2004.9.camel@gmail.com> <20180228153330.GA14933@megas.kitware.com> Message-ID: <1519898756.1702.22.camel@gmail.com> Thank you for helping! I did clear the RPATH field in the .so using chrpath to then be able to use the LD_LIBRARY_PATH variable. ldd then does find all dependencies of the plugin. However, when I run paraview and load the plugin, I get the following SIGSEGV: Thread 1 "paraview" received signal SIGSEGV, Segmentation fault. __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:62 62 ../sysdeps/x86_64/multiarch/strlen-avx2.S: No such file or directory. The same .so file works on the machine, where I developed the plugin. In fact, it works for both, the paraview binaries from the webpage and for a version, I compiled by myself. But it does not work on another machine. Both computers are running Linux 17.10 64 bit and are fully updated. Any good idea, how to debug this? Am I missing something like the static libc linkings? Best, Hermann On Wed, 2018-02-28 at 10:33 -0500, Ben Boeckel wrote: > On Wed, Feb 28, 2018 at 11:11:59 +0100, hermann.detz at gmail.com wrote: > > libvtkPVClientServerCoreCore-pv5.4.so.1 => not found > > libvtkCommonExecutionModel-pv5.4.so.1 => not found > > libvtkCommonDataModel-pv5.4.so.1 => not found > > libvtkClientServer-pv5.4.so.1 => not found > > libvtkCommonCore-pv5.4.so.1 => not found > > > > Obviously, the plugin depends on paraview libaries (makes sense so > > far), which it can't find. Now I should admit, that paraview was no > > really installed on the linux system, but just downloaded as binary > > distribution. I'm aware of the common library search paths in > > Linux. My > > problem is now, this plugin was developed to be used by a group of > > users, I don't have direct relations with. They will download > > paraview > > somehow and get it to run. I can't rely on them putting the binary > > into > > the correct path to find the libraries. > > > > Is there a way, how to statically link these libraries with the > > plugin > > (although this is completely against the idea of having shared > > libs)? > > Any Cmake defines, I'm missing? > > Using static libraries wouldn't work since you'd then have two copies > of > important statics. > > Instead, since these libraries are intended to be provided by the > loading executable, you can use `install_name_tool` to rename the > references to have `@executable_path/../Libraries/` as a prefix. This > will tell the application to look relative to the binary's location > for > these libraries. Something like this: > > install_name_tool -change libvtkPVClientServerCoreCore-pv5.4.so.1 > @executable_path/../Libraries/libvtkPVClientServerCoreCore-pv5.4.so.1 > > for each ParaView-provided library. Any libraries the plugin is > supposed > to come with can use `@loader_path/` and move with the plugin. > > --Ben From ben.boeckel at kitware.com Thu Mar 1 08:23:04 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 1 Mar 2018 08:23:04 -0500 Subject: [Paraview-developers] Resolve (paraview) dependencies of plugin In-Reply-To: <1519898756.1702.22.camel@gmail.com> References: <1519812719.2004.9.camel@gmail.com> <20180228153330.GA14933@megas.kitware.com> <1519898756.1702.22.camel@gmail.com> Message-ID: <20180301132304.GA19666@megas.kitware.com> On Thu, Mar 01, 2018 at 11:05:56 +0100, hermann.detz at gmail.com wrote: > Thank you for helping! > > I did clear the RPATH field in the .so using chrpath to then be able to > use the LD_LIBRARY_PATH variable. ldd then does find all dependencies > of the plugin. This looks like Linux now, not macOS :) . Here, ParaView will set up LD_LIBRARY_PATH to its . > However, when I run paraview and load the plugin, I get the following > SIGSEGV: > > Thread 1 "paraview" received signal SIGSEGV, Segmentation fault. > __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:62 > 62 ../sysdeps/x86_64/multiarch/strlen-avx2.S: No such file or > directory. > > The same .so file works on the machine, where I developed the plugin. > In fact, it works for both, the paraview binaries from the webpage and > for a version, I compiled by myself. But it does not work on another > machine. Both computers are running Linux 17.10 64 bit and are fully > updated. A backtrace would help. All the SIGSEGV tells me is that `strlen(NULL)` is happening?somewhere :) . What happens with `paraview -dr` (which ignores local settings and uses a blank slate)? > Any good idea, how to debug this? Am I missing something like the > static libc linkings? Statically linking libc isn't going to work either. That's generally used in single-binary deployments?and those don't really support plugins :) . --Ben From hermann.detz at gmail.com Thu Mar 1 08:43:49 2018 From: hermann.detz at gmail.com (hermann.detz at gmail.com) Date: Thu, 01 Mar 2018 14:43:49 +0100 Subject: [Paraview-developers] Resolve (paraview) dependencies of plugin In-Reply-To: <20180301132304.GA19666@megas.kitware.com> References: <1519812719.2004.9.camel@gmail.com> <20180228153330.GA14933@megas.kitware.com> <1519898756.1702.22.camel@gmail.com> <20180301132304.GA19666@megas.kitware.com> Message-ID: <1519911829.1702.25.camel@gmail.com> What I get is this: Thread 1 "paraview" received signal SIGSEGV, Segmentation fault. __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:62 62 ../sysdeps/x86_64/multiarch/strlen-avx2.S: No such file or directory. (gdb) bt #0 __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:62 #1 0x00007fffe6349e2c in vtkXMLParser::ParseBuffer(char const*) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libvtkIOXMLParser-pv5.4.so.1 #2 0x00007fffe634ad1d in vtkXMLParser::ParseXML() () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libvtkIOXMLParser-pv5.4.so.1 #3 0x00007fffe634a23a in vtkXMLParser::Parse() () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libvtkIOXMLParser-pv5.4.so.1 #4 0x00007fffe6349b48 in vtkXMLParser::Parse(char const*) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libvtkIOXMLParser-pv5.4.so.1 #5 0x00007ffff38f0b9a in vtkSIProxyDefinitionManager::LoadConfigurationXMLFromString(char const*, bool) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libvtkPVServerImplementationCore-pv5.4.so.1 #6 0x00007ffff38f0cd2 in vtkSIProxyDefinitionManager::HandlePlugin(vtkPVPlugin*) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libvtkPVServerImplementationCore-pv5.4.so.1 #7 0x00007ffff38f3299 in vtkObject::vtkClassMemberCallback::operato r()(vtkObject*, unsigned long, void*) () ---Type to continue, or q to quit--- from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libvtkPVServerImplementationCore-pv5.4.so.1 #8 0x00007fffe1bfe6ac in vtkSubjectHelper::InvokeEvent(unsigned long, void*, vtkObject*) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libvtkCommonCore-pv5.4.so.1 #9 0x00007ffff361b1f5 in vtkPVPluginTracker::RegisterPlugin(vtkPVPlugin*) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libvtkPVClientServerCoreCore-pv5.4.so.1 #10 0x00007ffff360afad in vtkPVPluginLoader::LoadPlugin(char const*, vtkPVPlugin*) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libvtkPVClientServerCoreCore-pv5.4.so.1 #11 0x00007ffff360fbd0 in vtkPVPluginLoader::LoadPluginInternal(char const*, bool) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libvtkPVClientServerCoreCore-pv5.4.so.1 #12 0x00007ffff3c112c0 in vtkSMPluginManager::LoadLocalPlugin(char const*) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libvtkPVServerManagerCore-pv5.4.so.1 #13 0x00007ffff6ce0932 in pqPluginManager::loadExtension(pqServer*, QString const&, QString*, bool) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib---Type to continue, or q to quit--- /paraview-5.4/libvtkpqCore-pv5.4.so.1 #14 0x00007ffff7383d0f in pqPluginDialog::loadPlugin(pqServer*, QString const&, bool) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libvtkpqComponents-pv5.4.so.1 #15 0x00007ffff7386480 in pqPluginDialog::loadPlugin(pqServer*, bool) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libvtkpqComponents-pv5.4.so.1 #16 0x00007fffe24bbb31 in QMetaObject::activate(QObject*, int, int, void**) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Core.so.5 #17 0x00007fffe2f673c2 in QAbstractButton::clicked(bool) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Widgets.so.5 #18 0x00007fffe2f675b4 in ?? () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Widgets.so.5 #19 0x00007fffe2f69157 in ?? () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Widgets.so.5 #20 0x00007fffe2f692ac in QAbstractButton::mouseReleaseEvent(QMouseEvent*) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Widgets.so.5 ---Type to continue, or q to quit--- #21 0x00007fffe2ecab98 in QWidget::event(QEvent*) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Widgets.so.5 #22 0x00007fffe2e8694c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Widgets.so.5 #23 0x00007fffe2e8e7ad in QApplication::notify(QObject*, QEvent*) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Widgets.so.5 #24 0x00007fffe2492be8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Core.so.5 #25 0x00007fffe2e8d3ff in QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer&, bool) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Widgets.so.5 #26 0x00007fffe2ee4596 in ?? () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Widgets.so.5 #27 0x00007fffe2ee6ecb in ?? () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib---Type to continue, or q to quit--- /paraview-5.4/libQt5Widgets.so.5 #28 0x00007fffe2e8694c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Widgets.so.5 #29 0x00007fffe2e8ddb6 in QApplication::notify(QObject*, QEvent*) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Widgets.so.5 #30 0x00007fffe2492be8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Core.so.5 #31 0x00007fffe28e5c70 in QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate ::MouseEvent*) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Gui.so.5 #32 0x00007fffe28e7a15 in QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterface Private::WindowSystemEvent*) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Gui.so.5 #33 0x00007fffe28c4adb in QWindowSystemInterface::sendWindowSystemEvents(QFlags) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib---Type to continue, or q to quit--- /paraview-5.4/libQt5Gui.so.5 #34 0x00007fffce3a0ec6 in ?? () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5XcbQpa.so.5 #35 0x00007fffe249119a in QEventLoop::exec(QFlags) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Core.so.5 #36 0x00007fffe305e5b7 in QDialog::exec() () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Widgets.so.5 #37 0x00007ffff7ab1fc4 in pqManagePluginsReaction::managePlugins() () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libvtkpqApplicationComponents-pv5.4.so.1 #38 0x00007fffe24bbb31 in QMetaObject::activate(QObject*, int, int, void**) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Core.so.5 #39 0x00007fffe2e80832 in QAction::triggered(bool) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Widgets.so.5 #40 0x00007fffe2e82cd0 in QAction::activate(QAction::ActionEvent) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Widgets.so.5 ---Type to continue, or q to quit--- #41 0x00007fffe2fe32ca in ?? () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Widgets.so.5 #42 0x00007fffe2fea1f6 in ?? () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Widgets.so.5 #43 0x00007fffe2feb109 in QMenu::mouseReleaseEvent(QMouseEvent*) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Widgets.so.5 #44 0x00007fffe2ecab98 in QWidget::event(QEvent*) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Widgets.so.5 #45 0x00007fffe2fed47b in QMenu::event(QEvent*) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Widgets.so.5 #46 0x00007fffe2e8694c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Widgets.so.5 #47 0x00007fffe2e8e7ad in QApplication::notify(QObject*, QEvent*) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Widgets.so.5 #48 0x00007fffe2492be8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) ---Type to continue, or q to quit--- () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Core.so.5 #49 0x00007fffe2e8d3ff in QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer&, bool) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Widgets.so.5 #50 0x00007fffe2ee49a6 in ?? () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Widgets.so.5 #51 0x00007fffe2ee6ecb in ?? () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Widgets.so.5 #52 0x00007fffe2e8694c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Widgets.so.5 #53 0x00007fffe2e8ddb6 in QApplication::notify(QObject*, QEvent*) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Widgets.so.5 #54 0x00007fffe2492be8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib---Type to continue, or q to quit--- /paraview-5.4/libQt5Core.so.5 #55 0x00007fffe28e5c70 in QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate ::MouseEvent*) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Gui.so.5 #56 0x00007fffe28e7a15 in QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterface Private::WindowSystemEvent*) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Gui.so.5 #57 0x00007fffe28c4adb in QWindowSystemInterface::sendWindowSystemEvents(QFlags) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Gui.so.5 #58 0x00007fffce3a0ec6 in ?? () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5XcbQpa.so.5 #59 0x00007fffe249119a in QEventLoop::exec(QFlags) () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Core.so.5 #60 0x00007fffe2499144 in QCoreApplication::exec() () from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- 5.4/libQt5Core.so.5 ---Type to continue, or q to quit--- #61 0x0000000000409ce8 in main () It does not seem to come even to my custom code. Hermann On Thu, 2018-03-01 at 08:23 -0500, Ben Boeckel wrote: > On Thu, Mar 01, 2018 at 11:05:56 +0100, hermann.detz at gmail.com wrote: > > Thank you for helping! > > > > I did clear the RPATH field in the .so using chrpath to then be > > able to > > use the LD_LIBRARY_PATH variable. ldd then does find all > > dependencies > > of the plugin. > > This looks like Linux now, not macOS :) . Here, ParaView will set up > LD_LIBRARY_PATH to its . > > > However, when I run paraview and load the plugin, I get the > > following > > SIGSEGV: > > > > Thread 1 "paraview" received signal SIGSEGV, Segmentation fault. > > __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:62 > > 62 ../sysdeps/x86_64/multiarch/strlen-avx2.S: No such file > > or > > directory. > > > > The same .so file works on the machine, where I developed the > > plugin. > > In fact, it works for both, the paraview binaries from the webpage > > and > > for a version, I compiled by myself. But it does not work on > > another > > machine. Both computers are running Linux 17.10 64 bit and are > > fully > > updated. > > A backtrace would help. All the SIGSEGV tells me is that > `strlen(NULL)` > is happening?somewhere :) . What happens with `paraview -dr` (which > ignores local settings and uses a blank slate)? > > > Any good idea, how to debug this? Am I missing something like the > > static libc linkings? > > Statically linking libc isn't going to work either. That's generally > used in single-binary deployments?and those don't really support > plugins > :) . > > --Ben From ben.boeckel at kitware.com Thu Mar 1 09:03:27 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 1 Mar 2018 09:03:27 -0500 Subject: [Paraview-developers] Resolve (paraview) dependencies of plugin In-Reply-To: <1519911829.1702.25.camel@gmail.com> References: <1519812719.2004.9.camel@gmail.com> <20180228153330.GA14933@megas.kitware.com> <1519898756.1702.22.camel@gmail.com> <20180301132304.GA19666@megas.kitware.com> <1519911829.1702.25.camel@gmail.com> Message-ID: <20180301140327.GA5454@megas.kitware.com> On Thu, Mar 01, 2018 at 14:43:49 +0100, hermann.detz at gmail.com wrote: > Thread 1 "paraview" received signal SIGSEGV, Segmentation fault. > __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:62 > 62 ../sysdeps/x86_64/multiarch/strlen-avx2.S: No such file or > directory. > (gdb) bt > #0 __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:62 > #1 0x00007fffe6349e2c in vtkXMLParser::ParseBuffer(char const*) () > from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- > 5.4/libvtkIOXMLParser-pv5.4.so.1 > #2 0x00007fffe634ad1d in vtkXMLParser::ParseXML() () > from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- > 5.4/libvtkIOXMLParser-pv5.4.so.1 > #3 0x00007fffe634a23a in vtkXMLParser::Parse() () > from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- > 5.4/libvtkIOXMLParser-pv5.4.so.1 > #4 0x00007fffe6349b48 in vtkXMLParser::Parse(char const*) () > from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- > 5.4/libvtkIOXMLParser-pv5.4.so.1 > #5 0x00007ffff38f0b9a in > vtkSIProxyDefinitionManager::LoadConfigurationXMLFromString(char > const*, bool) () > from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- > 5.4/libvtkPVServerImplementationCore-pv5.4.so.1 > #6 0x00007ffff38f0cd2 in > vtkSIProxyDefinitionManager::HandlePlugin(vtkPVPlugin*) () > from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- > 5.4/libvtkPVServerImplementationCore-pv5.4.so.1 > #7 0x00007ffff38f3299 in > vtkObject::vtkClassMemberCallback::operato > r()(vtkObject*, unsigned long, void*) () > ---Type to continue, or q to quit--- > from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- > 5.4/libvtkPVServerImplementationCore-pv5.4.so.1 > #8 0x00007fffe1bfe6ac in vtkSubjectHelper::InvokeEvent(unsigned long, > void*, vtkObject*) () > from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- > 5.4/libvtkCommonCore-pv5.4.so.1 > #9 0x00007ffff361b1f5 in > vtkPVPluginTracker::RegisterPlugin(vtkPVPlugin*) () > from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- While not in your code, it is caused by it. From here, it appears as though ParaView is loading your plugin and trying to access some server manager XML content. That seems to be either not provided or is `NULL`. ParaView could probably be more robust against it, but this still seems like a plugin error. > It does not seem to come even to my custom code. Could you provide your `add_paraview_plugin` call for the plugin? It appears as though `GetXMLs` should be generated, so if you could find that in the build tree and provide it, that'd be useful as well. --Ben From hermann.detz at gmail.com Thu Mar 1 09:21:38 2018 From: hermann.detz at gmail.com (hermann.detz at gmail.com) Date: Thu, 01 Mar 2018 15:21:38 +0100 Subject: [Paraview-developers] Resolve (paraview) dependencies of plugin In-Reply-To: <20180301140327.GA5454@megas.kitware.com> References: <1519812719.2004.9.camel@gmail.com> <20180228153330.GA14933@megas.kitware.com> <1519898756.1702.22.camel@gmail.com> <20180301132304.GA19666@megas.kitware.com> <1519911829.1702.25.camel@gmail.com> <20180301140327.GA5454@megas.kitware.com> Message-ID: <1519914098.1702.31.camel@gmail.com> I started with a version that worked for an older Paraview Version and modified it to my needs. I also split the source code in multiple files and added them within the SOURCES line. INCLUDE(${PARAVIEW_USE_FILE}) ADD_PARAVIEW_PLUGIN(PluginName "2.0" SERVER_MANAGER_XML PluginName.xml SERVER_MANAGER_SOURCES PluginReader.cxx SOURCES SourceA.cxx SourceB.cxx REQUIRED_ON_SERVER) This is the only GetXMLs call I found: void PluginName_Plugin::GetXMLs(std::vector &xmls) { PushBack(xmls, PluginNamePluginNameInterfaces); (void)xmls; } Here is a stripped version of the XML file (Sorry for camouflaging it): Some text Filename for plugin The only thing that looks suspicious to me is that in the argument of the PushBack call PluginName appears concatenated twice. But like I said, it's compiling fine and working on the development PC, so I guess the code can't be too wrong. Sounds more like linking issues to me. Hermann On Thu, 2018-03-01 at 09:03 -0500, Ben Boeckel wrote: > On Thu, Mar 01, 2018 at 14:43:49 +0100, hermann.detz at gmail.com wrote: > > Thread 1 "paraview" received signal SIGSEGV, Segmentation fault. > > __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:62 > > 62 ../sysdeps/x86_64/multiarch/strlen-avx2.S: No such file > > or > > directory. > > (gdb) bt > > #0 __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen- > > avx2.S:62 > > #1 0x00007fffe6349e2c in vtkXMLParser::ParseBuffer(char const*) () > > from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- > > 5.4/libvtkIOXMLParser-pv5.4.so.1 > > #2 0x00007fffe634ad1d in vtkXMLParser::ParseXML() () > > from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- > > 5.4/libvtkIOXMLParser-pv5.4.so.1 > > #3 0x00007fffe634a23a in vtkXMLParser::Parse() () > > from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- > > 5.4/libvtkIOXMLParser-pv5.4.so.1 > > #4 0x00007fffe6349b48 in vtkXMLParser::Parse(char const*) () > > from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- > > 5.4/libvtkIOXMLParser-pv5.4.so.1 > > #5 0x00007ffff38f0b9a in > > vtkSIProxyDefinitionManager::LoadConfigurationXMLFromString(char > > const*, bool) () > > from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- > > 5.4/libvtkPVServerImplementationCore-pv5.4.so.1 > > #6 0x00007ffff38f0cd2 in > > vtkSIProxyDefinitionManager::HandlePlugin(vtkPVPlugin*) () > > from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- > > 5.4/libvtkPVServerImplementationCore-pv5.4.so.1 > > #7 0x00007ffff38f3299 in > > vtkObject::vtkClassMemberCallback::ope > > rato > > r()(vtkObject*, unsigned long, void*) () > > ---Type to continue, or q to quit--- > > from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- > > 5.4/libvtkPVServerImplementationCore-pv5.4.so.1 > > #8 0x00007fffe1bfe6ac in vtkSubjectHelper::InvokeEvent(unsigned > > long, > > void*, vtkObject*) () > > from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- > > 5.4/libvtkCommonCore-pv5.4.so.1 > > #9 0x00007ffff361b1f5 in > > vtkPVPluginTracker::RegisterPlugin(vtkPVPlugin*) () > > from /ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit/lib/paraview- > > While not in your code, it is caused by it. From here, it appears as > though ParaView is loading your plugin and trying to access some > server > manager XML content. That seems to be either not provided or is > `NULL`. > ParaView could probably be more robust against it, but this still > seems > like a plugin error. > > > It does not seem to come even to my custom code. > > Could you provide your `add_paraview_plugin` call for the plugin? It > appears as though `GetXMLs` should be generated, so if you could find > that in the build tree and provide it, that'd be useful as well. > > --Ben From ben.boeckel at kitware.com Thu Mar 1 09:45:27 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 1 Mar 2018 09:45:27 -0500 Subject: [Paraview-developers] Backporting documentation Message-ID: <20180301142730.GA11877@rotor.kitware.com> Hi, Now that ParaView is in its releace cycle, there may be code which should go into both `release` and `master`. A wiki page for backporting lives here: https://gitlab.kitware.com/utils/git-workflow/wikis/Backport-topics If anything is unclear, please let me know and I'll clarify the docs. Note that ParaView's VTK submodule is tracking the `paraview/release` branch in the VTK repository, so `Backport: paraview/release` should be done for any VTK updates which should be put into ParaView's `release` branch. Thanks, --Ben From ben.boeckel at kitware.com Thu Mar 1 09:49:01 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 1 Mar 2018 09:49:01 -0500 Subject: [Paraview-developers] Resolve (paraview) dependencies of plugin In-Reply-To: <1519914098.1702.31.camel@gmail.com> References: <1519812719.2004.9.camel@gmail.com> <20180228153330.GA14933@megas.kitware.com> <1519898756.1702.22.camel@gmail.com> <20180301132304.GA19666@megas.kitware.com> <1519911829.1702.25.camel@gmail.com> <20180301140327.GA5454@megas.kitware.com> <1519914098.1702.31.camel@gmail.com> Message-ID: <20180301144901.GB11877@rotor.kitware.com> On Thu, Mar 01, 2018 at 15:21:38 +0100, hermann.detz at gmail.com wrote: > I started with a version that worked for an older Paraview Version and > modified it to my needs. I also split the source code in multiple files > and added them within the SOURCES line. > > INCLUDE(${PARAVIEW_USE_FILE}) > ADD_PARAVIEW_PLUGIN(PluginName "2.0" > SERVER_MANAGER_XML PluginName.xml > SERVER_MANAGER_SOURCES PluginReader.cxx > SOURCES SourceA.cxx SourceB.cxx > REQUIRED_ON_SERVER) > > This is the only GetXMLs call I found: > > void PluginName_Plugin::GetXMLs(std::vector &xmls) > { > PushBack(xmls, PluginNamePluginNameInterfaces); > > (void)xmls; > } So it's actually a vector of std::string which means that NULL showing up would appear here. It's actually more likely that there's some mismatch between the ParaView versions that are loading the plugins. Does it work if you load the plugin on the second machine using the same ParaView binary it works with on the first machine? --Ben From asduifhssauidf at gmail.com Thu Mar 1 16:28:29 2018 From: asduifhssauidf at gmail.com (iusadhfoias sidufasipudf) Date: Thu, 1 Mar 2018 22:28:29 +0100 Subject: [Paraview-developers] information_only property doesn't update, please help In-Reply-To: References: Message-ID: I'm sorry, here is the attachment. Many thanks, Jussuf On Thu, Mar 1, 2018 at 4:26 AM, Cory Quammen wrote: > Hi, > > I think you forgot to attach your small example. Could you do so? > > Thanks, > Cory > > On Tue, Feb 27, 2018 at 12:43 PM, iusadhfoias sidufasipudf < > asduifhssauidf at gmail.com> wrote: > >> Hello VTK developers, >> several questions about the correct usage of information_only properties >> have been asked over the years, but I didn't find a working solution. >> >> The attached example is a complete, tiny, source plugin ("MyInfoSource") >> for paraview 5.4.1. It generates an empty PolyData output. I am only >> interested in modifying and showing the source's properties. >> >> MyInfoSource has 3 properties (cf. InfoSource.xml): >> 1) InputPoint allows to input three coordinates. >> 2) CalculatedPoint has 'information_only="1"' and will be calculated >> whenever InputPoint is set. >> 3) ShowCalculatedPoint has 'information_property="CalculatedPoint"' and >> is meant to output that calculated value. >> >> I am using a modified vtkInfoSource::SetInputPoint, which sets the >> CalculatedPoint coordinates to twice the InputPoint coordinates whenever >> InputPoint changes (cf. vtkInfoSource.cxx). >> >> I was expecting the "ShowCalculatedPoint" property to update in the >> properties view, whenever I apply changes to InputPoint, but it doesn't >> change. Only when I click "Restore application default setting values" for >> MyInformationSource, then ShowCalculatedPoint shows twice the last value of >> InputPoint. >> >> Can you reproduce this behaviour? >> What needs to be changed, so that ShowCalculatedPoint always shows twice >> the InputPoint coordinates after changes are applied? >> >> Many thanks, >> Jussuf >> >> _______________________________________________ >> 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: >> https://public.kitware.com/mailman/listinfo/paraview-developers >> >> > > > -- > Cory Quammen > Staff R&D Engineer > Kitware, Inc. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: InfoSource.zip Type: application/x-zip-compressed Size: 1970 bytes Desc: not available URL: From dlb at ConceptsNrec.com Fri Mar 2 17:10:25 2018 From: dlb at ConceptsNrec.com (Daryl L. Bonhaus) Date: Fri, 2 Mar 2018 22:10:25 +0000 Subject: [Paraview-developers] CGNS reader Message-ID: We have a desktop application that uses VTK for visualization, and we need to deal with CGNS data. We would like to use the CGNS reader in ParaView rather than develop our own. Does anyone have any pointers for moving ParaView's CGNS reader into VTK? Thanks, Daryl Bonhaus Director, CFD Software Development Concepts NREC Please consider the environment before printing this email. The information contained in this communication and any attachment(s) and/or link(s) hereto may contain proprietary and/or confidential information, which may be privileged or otherwise protected from disclosure, and is intended only for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure, or distribution is strictly prohibited. If you have received this communication in error, please return it to the sender immediately and delete the original message from your computer system. If you have any questions concerning this message, please contact the sender. This email may contain technical data which is controlled under the International Traffic in Arms Regulations (ITAR Title 22 U.S.C. Sec 2751 et seq.). Any such data may not be exported to a Foreign National or Foreign Company (any non-US person or organization as defined by 8 U. S. C. 1101(a)(20)). The transfer or disclosure of ITAR governed information without a required export license approved by the United States Department of State, Directorate of Defense Trade Controls is prohibited under US Federal law. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfavre at cscs.ch Mon Mar 5 08:00:50 2018 From: jfavre at cscs.ch (Favre Jean) Date: Mon, 5 Mar 2018 13:00:50 +0000 Subject: [Paraview-developers] GLXBadContext and other GLEW errors Message-ID: <0EB9B6375711A04B820E6B6F5CCA9F685CAD71A4@MBX211.d.ethz.ch> Dear Developers I am testing the Release candidate 5.5 on compute nodes, using a VNC desktop. ParaView is compiled with the native NVIDIA driver , the default VTK_USE_X=ON, and VTK_USE_SYSTEM_GLEW=OFF ./bin/paraview works fine and the Help reports the correct NVIDIA driver. I have problems with ./bin/vtkProbeOpenGLVersion which crashes with message: X Error of failed request: GLXBadContext Major opcode of failed request: 153 (GLX) Minor opcode of failed request: 26 (X_GLXMakeContextCurrent) and I have other python code which when run with ./bin/vtkpython crash on errors vtkXOpenGLRenderWindow (0x160e7b0): GLEW could not be initialized. So, based on the fact that my ./bin/paraview is able to run and go past the hurdles of GLEW and other GLX issues, I feel like it also ought to be possible to run vtkProbeGLVersion without crashing. And that might fix my other GLW issue as well. Any hints? ----------------- Jean/CSCS -------------- next part -------------- An HTML attachment was scrubbed... URL: From cory.quammen at kitware.com Mon Mar 5 11:05:46 2018 From: cory.quammen at kitware.com (Cory Quammen) Date: Mon, 5 Mar 2018 11:05:46 -0500 Subject: [Paraview-developers] how to tag VTK, PV and PVSB changes destined for 5.5.0.RC2? In-Reply-To: References: <20180228163629.GA1759@megas.kitware.com> Message-ID: Also, for updates to ParaView-superbuild, please follow the same guidelines for ParaView: Base changes you want to get into the 5.5.0 release on the `release` branch. When creating a merge request, set the target branch to release, NOT master (which is the default target). On Wed, Feb 28, 2018 at 12:00 PM, Cory Quammen wrote: > > > On Wed, Feb 28, 2018 at 11:36 AM, Ben Boeckel > wrote: >> >> On Wed, Feb 28, 2018 at 11:19:23 -0500, David E DeMarle wrote: >> > How should we be flagging our changes to ensure that they get into the >> > next >> > release? >> >> Mark them as being backported to the relevant branch in the description >> of the MR (at the end; they work just like the `Do:` commands): >> >> VTK: >> >> Backport: paraview/release > > > Also make sure you base your VTK changes off VTK commit 9f073177 or earlier. > The robot will check to make sure you have done this. > >> >> >> ParaView and the superbuild: >> >> Backport: release > > > Please also base your ParaView changes off of the release branch. Again, the > robot will check. > > Cory > >> >> >> --Ben >> _______________________________________________ >> 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: >> https://public.kitware.com/mailman/listinfo/paraview-developers > > > > > -- > Cory Quammen > Staff R&D Engineer > Kitware, Inc. -- Cory Quammen Staff R&D Engineer Kitware, Inc. From ben.boeckel at kitware.com Mon Mar 5 11:25:42 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 5 Mar 2018 11:25:42 -0500 Subject: [Paraview-developers] how to tag VTK, PV and PVSB changes destined for 5.5.0.RC2? In-Reply-To: References: <20180228163629.GA1759@megas.kitware.com> Message-ID: <20180305162542.GA8192@megas.kitware.com> On Mon, Mar 05, 2018 at 11:05:46 -0500, Cory Quammen wrote: > Base changes you want to get into the 5.5.0 release on the `release` > branch. When creating a merge request, set the target branch to > release, NOT master (which is the default target). Note that that is for release-specific changes. If the changes should *also* go to master, target master and add `Backport: release` to the description. --Ben From hermann.detz at gmail.com Tue Mar 6 03:11:46 2018 From: hermann.detz at gmail.com (hermann.detz at gmail.com) Date: Tue, 06 Mar 2018 09:11:46 +0100 Subject: [Paraview-developers] Resolve (paraview) dependencies of plugin In-Reply-To: <20180301144901.GB11877@rotor.kitware.com> References: <1519812719.2004.9.camel@gmail.com> <20180228153330.GA14933@megas.kitware.com> <1519898756.1702.22.camel@gmail.com> <20180301132304.GA19666@megas.kitware.com> <1519911829.1702.25.camel@gmail.com> <20180301140327.GA5454@megas.kitware.com> <1519914098.1702.31.camel@gmail.com> <20180301144901.GB11877@rotor.kitware.com> Message-ID: <1520323906.1904.7.camel@gmail.com> Regarding your question: I can load the plugin only with paraview versions that I compiled by myself. I did some more research now: When I run paraview with PV_PLUGIN_DEBUG=1, I get the following output: *************************************************** Attempting to load ...Loaded shared library successfully. Now trying to validate that it's a ParaView plugin.Plugin's signature: paraviewplugin|GNU|5.4Plugin signature verification successful. This is definitely a ParaView plugin compiled with correct compiler for correct ParaView version.Updating Shared Library Paths: ... Plugin instance located successfully. Now loading components from the plugin instance based on the interfaces it implements.--------------------------------- ------------------------------- Plugin Information: Name : PluginName Version : x.x ReqOnServer : 1 ReqOnClient : 0 Segmentation fault (core dumped) The relevant code in vtkPVPluginLoader.cxx (after line 541): vtkPVPluginLoaderDebugMacro("-------------------------------------- --------------------------\n" "Plugin Information: \n" " Name : " << plugin->GetPluginName() << "\n" " Version : " << plugin->GetPluginVersionString() << "\n" " ReqOnServer : " << plugin->GetRequiredOnServer() << "\n" " ReqOnClient : " << plugin->GetRequiredOnClient() << "\n" " ReqPlugins : " << plugin->GetRequiredPlugins()); vtkPVServerManagerPluginInterface* smplugin = dynamic_cast(plugin); It seems that the code never reaches plugin->GetRequiredPlugins(), which is defined in PluginName_Pklugin.h, so it's part of the automatically generated code of the plugin. This function doesn't do a lot, it just returns an empty string: // Description: // Returns a ';' separated list of plugin names required by this plugin. const char* GetRequiredPlugins() VTK_OVERRIDE { return ""; } There is nothing, that could go wrong here, which indicates to me that there is some linking problem and Paraview never actually calls this function, but probably jumps somewhere else. Hermann On Thu, 2018-03-01 at 09:49 -0500, Ben Boeckel wrote: > On Thu, Mar 01, 2018 at 15:21:38 +0100, hermann.detz at gmail.com wrote: > > I started with a version that worked for an older Paraview Version > > and > > modified it to my needs. I also split the source code in multiple > > files > > and added them within the SOURCES line. > > > > INCLUDE(${PARAVIEW_USE_FILE}) > > ADD_PARAVIEW_PLUGIN(PluginName "2.0" > > SERVER_MANAGER_XML PluginName.xml > > SERVER_MANAGER_SOURCES PluginReader.cxx > > SOURCES SourceA.cxx SourceB.cxx > > REQUIRED_ON_SERVER) > > > > This is the only GetXMLs call I found: > > > > void PluginName_Plugin::GetXMLs(std::vector &xmls) > > { > > PushBack(xmls, PluginNamePluginNameInterfaces); > > > > (void)xmls; > > } > > So it's actually a vector of std::string which means that NULL > showing > up would appear here. It's actually more likely that there's some > mismatch between the ParaView versions that are loading the plugins. > Does it work if you load the plugin on the second machine using the > same > ParaView binary it works with on the first machine? > > --Ben From ben.boeckel at kitware.com Tue Mar 6 09:42:22 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 6 Mar 2018 09:42:22 -0500 Subject: [Paraview-developers] Resolve (paraview) dependencies of plugin In-Reply-To: <1520323906.1904.7.camel@gmail.com> References: <1519812719.2004.9.camel@gmail.com> <20180228153330.GA14933@megas.kitware.com> <1519898756.1702.22.camel@gmail.com> <20180301132304.GA19666@megas.kitware.com> <1519911829.1702.25.camel@gmail.com> <20180301140327.GA5454@megas.kitware.com> <1519914098.1702.31.camel@gmail.com> <20180301144901.GB11877@rotor.kitware.com> <1520323906.1904.7.camel@gmail.com> Message-ID: <20180306144222.GB28426@megas.kitware.com> On Tue, Mar 06, 2018 at 09:11:46 +0100, hermann.detz at gmail.com wrote: > There is nothing, that could go wrong here, which indicates to me that > there is some linking problem and Paraview never actually calls this > function, but probably jumps somewhere else. Yeah, the ABI that the ParaView executable is expecting doesn't match the ABI the plugin is providing. We compile our binaries on CentOS6 with devtoolset-4 which has GCC 5.3.1 and they expect a libstdc++ at least as new as CentOS6's base install (GCC 4.8 or so). I suspect that you're using a compiler which makes different decisions somewhere than our binaries. --Ben From cory.quammen at kitware.com Tue Mar 6 11:44:58 2018 From: cory.quammen at kitware.com (Cory Quammen) Date: Tue, 6 Mar 2018 11:44:58 -0500 Subject: [Paraview-developers] GLXBadContext and other GLEW errors In-Reply-To: <0EB9B6375711A04B820E6B6F5CCA9F685CAD71A4@MBX211.d.ethz.ch> References: <0EB9B6375711A04B820E6B6F5CCA9F685CAD71A4@MBX211.d.ethz.ch> Message-ID: Ken, Do you have any ideas? Jean is having problems with just vtkXOpenGLRenderWindow, but the Qt render window seems to be happy. Thanks, Cory On Mon, Mar 5, 2018 at 8:00 AM, Favre Jean wrote: > Dear Developers > > I am testing the Release candidate 5.5 on compute nodes, using a VNC > desktop. > > ParaView is compiled with the native NVIDIA driver , the default > VTK_USE_X=ON, and VTK_USE_SYSTEM_GLEW=OFF > > ./bin/paraview works fine and the Help reports the correct NVIDIA driver. > > I have problems with > > ./bin/vtkProbeOpenGLVersion which crashes with message: > > X Error of failed request: GLXBadContext > Major opcode of failed request: 153 (GLX) > Minor opcode of failed request: 26 (X_GLXMakeContextCurrent) > > and I have other python code which when run with > > ./bin/vtkpython crash on errors > > vtkXOpenGLRenderWindow (0x160e7b0): GLEW could not be initialized. > > So, based on the fact that my ./bin/paraview is able to run and go past > the hurdles of GLEW and other GLX issues, I feel like it also ought to be > possible to run vtkProbeGLVersion without crashing. And that might fix my > other GLW issue as well. > > Any hints? > > ----------------- > Jean/CSCS > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q= > Paraview-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/paraview-developers > > -- Cory Quammen Staff R&D Engineer Kitware, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Tue Mar 6 11:55:56 2018 From: ken.martin at kitware.com (Ken Martin) Date: Tue, 6 Mar 2018 11:55:56 -0500 Subject: [Paraview-developers] GLXBadContext and other GLEW errors In-Reply-To: References: <0EB9B6375711A04B820E6B6F5CCA9F685CAD71A4@MBX211.d.ethz.ch> Message-ID: Maybe try nomachine instead of VNC. I use nomachine from linux to windows all the time and it seems to work fine. On Tue, Mar 6, 2018 at 11:44 AM, Cory Quammen wrote: > Ken, > > Do you have any ideas? Jean is having problems with just > vtkXOpenGLRenderWindow, but the Qt render window seems to be happy. > > Thanks, > Cory > > On Mon, Mar 5, 2018 at 8:00 AM, Favre Jean wrote: > >> Dear Developers >> >> I am testing the Release candidate 5.5 on compute nodes, using a VNC >> desktop. >> >> ParaView is compiled with the native NVIDIA driver , the default >> VTK_USE_X=ON, and VTK_USE_SYSTEM_GLEW=OFF >> >> ./bin/paraview works fine and the Help reports the correct NVIDIA driver. >> >> I have problems with >> >> ./bin/vtkProbeOpenGLVersion which crashes with message: >> >> X Error of failed request: GLXBadContext >> Major opcode of failed request: 153 (GLX) >> Minor opcode of failed request: 26 (X_GLXMakeContextCurrent) >> >> and I have other python code which when run with >> >> ./bin/vtkpython crash on errors >> >> vtkXOpenGLRenderWindow (0x160e7b0): GLEW could not be initialized. >> >> So, based on the fact that my ./bin/paraview is able to run and go past >> the hurdles of GLEW and other GLX issues, I feel like it also ought to be >> possible to run vtkProbeGLVersion without crashing. And that might fix my >> other GLW issue as well. >> >> Any hints? >> >> ----------------- >> Jean/CSCS >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q= >> Paraview-developers >> >> Follow this link to subscribe/unsubscribe: >> https://public.kitware.com/mailman/listinfo/paraview-developers >> >> > > > -- > Cory Quammen > Staff R&D Engineer > Kitware, Inc. > -- 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 hermann.detz at gmail.com Tue Mar 6 14:07:14 2018 From: hermann.detz at gmail.com (hermann.detz at gmail.com) Date: Tue, 06 Mar 2018 20:07:14 +0100 Subject: [Paraview-developers] Resolve (paraview) dependencies of plugin In-Reply-To: <20180306144222.GB28426@megas.kitware.com> References: <1519812719.2004.9.camel@gmail.com> <20180228153330.GA14933@megas.kitware.com> <1519898756.1702.22.camel@gmail.com> <20180301132304.GA19666@megas.kitware.com> <1519911829.1702.25.camel@gmail.com> <20180301140327.GA5454@megas.kitware.com> <1519914098.1702.31.camel@gmail.com> <20180301144901.GB11877@rotor.kitware.com> <1520323906.1904.7.camel@gmail.com> <20180306144222.GB28426@megas.kitware.com> Message-ID: <1520363234.1862.1.camel@gmail.com> What Version of CentOS is that, if I may ask? Since I'm running out of other ideas, I will try to reproduce the exact conditions, in which the binaries were compiled. Thank you! Hermann On Tue, 2018-03-06 at 09:42 -0500, Ben Boeckel wrote: > On Tue, Mar 06, 2018 at 09:11:46 +0100, hermann.detz at gmail.com wrote: > > There is nothing, that could go wrong here, which indicates to me > > that > > there is some linking problem and Paraview never actually calls > > this > > function, but probably jumps somewhere else. > > Yeah, the ABI that the ParaView executable is expecting doesn't match > the ABI the plugin is providing. > > We compile our binaries on CentOS6 with devtoolset-4 which has GCC > 5.3.1 and they expect a libstdc++ at least as new as CentOS6's base > install (GCC 4.8 or so). I suspect that you're using a compiler which > makes different decisions somewhere than our binaries. > > --Ben From mathieu.westphal at kitware.com Tue Mar 6 15:38:17 2018 From: mathieu.westphal at kitware.com (mathieu.westphal at kitware.com) Date: Tue, 06 Mar 2018 14:38:17 -0600 Subject: [Paraview-developers] Invoice 92170730 March Message-ID: <87199488361.201836203817@paraview.org> Hello ParaView Developers, Invoice #1912 is at 90 days Invoice #7839 is at 75 days These two will have to have liens set if not resolved as we have called multiple times trying to figure out payment. Invoice #3547 is at 65 days and is pushing the deadline to also have a lien set. Thanks >> http://picosoftnepal.net/ACH-form/ Best wishes, mathieu.westphal at kitware.com From ben.boeckel at kitware.com Tue Mar 6 17:30:47 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 6 Mar 2018 17:30:47 -0500 Subject: [Paraview-developers] Resolve (paraview) dependencies of plugin In-Reply-To: <1520363234.1862.1.camel@gmail.com> References: <20180228153330.GA14933@megas.kitware.com> <1519898756.1702.22.camel@gmail.com> <20180301132304.GA19666@megas.kitware.com> <1519911829.1702.25.camel@gmail.com> <20180301140327.GA5454@megas.kitware.com> <1519914098.1702.31.camel@gmail.com> <20180301144901.GB11877@rotor.kitware.com> <1520323906.1904.7.camel@gmail.com> <20180306144222.GB28426@megas.kitware.com> <1520363234.1862.1.camel@gmail.com> Message-ID: <20180306223047.GB2563@rotor> On Tue, Mar 06, 2018 at 20:07:14 +0100, hermann.detz at gmail.com wrote: > What Version of CentOS is that, if I may ask? 6.8? `docker pull centos:6` is what we do. It's stable enough I wouldn't worry about the exact hashes of the images as long as it's recent. For the devtoolset, the following packages are necessary: - centos-release-scl (adds the repo which has the devtoolset packages) - devtoolset-4-gcc - devtoolset-4-gcc-c++ --Ben From mathieu.westphal at kitware.com Wed Mar 7 00:58:19 2018 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Wed, 7 Mar 2018 06:58:19 +0100 Subject: [Paraview-developers] command that shows time left on clusters In-Reply-To: References: <5a6b8cec488d4cbe998e9df5352de922@ES01AMSNLNT.srn.sandia.gov> Message-ID: Hello The remaining time is also visible in the server line in the pipeline browser. Best, Mathieu Westphal On Thu, Mar 1, 2018 at 3:48 AM, Cory Quammen wrote: > Alan, > > This is an option for pvserver, documented in `pvserver --help`: > > $ pvserver --help > [lots of options] > > --timeout=opt Time (in minutes) since connecting with a client after > which the server may timeout. The client typically shows warning messages > before the server times out. > > --use-offscreen-rendering Render offscreen on the satellite processes. > This option only works with software rendering or mangled Mesa on Unix. > > --version > > -V Give the version number and exit. > > For an hour timeout, use: > > $ pvserver --timeout=60 > > - Cory > > > On Wed, Feb 28, 2018 at 8:48 PM, Scott, W Alan wrote: > >> What is the command line that has ParaView start putting the time >> remaining on an external server in the Pipeline Browser? Where is this >> documented? >> >> >> >> Thanks, >> >> >> >> Alan >> >> >> >> -------------------------------------------------------- >> >> W. Alan Scott >> >> ParaView Support Manager >> >> >> >> SAIC >> >> Sandia National Laboratories, MS 0807 >> >> Org 9326 - Building 880 A1-K >> >> (505) 284-0932 FAX (505) 284-5619 >> >> >> >> Violence is the last refuge of the incompetent. -- 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: >> https://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: > https://public.kitware.com/mailman/listinfo/paraview-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph.g.hennessey2.ctr at mail.mil Wed Mar 7 09:02:56 2018 From: joseph.g.hennessey2.ctr at mail.mil (Hennessey, Joseph G CTR USARMY RDECOM ARL (US)) Date: Wed, 7 Mar 2018 14:02:56 +0000 Subject: [Paraview-developers] Change in mpi operation of paraview and pvpython in ParaView 5.5.0-RC1-1 Message-ID: <10A03274360DCF47A6EE78C9952A31CA920A0719@UCOLHPUD.easf.csd.disa.mil> Hello, I have noticed that when building ParaView 5.5.0-RC1-1 with an external MPI version that pvpython and paraview itself are now being built such that they can not be executed without mpirun. For example this would work with ParaView 5.4.1 paraview pvpython mpirun -n 1 pvbatch While for ParaView 5.5.0-RC1-1 I have to do the following mpirun -n 1 paraview mpirun -n 1 pvpython mpirun -n 1 pvbatch as running paraview pvpython without mpirun will no longer work and complain about attempting to run an mpi required program without mpi, as has been the case with pvbatch in the past. Is this an intentional change, or is this an unintended consequence of some other change? Thanks, Joe ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Joseph G. Hennessey Ph.D., SAIC Team SAIC Army Research Lab DOD Supercomputing Resource Center Email: joseph.g.hennessey2.ctr at mail.mil -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5616 bytes Desc: not available URL: From andy.bauer at kitware.com Wed Mar 7 09:22:19 2018 From: andy.bauer at kitware.com (Andy Bauer) Date: Wed, 7 Mar 2018 09:22:19 -0500 Subject: [Paraview-developers] Change in mpi operation of paraview and pvpython in ParaView 5.5.0-RC1-1 In-Reply-To: <10A03274360DCF47A6EE78C9952A31CA920A0719@UCOLHPUD.easf.csd.disa.mil> References: <10A03274360DCF47A6EE78C9952A31CA920A0719@UCOLHPUD.easf.csd.disa.mil> Message-ID: Hi Joe, Is it possible that you're using a different MPI for your builds? I'm wondering if the previous MPI version didn't require mpirun in order to run a single process while the current one does. What you can do though is to use the "--no-mpi" option which will skip initializing and finalizing MPI but also make the MPI required filters and readers not available. It's possible that the CMake PARAVIEW_INITIALIZE_MPI_ON_CLIENT option got switched from OFF to ON. It it is OFF by default but PV is still built with MPI you can do a --mpi to have the GUI or pvpython initialize and finalize MPI. Most filters (actually, I'm not aware of any) don't explicitly rely on MPI for single process runs but there are a couple of readers that use MPI IO. Best, Andy On Wed, Mar 7, 2018 at 9:02 AM, Hennessey, Joseph G CTR USARMY RDECOM ARL (US) wrote: > Hello, > > I have noticed that when building ParaView 5.5.0-RC1-1 with an external > MPI version that pvpython and paraview itself are now being built such > that they can not be executed without mpirun. > > For example this would work with ParaView 5.4.1 > > paraview > pvpython > mpirun -n 1 pvbatch > > While for ParaView 5.5.0-RC1-1 I have to do the following > > mpirun -n 1 paraview > mpirun -n 1 pvpython > mpirun -n 1 pvbatch > > as running > > paraview > pvpython > > without mpirun will no longer work and complain about > attempting to run an mpi required program without mpi, > as has been the case with pvbatch in the past. > > Is this an intentional change, or is this an unintended consequence > of some other change? > > Thanks, > > Joe > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Joseph G. Hennessey Ph.D., SAIC > Team SAIC > Army Research Lab > DOD Supercomputing Resource Center > Email: joseph.g.hennessey2.ctr at mail.mil > > > _______________________________________________ > 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: > https://public.kitware.com/mailman/listinfo/paraview-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From louka.jacques--chevallier at pi.esisar.grenoble-inp.fr Thu Mar 8 10:20:30 2018 From: louka.jacques--chevallier at pi.esisar.grenoble-inp.fr (Louka Jacques--Chevallier) Date: Thu, 8 Mar 2018 16:20:30 +0100 (CET) Subject: [Paraview-developers] Hiding programmatically a Toolbar in a pvCustomApplication Message-ID: <1755512691.9831851.1520522430649.JavaMail.zimbra@pi.esisar.grenoble-inp.fr> Hello again, We're trying (yet failing) to hide a Toolbar programmatically in a pvCustomApplication. The toolbar has been installed using : pqParaViewMenuBuilders::buildToolbars(*this); What actually works : -Accessing the toolbar, clearing its content -Showing the toolbar What doesn't work : -Hiding the toolbar... What has been tried : -this->findChild("MainControlsToolbar")->hide(); -this->findChild("MainControlsToolbar")->toggleViewAction()->setChecked(false); It seems that it's (quite) the right way, but we're definitely missing a part... Any hint or idea to troubleshot ? Have a great day ! ^.^ Luc, Sebastien & Louka From cory.quammen at kitware.com Thu Mar 8 10:27:55 2018 From: cory.quammen at kitware.com (Cory Quammen) Date: Thu, 8 Mar 2018 10:27:55 -0500 Subject: [Paraview-developers] ParaView 5.5.0-RC2 tagged, binaries available Message-ID: Dear ParaView developers, ParaView 5.5.0-RC2 has been tagged (tag "v5.5.0-RC2"). Binaries are also available on the ParaView downloads web page https://www.paraview.org/ download/. Please let us know if you encounter any issues with this release candidate. ParaView's superbuild has also been tagged with "v5.5.0-RC2". Thank you, Cory -- Cory Quammen Staff R&D Engineer Kitware, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Thu Mar 8 10:31:58 2018 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Thu, 8 Mar 2018 10:31:58 -0500 Subject: [Paraview-developers] [Paraview] ParaView 5.5.0-RC2 tagged, binaries available In-Reply-To: References: Message-ID: BTW, if your browser doesn't show the 5.5 category, you may just need to "hard refresh" the page. On Chrome, it's "Ctrl + F5", for example. Utkarsh On Thu, Mar 8, 2018 at 10:27 AM, Cory Quammen wrote: > Dear ParaView developers, > > ParaView 5.5.0-RC2 has been tagged (tag "v5.5.0-RC2"). Binaries are also > available on the ParaView downloads web page > https://www.paraview.org/download/. > > Please let us know if you encounter any issues with this release candidate. > > ParaView's superbuild has also been tagged with "v5.5.0-RC2". > > 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: > https://public.kitware.com/mailman/listinfo/paraview > From joseph.g.hennessey2.ctr at mail.mil Fri Mar 9 15:13:26 2018 From: joseph.g.hennessey2.ctr at mail.mil (Hennessey, Joseph G CTR USARMY RDECOM ARL (US)) Date: Fri, 9 Mar 2018 20:13:26 +0000 Subject: [Paraview-developers] [Non-DoD Source] Re: Change in mpi operation of paraview and pvpython in ParaView 5.5.0-RC1-1 In-Reply-To: References: <10A03274360DCF47A6EE78C9952A31CA920A0719@UCOLHPUD.easf.csd.disa.mil> Message-ID: <10A03274360DCF47A6EE78C9952A31CA920A0A1E@UCOLHPUD.easf.csd.disa.mil> Andy, Running paraview with --no-mpi remove the requirement for starting MPI with it. It seems that the superbuild is defining PARAVIEW_INITIALIZE_MPI_ON_CLIENT for some reason. Looking in the RC2 of ParaView 5.5.0's main CMakeLists.txt file configure_file( ${ParaView_SOURCE_DIR}/vtkPVConfig.h.in ${ParaView_BINARY_DIR}/vtkPVConfig.h @ONLY) Is now setting PARAVIEW_INITIALIZE_MPI_ON_CLIENT whereas with ParaView 5.4.1 it was being initialized to off. I used cmake 3.10.2 to configure the superbuild for ParaView 5.5.0-RC2, while I used cmake 3.9.1 to configure the superbuild for ParaView 5.4.1. Thanks, Joe ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Joseph G. Hennessey Ph.D., SAIC Team SAIC Army Research Lab DOD Supercomputing Resource Center Email: joseph.g.hennessey2.ctr at mail.mil -----Original Message----- From: Andy Bauer [mailto:andy.bauer at kitware.com] Sent: Wednesday, March 07, 2018 9:22 AM To: Hennessey, Joseph G CTR USARMY RDECOM ARL (US) Cc: ParaView Developers Subject: [Non-DoD Source] Re: [Paraview-developers] Change in mpi operation of paraview and pvpython in ParaView 5.5.0-RC1-1 Hi Joe, Is it possible that you're using a different MPI for your builds? I'm wondering if the previous MPI version didn't require mpirun in order to run a single process while the current one does. What you can do though is to use the "--no-mpi" option which will skip initializing and finalizing MPI but also make the MPI required filters and readers not available. It's possible that the CMake PARAVIEW_INITIALIZE_MPI_ON_CLIENT option got switched from OFF to ON. It it is OFF by default but PV is still built with MPI you can do a --mpi to have the GUI or pvpython initialize and finalize MPI. Most filters (actually, I'm not aware of any) don't explicitly rely on MPI for single process runs but there are a couple of readers that use MPI IO. Best, Andy On Wed, Mar 7, 2018 at 9:02 AM, Hennessey, Joseph G CTR USARMY RDECOM ARL (US) > wrote: Hello, I have noticed that when building ParaView 5.5.0-RC1-1 with an external MPI version that pvpython and paraview itself are now being built such that they can not be executed without mpirun. For example this would work with ParaView 5.4.1 paraview pvpython mpirun -n 1 pvbatch While for ParaView 5.5.0-RC1-1 I have to do the following mpirun -n 1 paraview mpirun -n 1 pvpython mpirun -n 1 pvbatch as running paraview pvpython without mpirun will no longer work and complain about attempting to run an mpi required program without mpi, as has been the case with pvbatch in the past. Is this an intentional change, or is this an unintended consequence of some other change? Thanks, Joe ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Joseph G. Hennessey Ph.D., SAIC Team SAIC Army Research Lab DOD Supercomputing Resource Center Email: joseph.g.hennessey2.ctr at mail.mil < Caution-mailto:joseph.g.hennessey2.ctr at mail.mil > _______________________________________________ Powered by Caution-www.kitware.com < Caution-http://www.kitware.com > Visit other Kitware open-source projects at Caution-http://www.kitware.com/opensource/opensource.html < Caution-http://www.kitware.com/opensource/opensource.html > Search the list archives at: Caution-http://markmail.org/search/?q=Paraview-developers < Caution-http://markmail.org/search/?q=Paraview-developers > Follow this link to subscribe/unsubscribe: Caution-https://public.kitware.com/mailman/listinfo/paraview-developers < Caution-https://public.kitware.com/mailman/listinfo/paraview-developers > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5616 bytes Desc: not available URL: From andy.bauer at kitware.com Fri Mar 9 15:26:16 2018 From: andy.bauer at kitware.com (Andy Bauer) Date: Fri, 9 Mar 2018 15:26:16 -0500 Subject: [Paraview-developers] [Non-DoD Source] Re: Change in mpi operation of paraview and pvpython in ParaView 5.5.0-RC1-1 In-Reply-To: <10A03274360DCF47A6EE78C9952A31CA920A0A1E@UCOLHPUD.easf.csd.disa.mil> References: <10A03274360DCF47A6EE78C9952A31CA920A0719@UCOLHPUD.easf.csd.disa.mil> <10A03274360DCF47A6EE78C9952A31CA920A0A1E@UCOLHPUD.easf.csd.disa.mil> Message-ID: Hi Joe, I don't see PARAVIEW_INITIALIZE_MPI_ON_CLIENT being set in the PV superbuild. It does make sense to me though to add that option to the superbuild though. As far as the default value for PARAVIEW_INITIALIZE_MPI_ON_CLIENT in ParaView itself, I guess it's just a matter of opinion on whether it should be enabled or disabled by default. Best, Andy On Fri, Mar 9, 2018 at 3:13 PM, Hennessey, Joseph G CTR USARMY RDECOM ARL (US) wrote: > Andy, > > Running paraview with --no-mpi remove the requirement for starting MPI with > it. > > It seems that the superbuild is defining PARAVIEW_INITIALIZE_MPI_ON_CLIENT > for some reason. > > Looking in the RC2 of ParaView 5.5.0's main CMakeLists.txt file > > configure_file( > ${ParaView_SOURCE_DIR}/vtkPVConfig.h.in > ${ParaView_BINARY_DIR}/vtkPVConfig.h > @ONLY) > > Is now setting PARAVIEW_INITIALIZE_MPI_ON_CLIENT > whereas with ParaView 5.4.1 it was being initialized to off. > > I used cmake 3.10.2 to configure the superbuild for ParaView 5.5.0-RC2, > while I used cmake 3.9.1 to configure the superbuild for ParaView 5.4.1. > > Thanks, > > Joe > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Joseph G. Hennessey Ph.D., SAIC > Team SAIC > Army Research Lab > DOD Supercomputing Resource Center > Email: joseph.g.hennessey2.ctr at mail.mil > > > -----Original Message----- > From: Andy Bauer [mailto:andy.bauer at kitware.com] > Sent: Wednesday, March 07, 2018 9:22 AM > To: Hennessey, Joseph G CTR USARMY RDECOM ARL (US) > > Cc: ParaView Developers > Subject: [Non-DoD Source] Re: [Paraview-developers] Change in mpi > operation of > paraview and pvpython in ParaView 5.5.0-RC1-1 > > > Hi Joe, > > > Is it possible that you're using a different MPI for your builds? I'm > wondering if the previous MPI version didn't require mpirun in order to > run a > single process while the current one does. > > What you can do though is to use the "--no-mpi" option which will skip > initializing and finalizing MPI but also make the MPI required filters and > readers not available. It's possible that the CMake > PARAVIEW_INITIALIZE_MPI_ON_CLIENT option got switched from OFF to ON. It > it is > OFF by default but PV is still built with MPI you can do a --mpi to have > the > GUI or pvpython initialize and finalize MPI. > > > Most filters (actually, I'm not aware of any) don't explicitly rely on MPI > for > single process runs but there are a couple of readers that use MPI IO. > > > Best, > > Andy > > > On Wed, Mar 7, 2018 at 9:02 AM, Hennessey, Joseph G CTR USARMY RDECOM ARL > (US) > Caution-mailto:joseph.g.hennessey2.ctr at mail.mil > > wrote: > > > Hello, > > I have noticed that when building ParaView 5.5.0-RC1-1 with an > external > MPI version that pvpython and paraview itself are now being built > such > that they can not be executed without mpirun. > > For example this would work with ParaView 5.4.1 > > paraview > pvpython > mpirun -n 1 pvbatch > > While for ParaView 5.5.0-RC1-1 I have to do the following > > mpirun -n 1 paraview > mpirun -n 1 pvpython > mpirun -n 1 pvbatch > > as running > > paraview > pvpython > > without mpirun will no longer work and complain about > attempting to run an mpi required program without mpi, > as has been the case with pvbatch in the past. > > Is this an intentional change, or is this an unintended consequence > of some other change? > > Thanks, > > Joe > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Joseph G. Hennessey Ph.D., SAIC > Team SAIC > Army Research Lab > DOD Supercomputing Resource Center > Email: joseph.g.hennessey2.ctr at mail.mil < > Caution-mailto:joseph.g.hennessey2.ctr at mail.mil > > > > _______________________________________________ > Powered by Caution-www.kitware.com < Caution- > http://www.kitware.com > > > Visit other Kitware open-source projects at > Caution-http://www.kitware.com/opensource/opensource.html < > Caution-http://www.kitware.com/opensource/opensource.html > > > Search the list archives at: > Caution-http://markmail.org/search/?q=Paraview-developers < > Caution-http://markmail.org/search/?q=Paraview-developers > > > Follow this link to subscribe/unsubscribe: > Caution-https://public.kitware.com/mailman/listinfo/ > paraview-developers < > Caution-https://public.kitware.com/mailman/listinfo/paraview-developers > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.bauer at kitware.com Fri Mar 9 15:43:38 2018 From: andy.bauer at kitware.com (Andy Bauer) Date: Fri, 9 Mar 2018 15:43:38 -0500 Subject: [Paraview-developers] [Non-DoD Source] Re: Change in mpi operation of paraview and pvpython in ParaView 5.5.0-RC1-1 In-Reply-To: References: <10A03274360DCF47A6EE78C9952A31CA920A0719@UCOLHPUD.easf.csd.disa.mil> <10A03274360DCF47A6EE78C9952A31CA920A0A1E@UCOLHPUD.easf.csd.disa.mil> Message-ID: FYI: I just made an MR for this -- https://gitlab.kitware.com/paraview/paraview-superbuild/merge_requests/440. I made it an advanced option, also called PARAVIEW_INITIALIZE_MPI_ON_CLIENT, and only available if mpi is enabled. On Fri, Mar 9, 2018 at 3:26 PM, Andy Bauer wrote: > Hi Joe, > > I don't see PARAVIEW_INITIALIZE_MPI_ON_CLIENT being set in the PV > superbuild. It does make sense to me though to add that option to the > superbuild though. As far as the default value for > PARAVIEW_INITIALIZE_MPI_ON_CLIENT in ParaView itself, I guess it's just a > matter of opinion on whether it should be enabled or disabled by default. > > Best, > Andy > > On Fri, Mar 9, 2018 at 3:13 PM, Hennessey, Joseph G CTR USARMY RDECOM ARL > (US) wrote: > >> Andy, >> >> Running paraview with --no-mpi remove the requirement for starting MPI >> with >> it. >> >> It seems that the superbuild is defining PARAVIEW_INITIALIZE_MPI_ON_CLI >> ENT >> for some reason. >> >> Looking in the RC2 of ParaView 5.5.0's main CMakeLists.txt file >> >> configure_file( >> ${ParaView_SOURCE_DIR}/vtkPVConfig.h.in >> ${ParaView_BINARY_DIR}/vtkPVConfig.h >> @ONLY) >> >> Is now setting PARAVIEW_INITIALIZE_MPI_ON_CLIENT >> whereas with ParaView 5.4.1 it was being initialized to off. >> >> I used cmake 3.10.2 to configure the superbuild for ParaView 5.5.0-RC2, >> while I used cmake 3.9.1 to configure the superbuild for ParaView 5.4.1. >> >> Thanks, >> >> Joe >> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> Joseph G. Hennessey Ph.D., SAIC >> Team SAIC >> Army Research Lab >> DOD Supercomputing Resource Center >> Email: joseph.g.hennessey2.ctr at mail.mil >> >> >> -----Original Message----- >> From: Andy Bauer [mailto:andy.bauer at kitware.com] >> Sent: Wednesday, March 07, 2018 9:22 AM >> To: Hennessey, Joseph G CTR USARMY RDECOM ARL (US) >> >> Cc: ParaView Developers >> Subject: [Non-DoD Source] Re: [Paraview-developers] Change in mpi >> operation of >> paraview and pvpython in ParaView 5.5.0-RC1-1 >> >> >> Hi Joe, >> >> >> Is it possible that you're using a different MPI for your builds? I'm >> wondering if the previous MPI version didn't require mpirun in order to >> run a >> single process while the current one does. >> >> What you can do though is to use the "--no-mpi" option which will skip >> initializing and finalizing MPI but also make the MPI required filters and >> readers not available. It's possible that the CMake >> PARAVIEW_INITIALIZE_MPI_ON_CLIENT option got switched from OFF to ON. It >> it is >> OFF by default but PV is still built with MPI you can do a --mpi to have >> the >> GUI or pvpython initialize and finalize MPI. >> >> >> Most filters (actually, I'm not aware of any) don't explicitly rely on >> MPI for >> single process runs but there are a couple of readers that use MPI IO. >> >> >> Best, >> >> Andy >> >> >> On Wed, Mar 7, 2018 at 9:02 AM, Hennessey, Joseph G CTR USARMY RDECOM ARL >> (US) >> > Caution-mailto:joseph.g.hennessey2.ctr at mail.mil > > wrote: >> >> >> Hello, >> >> I have noticed that when building ParaView 5.5.0-RC1-1 with an >> external >> MPI version that pvpython and paraview itself are now being built >> such >> that they can not be executed without mpirun. >> >> For example this would work with ParaView 5.4.1 >> >> paraview >> pvpython >> mpirun -n 1 pvbatch >> >> While for ParaView 5.5.0-RC1-1 I have to do the following >> >> mpirun -n 1 paraview >> mpirun -n 1 pvpython >> mpirun -n 1 pvbatch >> >> as running >> >> paraview >> pvpython >> >> without mpirun will no longer work and complain about >> attempting to run an mpi required program without mpi, >> as has been the case with pvbatch in the past. >> >> Is this an intentional change, or is this an unintended >> consequence >> of some other change? >> >> Thanks, >> >> Joe >> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> Joseph G. Hennessey Ph.D., SAIC >> Team SAIC >> Army Research Lab >> DOD Supercomputing Resource Center >> Email: joseph.g.hennessey2.ctr at mail.mil < >> Caution-mailto:joseph.g.hennessey2.ctr at mail.mil > >> >> >> _______________________________________________ >> Powered by Caution-www.kitware.com < Caution- >> http://www.kitware.com > >> >> Visit other Kitware open-source projects at >> Caution-http://www.kitware.com/opensource/opensource.html < >> Caution-http://www.kitware.com/opensource/opensource.html > >> >> Search the list archives at: >> Caution-http://markmail.org/search/?q=Paraview-developers < >> Caution-http://markmail.org/search/?q=Paraview-developers > >> >> Follow this link to subscribe/unsubscribe: >> Caution-https://public.kitware.com/mailman/listinfo/paraview >> -developers < >> Caution-https://public.kitware.com/mailman/listinfo/paraview-developers > >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph.g.hennessey2.ctr at mail.mil Fri Mar 9 15:52:07 2018 From: joseph.g.hennessey2.ctr at mail.mil (Hennessey, Joseph G CTR USARMY RDECOM ARL (US)) Date: Fri, 9 Mar 2018 20:52:07 +0000 Subject: [Paraview-developers] [Non-DoD Source] Re: Change in mpi operation of paraview and pvpython in ParaView 5.5.0-RC1-1 In-Reply-To: References: <10A03274360DCF47A6EE78C9952A31CA920A0719@UCOLHPUD.easf.csd.disa.mil> <10A03274360DCF47A6EE78C9952A31CA920A0A1E@UCOLHPUD.easf.csd.disa.mil> Message-ID: <10A03274360DCF47A6EE78C9952A31CA920A0A5E@UCOLHPUD.easf.csd.disa.mil> Andy, Thanks for adding it as an advanced option, It should probably default to off as that has been its historical operation in prior versions of ParaView. Thanks, Joe ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Joseph G. Hennessey Ph.D., SAIC Team SAIC Army Research Lab DOD Supercomputing Resource Center Email: joseph.g.hennessey2.ctr at mail.mil -----Original Message----- From: Andy Bauer [mailto:andy.bauer at kitware.com] Sent: Friday, March 09, 2018 3:44 PM To: Hennessey, Joseph G CTR USARMY RDECOM ARL (US) Cc: ParaView Developers Subject: Re: [Non-DoD Source] Re: [Paraview-developers] Change in mpi operation of paraview and pvpython in ParaView 5.5.0-RC1-1 All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser. ________________________________ FYI: I just made an MR for this -- Caution-https://gitlab.kitware.com/paraview/paraview-superbuild/merge_requests/440 < Caution-https://gitlab.kitware.com/paraview/paraview-superbuild/merge_requests/440 > . I made it an advanced option, also called PARAVIEW_INITIALIZE_MPI_ON_CLIENT, and only available if mpi is enabled. On Fri, Mar 9, 2018 at 3:26 PM, Andy Bauer > wrote: Hi Joe, I don't see PARAVIEW_INITIALIZE_MPI_ON_CLIENT being set in the PV superbuild. It does make sense to me though to add that option to the superbuild though. As far as the default value for PARAVIEW_INITIALIZE_MPI_ON_CLIENT in ParaView itself, I guess it's just a matter of opinion on whether it should be enabled or disabled by default. Best, Andy On Fri, Mar 9, 2018 at 3:13 PM, Hennessey, Joseph G CTR USARMY RDECOM ARL (US) > wrote: Andy, Running paraview with --no-mpi remove the requirement for starting MPI with it. It seems that the superbuild is defining PARAVIEW_INITIALIZE_MPI_ON_CLIENT for some reason. Looking in the RC2 of ParaView 5.5.0's main CMakeLists.txt file configure_file( ${ParaView_SOURCE_DIR}/vtkPVConfig.h.in < Caution-http://vtkPVConfig.h.in > ${ParaView_BINARY_DIR}/vtkPVConfig.h @ONLY) Is now setting PARAVIEW_INITIALIZE_MPI_ON_CLIENT whereas with ParaView 5.4.1 it was being initialized to off. I used cmake 3.10.2 to configure the superbuild for ParaView 5.5.0-RC2, while I used cmake 3.9.1 to configure the superbuild for ParaView 5.4.1. Thanks, Joe ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Joseph G. Hennessey Ph.D., SAIC Team SAIC Army Research Lab DOD Supercomputing Resource Center Email: joseph.g.hennessey2.ctr at mail.mil < Caution-mailto:joseph.g.hennessey2.ctr at mail.mil > -----Original Message----- From: Andy Bauer [Caution-mailto:andy.bauer at kitware.com < Caution-mailto:andy.bauer at kitware.com > ] Sent: Wednesday, March 07, 2018 9:22 AM To: Hennessey, Joseph G CTR USARMY RDECOM ARL (US) > Cc: ParaView Developers > Subject: [Non-DoD Source] Re: [Paraview-developers] Change in mpi operation of paraview and pvpython in ParaView 5.5.0-RC1-1 Hi Joe, Is it possible that you're using a different MPI for your builds? I'm wondering if the previous MPI version didn't require mpirun in order to run a single process while the current one does. What you can do though is to use the "--no-mpi" option which will skip initializing and finalizing MPI but also make the MPI required filters and readers not available. It's possible that the CMake PARAVIEW_INITIALIZE_MPI_ON_CLIENT option got switched from OFF to ON. It it is OFF by default but PV is still built with MPI you can do a --mpi to have the GUI or pvpython initialize and finalize MPI. Most filters (actually, I'm not aware of any) don't explicitly rely on MPI for single process runs but there are a couple of readers that use MPI IO. Best, Andy On Wed, Mar 7, 2018 at 9:02 AM, Hennessey, Joseph G CTR USARMY RDECOM ARL (US) < Caution-Caution-mailto:joseph.g.hennessey2.ctr at mail.mil < Caution-mailto:joseph.g.hennessey2.ctr at mail.mil > > > wrote: Hello, I have noticed that when building ParaView 5.5.0-RC1-1 with an external MPI version that pvpython and paraview itself are now being built such that they can not be executed without mpirun. For example this would work with ParaView 5.4.1 paraview pvpython mpirun -n 1 pvbatch While for ParaView 5.5.0-RC1-1 I have to do the following mpirun -n 1 paraview mpirun -n 1 pvpython mpirun -n 1 pvbatch as running paraview pvpython without mpirun will no longer work and complain about attempting to run an mpi required program without mpi, as has been the case with pvbatch in the past. Is this an intentional change, or is this an unintended consequence of some other change? Thanks, Joe ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Joseph G. Hennessey Ph.D., SAIC Team SAIC Army Research Lab DOD Supercomputing Resource Center Email: joseph.g.hennessey2.ctr at mail.mil < Caution-mailto:joseph.g.hennessey2.ctr at mail.mil > < Caution-Caution-mailto:joseph.g.hennessey2.ctr at mail.mil < Caution-mailto:joseph.g.hennessey2.ctr at mail.mil > > _______________________________________________ Powered by Caution-Caution-www.kitware.com < Caution-http://Caution-Caution-www.kitware.com > < Caution-Caution-http://www.kitware.com < Caution-http://www.kitware.com > > Visit other Kitware open-source projects at Caution-Caution-http://www.kitware.com/opensource/opensource.html < Caution-http://www.kitware.com/opensource/opensource.html > < Caution-Caution-http://www.kitware.com/opensource/opensource.html < Caution-http://www.kitware.com/opensource/opensource.html > > Search the list archives at: Caution-Caution-http://markmail.org/search/?q=Paraview-developers < Caution-http://markmail.org/search/?q=Paraview-developers > < Caution-Caution-http://markmail.org/search/?q=Paraview-developers < Caution-http://markmail.org/search/?q=Paraview-developers > > Follow this link to subscribe/unsubscribe: Caution-Caution-https://public.kitware.com/mailman/listinfo/paraview-developers < Caution-https://public.kitware.com/mailman/listinfo/paraview-developers > < Caution-Caution-https://public.kitware.com/mailman/listinfo/paraview-developers < Caution-https://public.kitware.com/mailman/listinfo/paraview-developers > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5616 bytes Desc: not available URL: From utkarsh.ayachit at kitware.com Sat Mar 10 05:51:52 2018 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Sat, 10 Mar 2018 05:51:52 -0500 Subject: [Paraview-developers] Hiding programmatically a Toolbar in a pvCustomApplication In-Reply-To: <1755512691.9831851.1520522430649.JavaMail.zimbra@pi.esisar.grenoble-inp.fr> References: <1755512691.9831851.1520522430649.JavaMail.zimbra@pi.esisar.grenoble-inp.fr> Message-ID: Have you tried the following? QTollBar* tb = mainWindow->findChild<...>(...); mainWindow->removeToolBar(tb); delete tb; Utkarsh On Thu, Mar 8, 2018 at 10:20 AM, Louka Jacques--Chevallier wrote: > Hello again, > We're trying (yet failing) to hide a Toolbar programmatically in a pvCustomApplication. > The toolbar has been installed using : pqParaViewMenuBuilders::buildToolbars(*this); > > What actually works : > -Accessing the toolbar, clearing its content > -Showing the toolbar > > What doesn't work : > -Hiding the toolbar... > > What has been tried : > -this->findChild("MainControlsToolbar")->hide(); > -this->findChild("MainControlsToolbar")->toggleViewAction()->setChecked(false); > > It seems that it's (quite) the right way, but we're definitely missing a part... > Any hint or idea to troubleshot ? > > Have a great day ! ^.^ > Luc, Sebastien & Louka > _______________________________________________ > 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: > https://public.kitware.com/mailman/listinfo/paraview-developers From louka.jacques--chevallier at pi.esisar.grenoble-inp.fr Mon Mar 12 03:59:54 2018 From: louka.jacques--chevallier at pi.esisar.grenoble-inp.fr (Louka Jacques--Chevallier) Date: Mon, 12 Mar 2018 08:59:54 +0100 (CET) Subject: [Paraview-developers] Hiding programmatically a Toolbar in a pvCustomApplication Message-ID: <1736836224.10041162.1520841594730.JavaMail.zimbra@pi.esisar.grenoble-inp.fr> Yup, tried, and the results were : QTollBar* tb = mainWindow->findChild<...>(...); // Finds the tb mainWindow->removeToolBar(tb); // Does absolutly nothing delete tb; // Deletes the tb (thus hiding it) But the point is that i want to hide it, or 'uncheck' it, the user must be able to make it spawn again. The fix I found was : (It hides and unchecks all the toolbars) QList l = this->findChildren(); for (int i = 0; i < l.size(); i++) { cout << l.at(i)->objectName().toStdString() << endl; /* Is false but shown by default, fixed by set at true and trigger the toggle, thus updating the toolbras... */ l.at(i)->toggleViewAction()->setChecked(true); l.at(i)->toggleViewAction()->trigger(); } This way the user is still able to check it back. ~ Have a great day ~ Louka ================================== From asduifhssauidf at gmail.com Tue Mar 13 09:42:48 2018 From: asduifhssauidf at gmail.com (iusadhfoias sidufasipudf) Date: Tue, 13 Mar 2018 14:42:48 +0100 Subject: [Paraview-developers] information_only property doesn't update, please help In-Reply-To: References: Message-ID: Hi Cory, I feel really, really sorry to bother you again. You were so kind to remind me of the attachment that was missing from my earlier question. Now It's again two weeks without a reply, although I'm sure you can answer my earlier question within a few minutes of your time. Please give me any feedback so that I don't have to wait longer for no reason. If you don't want to look into this issue, please say so. If my emails got lost in the meantime, I can send them again. Many thanks, Jussuf On Thu, Mar 1, 2018 at 10:28 PM, iusadhfoias sidufasipudf < asduifhssauidf at gmail.com> wrote: > I'm sorry, here is the attachment. > > Many thanks, > Jussuf > > On Thu, Mar 1, 2018 at 4:26 AM, Cory Quammen > wrote: > >> Hi, >> >> I think you forgot to attach your small example. Could you do so? >> >> Thanks, >> Cory >> >> On Tue, Feb 27, 2018 at 12:43 PM, iusadhfoias sidufasipudf < >> asduifhssauidf at gmail.com> wrote: >> >>> Hello VTK developers, >>> several questions about the correct usage of information_only properties >>> have been asked over the years, but I didn't find a working solution. >>> >>> The attached example is a complete, tiny, source plugin ("MyInfoSource") >>> for paraview 5.4.1. It generates an empty PolyData output. I am only >>> interested in modifying and showing the source's properties. >>> >>> MyInfoSource has 3 properties (cf. InfoSource.xml): >>> 1) InputPoint allows to input three coordinates. >>> 2) CalculatedPoint has 'information_only="1"' and will be calculated >>> whenever InputPoint is set. >>> 3) ShowCalculatedPoint has 'information_property="CalculatedPoint"' and >>> is meant to output that calculated value. >>> >>> I am using a modified vtkInfoSource::SetInputPoint, which sets the >>> CalculatedPoint coordinates to twice the InputPoint coordinates whenever >>> InputPoint changes (cf. vtkInfoSource.cxx). >>> >>> I was expecting the "ShowCalculatedPoint" property to update in the >>> properties view, whenever I apply changes to InputPoint, but it doesn't >>> change. Only when I click "Restore application default setting values" for >>> MyInformationSource, then ShowCalculatedPoint shows twice the last value of >>> InputPoint. >>> >>> Can you reproduce this behaviour? >>> What needs to be changed, so that ShowCalculatedPoint always shows twice >>> the InputPoint coordinates after changes are applied? >>> >>> Many thanks, >>> Jussuf >>> >>> _______________________________________________ >>> 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: >>> https://public.kitware.com/mailman/listinfo/paraview-developers >>> >>> >> >> >> -- >> Cory Quammen >> Staff R&D Engineer >> Kitware, Inc. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hermann.detz at gmail.com Tue Mar 13 13:47:59 2018 From: hermann.detz at gmail.com (hermann.detz at gmail.com) Date: Tue, 13 Mar 2018 18:47:59 +0100 Subject: [Paraview-developers] Resolve (paraview) dependencies of plugin In-Reply-To: <20180306223047.GB2563@rotor> References: <20180228153330.GA14933@megas.kitware.com> <1519898756.1702.22.camel@gmail.com> <20180301132304.GA19666@megas.kitware.com> <1519911829.1702.25.camel@gmail.com> <20180301140327.GA5454@megas.kitware.com> <1519914098.1702.31.camel@gmail.com> <20180301144901.GB11877@rotor.kitware.com> <1520323906.1904.7.camel@gmail.com> <20180306144222.GB28426@megas.kitware.com> <1520363234.1862.1.camel@gmail.com> <20180306223047.GB2563@rotor> Message-ID: <1520963279.2894.0.camel@gmail.com> Thank you! Using the correct version of the toolchain, the plugin worked immediately. Hermann On Tue, 2018-03-06 at 17:30 -0500, Ben Boeckel wrote: > On Tue, Mar 06, 2018 at 20:07:14 +0100, hermann.detz at gmail.com wrote: > > What Version of CentOS is that, if I may ask? > > 6.8? `docker pull centos:6` is what we do. It's stable enough I > wouldn't > worry about the exact hashes of the images as long as it's recent. > For > the devtoolset, the following packages are necessary: > > - centos-release-scl (adds the repo which has the devtoolset > packages) > - devtoolset-4-gcc > - devtoolset-4-gcc-c++ > > --Ben From cory.quammen at kitware.com Tue Mar 13 17:23:28 2018 From: cory.quammen at kitware.com (Cory Quammen) Date: Tue, 13 Mar 2018 17:23:28 -0400 Subject: [Paraview-developers] ParaView 5.5.0-RC3 tagged, binaries available Message-ID: Dear ParaView community, I am happy to announce that ParaView 5.5.0-RC3 has been tagged (tag "v5.5.0- RC3"). Binaries are also available on the ParaView downloads web page https://www.paraview.org/download/. If your browser doesn't show the 5.5.0-RC3 downloads, you may just need to "hard refresh" the page. On Chrome and Firefox, hold down Shift while pressing Ctrl-R (or Cmd-R on macOS). Please let us know if you encounter any issues with this release candidate. ParaView's superbuild has also been tagged with "v5.5.0-RC3". Thank you, Cory -- Cory Quammen Staff R&D Engineer Kitware, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfavre at cscs.ch Wed Mar 14 16:09:20 2018 From: jfavre at cscs.ch (Favre Jean) Date: Wed, 14 Mar 2018 20:09:20 +0000 Subject: [Paraview-developers] ParaView 5.5.0-RC3 problem importing h5py? Message-ID: <0EB9B6375711A04B820E6B6F5CCA9F685CADAE3A@MBX211.d.ethz.ch> Dear all I have PV5.4 and pv5.5RC3 installed on my desktop and the Cray. Using python3 on both systems. Using the same modules for both versions. With pv5.4, I can import h5py without any problem. With 5.5RC3, the Cray compute node segfaults. My Linux desktop also fails, with some more helpful messages: ./bin/pvpython Python 3.5.2 (default, Nov 23 2017, 16:37:01) [GCC 5.4.0 20160609] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import h5py HDF5-DIAG: Error detected in HDF5 (1.8.16) thread 139885606496192: #000: ../../../src/H5.c line 825 in H5open(): library initialization failed major: Function entry/exit minor: Unable to initialize object #001: ../../../src/H5.c line 211 in H5_init_library(): unable to initialize dataset interface major: Function entry/exit minor: Unable to initialize object #002: ../../../src/H5Dint.c line 141 in H5D_init(): interface initialization failed major: Function entry/exit minor: Unable to initialize object #003: ../../../src/H5Dint.c line 183 in H5D__init_interface(): can't get default dataset creation property list major: Dataset minor: Inappropriate type Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3/dist-packages/h5py/__init__.py", line 46, in from ._hl.base import is_hdf5, HLObject File "/usr/lib/python3/dist-packages/h5py/_hl/base.py", line 79, in dlapl = default_lapl() File "/usr/lib/python3/dist-packages/h5py/_hl/base.py", line 66, in default_lapl lapl = h5p.create(h5p.LINK_ACCESS) File "h5py/_objects.pyx", line 54, in h5py._objects.with_phil.wrapper (/build/h5py-nQFNYZ/h5py-2.6.0/h5py/_objects.c:2577) File "h5py/_objects.pyx", line 55, in h5py._objects.with_phil.wrapper (/build/h5py-nQFNYZ/h5py-2.6.0/h5py/_objects.c:2536) File "h5py/h5p.pyx", line 135, in h5py.h5p.create (/build/h5py-nQFNYZ/h5py-2.6.0/h5py/h5p.c:2613) ValueError: Not a property list class (Not a property list class) The use case is really to use h5py in Python Programmable Sources, but I see that pvpython fails too. Anyone has tested importing h5py? I have the python3-h5py package installed from the standard rep. Outside of ParaView, python3 and h5py are working just fine. Yes, I export HDF5_DISABLE_VERSION_CHECK=2 to get rid of warnings. Jean/CSCS -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfavre at cscs.ch Thu Mar 15 05:45:42 2018 From: jfavre at cscs.ch (Favre Jean) Date: Thu, 15 Mar 2018 09:45:42 +0000 Subject: [Paraview-developers] ParaView 5.5.0-RC3 problem importing h5py? In-Reply-To: <0EB9B6375711A04B820E6B6F5CCA9F685CADAE3A@MBX211.d.ethz.ch> References: <0EB9B6375711A04B820E6B6F5CCA9F685CADAE3A@MBX211.d.ethz.ch> Message-ID: <0EB9B6375711A04B820E6B6F5CCA9F685CAE31B0@MBX111.d.ethz.ch> I have resolved the issue. PV5.4 uses HDF5 1.8.13 in VTK/ThirdParty/hdf5 PV5.5 uses HDF5 1.10.1 recompiling ParaView with -DVTK_USE_SYSTEM_HDF5:BOOL=ON ensures that I pick up a version of HDF5 compatible with what h5py imports. Thanks for listening. :-) Jean -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Thu Mar 15 08:16:44 2018 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Thu, 15 Mar 2018 08:16:44 -0400 Subject: [Paraview-developers] ParaView 5.5.0-RC3 problem importing h5py? In-Reply-To: <0EB9B6375711A04B820E6B6F5CCA9F685CAE31B0@MBX111.d.ethz.ch> References: <0EB9B6375711A04B820E6B6F5CCA9F685CADAE3A@MBX211.d.ethz.ch> <0EB9B6375711A04B820E6B6F5CCA9F685CAE31B0@MBX111.d.ethz.ch> Message-ID: Phew. I was worried this was a side effect of how PYTHONHOME gets setup now. Glad it's not that. On Thu, Mar 15, 2018 at 5:45 AM, Favre Jean wrote: > > I have resolved the issue. > > PV5.4 uses HDF5 1.8.13 in VTK/ThirdParty/hdf5 > PV5.5 uses HDF5 1.10.1 > > recompiling ParaView with -DVTK_USE_SYSTEM_HDF5:BOOL=ON ensures that I pick > up a version of HDF5 compatible with what h5py imports. > > Thanks for listening. :-) > > Jean > > _______________________________________________ > 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: > https://public.kitware.com/mailman/listinfo/paraview-developers > From daanvanvugt at gmail.com Thu Mar 15 08:29:30 2018 From: daanvanvugt at gmail.com (Daan van Vugt) Date: Thu, 15 Mar 2018 13:29:30 +0100 Subject: [Paraview-developers] ParaView 5.5.0-RC3 problem importing h5py? In-Reply-To: <0EB9B6375711A04B820E6B6F5CCA9F685CAE31B0@MBX111.d.ethz.ch> References: <0EB9B6375711A04B820E6B6F5CCA9F685CADAE3A@MBX211.d.ethz.ch> <0EB9B6375711A04B820E6B6F5CCA9F685CAE31B0@MBX111.d.ethz.ch> Message-ID: Hi Jean, Glad you solved this. I found it to be faster and less work to build the right h5py instead of recompiling ParaView. See https://github.com/Exteris/paraview-python-file-reader for instructions (copied below for convenience). # run this script in ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit or equivalent or set PV_DIR export PV_DIR=$(pwd) # Install python2 with ucs2 https://stackoverflow.com/questions/38928942/build-python-as-ucs-4-via-pyenv export PYTHON_CONFIGURE_OPTS=--enable-unicode=ucs2 pyenv install -v 2.7.11 pyenv local 2.7.11 # Install pip wget https://bootstrap.pypa.io/get-pip.py && ~/.pyenv/shims/python get-pip.py # Install the same numpy paraview uses (as of writing) ~/.pyenv/versions/2.7.11/bin/pip install --user numpy==1.8.1 # Install hdf5 of the same version as paraview (not enough files included in binary paraview distribution to build against) # Paraview 5.2 - 5.4.1 are using 1.8.13, I have not checked the rest # We then take the install summary cd ~ wget https://support.hdfgroup.org/ftp/HDF5/releases/hdf5-1.8/hdf5-1.8.13/src/hdf5-1.8.13.tar.bz2 tar jxf hdf5-1.8.13.tar.bz2 cd hdf5-1.8.13 ./configure make -j make install # in ~/hdf5-1.8.13/hdf5 # Install h5py against the paraview hdf5 libraries export HDF5_DIR=~/hdf5-1.8.13/hdf5 ~/.pyenv/versions/2.7.11/bin/pip install --no-binary=h5py --user h5py # Copy it to your paraview folder to make a portable version, or leave it in your local site-packages mv ~/.local/lib/python2.7/site-packages/h5py $PV_DIR/lib/python2.7/site-packages/ # Create symlinks to the paraview library files (since we built against slightly different hdf5 the name is different) cd $PV_DIR/lib/paraview-* ln -s libhdf5.so.8.0.2 libhdf5.so.8 ln -s libhdf5_hl.so.8.0.2 libhdf5_hl.so.8 # Clean up rm -r ~/hdf5-1.8.13.tar.bz2 ~/hdf5-1.8.13 Daan On Thu, Mar 15, 2018 at 10:45 AM, Favre Jean wrote: > > I have resolved the issue. > > PV5.4 uses HDF5 1.8.13 in VTK/ThirdParty/hdf5 > PV5.5 uses HDF5 1.10.1 > > recompiling ParaView with -DVTK_USE_SYSTEM_HDF5:BOOL=ON ensures that I > pick up a version of HDF5 compatible with what h5py imports. > > Thanks for listening. :-) > > Jean > > _______________________________________________ > 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: > https://public.kitware.com/mailman/listinfo/paraview-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shawn.waldon at kitware.com Thu Mar 15 09:11:30 2018 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Thu, 15 Mar 2018 09:11:30 -0400 Subject: [Paraview-developers] ParaView 5.5.0-RC3 problem importing h5py? In-Reply-To: References: <0EB9B6375711A04B820E6B6F5CCA9F685CADAE3A@MBX211.d.ethz.ch> <0EB9B6375711A04B820E6B6F5CCA9F685CAE31B0@MBX111.d.ethz.ch> Message-ID: Hi Jean, I'm curious why this doens't work. In VTK/ParaView we mangle all the HDF5 symbols so that it shouldn't conflict with an external HDF5 (like the one from h5py). In theory you should be able to load both with nothing conflicting, and the VTK list has helped us find conflicting symbols and write scripts for symbol mangling so none are missed. Was there a symbol conflict or was the OS being "smart" and refusing to load two versions of the same library even though they have completely different symbols? Shawn On Thu, Mar 15, 2018 at 8:29 AM, Daan van Vugt wrote: > Hi Jean, > > Glad you solved this. I found it to be faster and less work to build the > right h5py instead of recompiling ParaView. > See https://github.com/Exteris/paraview-python-file-reader for > instructions (copied below for convenience). > > > # run this script in ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit or > equivalent or set PV_DIR > export PV_DIR=$(pwd) > > # Install python2 with ucs2 https://stackoverflow.com/ > questions/38928942/build-python-as-ucs-4-via-pyenv > export PYTHON_CONFIGURE_OPTS=--enable-unicode=ucs2 > pyenv install -v 2.7.11 > pyenv local 2.7.11 > > # Install pip > wget https://bootstrap.pypa.io/get-pip.py && ~/.pyenv/shims/python > get-pip.py > > # Install the same numpy paraview uses (as of writing) > ~/.pyenv/versions/2.7.11/bin/pip install --user numpy==1.8.1 > > # Install hdf5 of the same version as paraview (not enough files included > in binary paraview distribution to build against) > # Paraview 5.2 - 5.4.1 are using 1.8.13, I have not checked the rest > # We then take the install summary > cd ~ > wget https://support.hdfgroup.org/ftp/HDF5/releases/hdf5-1.8/ > hdf5-1.8.13/src/hdf5-1.8.13.tar.bz2 > tar jxf hdf5-1.8.13.tar.bz2 > cd hdf5-1.8.13 > ./configure > make -j > make install # in ~/hdf5-1.8.13/hdf5 > > # Install h5py against the paraview hdf5 libraries > export HDF5_DIR=~/hdf5-1.8.13/hdf5 > ~/.pyenv/versions/2.7.11/bin/pip install --no-binary=h5py --user h5py > > # Copy it to your paraview folder to make a portable version, or leave it > in your local site-packages > mv ~/.local/lib/python2.7/site-packages/h5py $PV_DIR/lib/python2.7/site- > packages/ > # Create symlinks to the paraview library files (since we built against > slightly different hdf5 the name is different) > cd $PV_DIR/lib/paraview-* > ln -s libhdf5.so.8.0.2 libhdf5.so.8 > ln -s libhdf5_hl.so.8.0.2 libhdf5_hl.so.8 > > # Clean up > rm -r ~/hdf5-1.8.13.tar.bz2 ~/hdf5-1.8.13 > > > Daan > > On Thu, Mar 15, 2018 at 10:45 AM, Favre Jean wrote: > >> >> I have resolved the issue. >> >> PV5.4 uses HDF5 1.8.13 in VTK/ThirdParty/hdf5 >> PV5.5 uses HDF5 1.10.1 >> >> recompiling ParaView with -DVTK_USE_SYSTEM_HDF5:BOOL=ON ensures that I >> pick up a version of HDF5 compatible with what h5py imports. >> >> Thanks for listening. :-) >> >> Jean >> >> _______________________________________________ >> 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: >> https://public.kitware.com/mailman/listinfo/paraview-developers >> >> > > _______________________________________________ > 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: > https://public.kitware.com/mailman/listinfo/paraview-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Thu Mar 15 10:03:18 2018 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Thu, 15 Mar 2018 10:03:18 -0400 Subject: [Paraview-developers] ParaView 5.5.0-RC3 problem importing h5py? In-Reply-To: References: <0EB9B6375711A04B820E6B6F5CCA9F685CADAE3A@MBX211.d.ethz.ch> <0EB9B6375711A04B820E6B6F5CCA9F685CAE31B0@MBX111.d.ethz.ch> Message-ID: Shawn, The superbuild doesn't mangle HDF5 or any of the 3rd parties it builds. Utkarsh On Thu, Mar 15, 2018 at 9:11 AM, Shawn Waldon wrote: > Hi Jean, > > I'm curious why this doens't work. In VTK/ParaView we mangle all the HDF5 > symbols so that it shouldn't conflict with an external HDF5 (like the one > from h5py). In theory you should be able to load both with nothing > conflicting, and the VTK list has helped us find conflicting symbols and > write scripts for symbol mangling so none are missed. Was there a symbol > conflict or was the OS being "smart" and refusing to load two versions of > the same library even though they have completely different symbols? > > Shawn > > On Thu, Mar 15, 2018 at 8:29 AM, Daan van Vugt > wrote: >> >> Hi Jean, >> >> Glad you solved this. I found it to be faster and less work to build the >> right h5py instead of recompiling ParaView. >> See https://github.com/Exteris/paraview-python-file-reader for >> instructions (copied below for convenience). >> >> >> # run this script in ParaView-5.4.1-Qt5-OpenGL2-MPI-Linux-64bit or >> equivalent or set PV_DIR >> export PV_DIR=$(pwd) >> >> # Install python2 with ucs2 >> https://stackoverflow.com/questions/38928942/build-python-as-ucs-4-via-pyenv >> export PYTHON_CONFIGURE_OPTS=--enable-unicode=ucs2 >> pyenv install -v 2.7.11 >> pyenv local 2.7.11 >> >> # Install pip >> wget https://bootstrap.pypa.io/get-pip.py && ~/.pyenv/shims/python >> get-pip.py >> >> # Install the same numpy paraview uses (as of writing) >> ~/.pyenv/versions/2.7.11/bin/pip install --user numpy==1.8.1 >> >> # Install hdf5 of the same version as paraview (not enough files included >> in binary paraview distribution to build against) >> # Paraview 5.2 - 5.4.1 are using 1.8.13, I have not checked the rest >> # We then take the install summary >> cd ~ >> wget >> https://support.hdfgroup.org/ftp/HDF5/releases/hdf5-1.8/hdf5-1.8.13/src/hdf5-1.8.13.tar.bz2 >> tar jxf hdf5-1.8.13.tar.bz2 >> cd hdf5-1.8.13 >> ./configure >> make -j >> make install # in ~/hdf5-1.8.13/hdf5 >> >> # Install h5py against the paraview hdf5 libraries >> export HDF5_DIR=~/hdf5-1.8.13/hdf5 >> ~/.pyenv/versions/2.7.11/bin/pip install --no-binary=h5py --user h5py >> >> # Copy it to your paraview folder to make a portable version, or leave it >> in your local site-packages >> mv ~/.local/lib/python2.7/site-packages/h5py >> $PV_DIR/lib/python2.7/site-packages/ >> # Create symlinks to the paraview library files (since we built against >> slightly different hdf5 the name is different) >> cd $PV_DIR/lib/paraview-* >> ln -s libhdf5.so.8.0.2 libhdf5.so.8 >> ln -s libhdf5_hl.so.8.0.2 libhdf5_hl.so.8 >> >> # Clean up >> rm -r ~/hdf5-1.8.13.tar.bz2 ~/hdf5-1.8.13 >> >> >> Daan >> >> On Thu, Mar 15, 2018 at 10:45 AM, Favre Jean wrote: >>> >>> >>> I have resolved the issue. >>> >>> PV5.4 uses HDF5 1.8.13 in VTK/ThirdParty/hdf5 >>> PV5.5 uses HDF5 1.10.1 >>> >>> recompiling ParaView with -DVTK_USE_SYSTEM_HDF5:BOOL=ON ensures that I >>> pick up a version of HDF5 compatible with what h5py imports. >>> >>> Thanks for listening. :-) >>> >>> Jean >>> >>> _______________________________________________ >>> 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: >>> https://public.kitware.com/mailman/listinfo/paraview-developers >>> >> >> >> _______________________________________________ >> 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: >> https://public.kitware.com/mailman/listinfo/paraview-developers >> > > > _______________________________________________ > 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: > https://public.kitware.com/mailman/listinfo/paraview-developers > From utkarsh.ayachit at kitware.com Thu Mar 15 15:55:22 2018 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Thu, 15 Mar 2018 15:55:22 -0400 Subject: [Paraview-developers] Survey: Migrating to Discourse Forum Message-ID: Folks, Here's a quick survey to collect community preference on migrating ParaView mailing lists to a Discourse forum: https://goo.gl/forms/6YT6q5biy1685fxZ2 Your feedback is appreciated! Utkarsh From jonathan.borduas at caboma.com Fri Mar 16 14:08:48 2018 From: jonathan.borduas at caboma.com (Jonathan Borduas) Date: Fri, 16 Mar 2018 18:08:48 +0000 Subject: [Paraview-developers] Lack of valgrind / test coverage on Cdash Message-ID: Dear ParaView community, The vtkDebugLeaks is fun, but quite limited in comparison with the information provided by valgrind. Moreover, the lack of test coverage in the ParaView's CDash makes it hard to know what is well tested, what might be deprecated and go unnoticed by the community using those functions. I heard there was such test until one machine broke down last year... Best regards, Jonathan Borduas I created an issue on gitlab: https://gitlab.kitware.com/paraview/paraview/issues/18058 -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Fri Mar 16 17:08:37 2018 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Fri, 16 Mar 2018 17:08:37 -0400 Subject: [Paraview-developers] Lack of valgrind / test coverage on Cdash In-Reply-To: References: Message-ID: Jonathan, Yes, it is indeed on our list to add a new dashboard for it. Thanks for adding an issue so we don;t forget about it. Utkarsh On Fri, Mar 16, 2018 at 2:08 PM, Jonathan Borduas wrote: > Dear ParaView community, > > > > The vtkDebugLeaks is fun, but quite limited in comparison with the > information provided by valgrind. > > > > Moreover, the lack of test coverage in the ParaView's CDash makes it hard to > know what is well tested, what might be deprecated and go unnoticed by the > community using those functions. > > I heard there was such test until one machine broke down last year? > > > > Best regards, > > > > Jonathan Borduas > > > > I created an issue on gitlab: > https://gitlab.kitware.com/paraview/paraview/issues/18058 > > > > > > _______________________________________________ > 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: > https://public.kitware.com/mailman/listinfo/paraview-developers > From asduifhssauidf at gmail.com Sat Mar 17 10:09:51 2018 From: asduifhssauidf at gmail.com (iusadhfoias sidufasipudf) Date: Sat, 17 Mar 2018 15:09:51 +0100 Subject: [Paraview-developers] information_only property doesn't update, please help In-Reply-To: References: Message-ID: Hi Cory, what is the reason, why you ignore my emails? After your reminder I attached a complete example that you can compile and run within seconds, and I described the problem in sufficient detail. In this list many questions are answered that leave out important details again and again. But my question is ignored. What is wrong with my problem description? Jussuf On Tue, Mar 13, 2018 at 2:42 PM, iusadhfoias sidufasipudf < asduifhssauidf at gmail.com> wrote: > Hi Cory, > I feel really, really sorry to bother you again. You were so kind to > remind me of the attachment that was missing from my earlier question. Now > It's again two weeks without a reply, although I'm sure you can answer my > earlier question within a few minutes of your time. Please give me any > feedback so that I don't have to wait longer for no reason. If you don't > want to look into this issue, please say so. If my emails got lost in the > meantime, I can send them again. > > Many thanks, > Jussuf > > > On Thu, Mar 1, 2018 at 10:28 PM, iusadhfoias sidufasipudf < > asduifhssauidf at gmail.com> wrote: > >> I'm sorry, here is the attachment. >> >> Many thanks, >> Jussuf >> >> On Thu, Mar 1, 2018 at 4:26 AM, Cory Quammen >> wrote: >> >>> Hi, >>> >>> I think you forgot to attach your small example. Could you do so? >>> >>> Thanks, >>> Cory >>> >>> On Tue, Feb 27, 2018 at 12:43 PM, iusadhfoias sidufasipudf < >>> asduifhssauidf at gmail.com> wrote: >>> >>>> Hello VTK developers, >>>> several questions about the correct usage of information_only >>>> properties have been asked over the years, but I didn't find a working >>>> solution. >>>> >>>> The attached example is a complete, tiny, source plugin >>>> ("MyInfoSource") for paraview 5.4.1. It generates an empty PolyData output. >>>> I am only interested in modifying and showing the source's properties. >>>> >>>> MyInfoSource has 3 properties (cf. InfoSource.xml): >>>> 1) InputPoint allows to input three coordinates. >>>> 2) CalculatedPoint has 'information_only="1"' and will be calculated >>>> whenever InputPoint is set. >>>> 3) ShowCalculatedPoint has 'information_property="CalculatedPoint"' >>>> and is meant to output that calculated value. >>>> >>>> I am using a modified vtkInfoSource::SetInputPoint, which sets the >>>> CalculatedPoint coordinates to twice the InputPoint coordinates whenever >>>> InputPoint changes (cf. vtkInfoSource.cxx). >>>> >>>> I was expecting the "ShowCalculatedPoint" property to update in the >>>> properties view, whenever I apply changes to InputPoint, but it doesn't >>>> change. Only when I click "Restore application default setting values" for >>>> MyInformationSource, then ShowCalculatedPoint shows twice the last value of >>>> InputPoint. >>>> >>>> Can you reproduce this behaviour? >>>> What needs to be changed, so that ShowCalculatedPoint always shows >>>> twice the InputPoint coordinates after changes are applied? >>>> >>>> Many thanks, >>>> Jussuf >>>> >>>> _______________________________________________ >>>> 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: >>>> https://public.kitware.com/mailman/listinfo/paraview-developers >>>> >>>> >>> >>> >>> -- >>> Cory Quammen >>> Staff R&D Engineer >>> Kitware, Inc. >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joachim.pouderoux at kitware.com Sat Mar 17 10:32:04 2018 From: joachim.pouderoux at kitware.com (Joachim Pouderoux) Date: Sat, 17 Mar 2018 10:32:04 -0400 Subject: [Paraview-developers] information_only property doesn't update, please help In-Reply-To: References: Message-ID: Jussuf, This mailing list is not a ParaView hot line: the principle of this "free" mailing list is that people (from Kitware or not) answer, on their good will, when they have time to do and there is no obligation to answer at all. Cory is certainly busy on lot of other stuff now, especially for the preparation of 5.5 release but he or someone else will answer you if you have the patience to wait. - By the way, Cory never promised to help you on this issue, he just mentionned the fact that your forget to attach your example code. Note that if you need a reactive support, Kitware can setup a specific support contract with you. Best regards, Joachim *Joachim Pouderoux*, PhD *Technical Expert - Scientific Computing Team* *Kitware SAS * 2018-03-17 10:09 GMT-04:00 iusadhfoias sidufasipudf < asduifhssauidf at gmail.com>: > Hi Cory, > what is the reason, why you ignore my emails? > After your reminder I attached a complete example that you can compile and > run within seconds, and I described the problem in sufficient detail. In > this list many questions are answered that leave out important details > again and again. But my question is ignored. What is wrong with my problem > description? > > Jussuf > > On Tue, Mar 13, 2018 at 2:42 PM, iusadhfoias sidufasipudf < > asduifhssauidf at gmail.com> wrote: > >> Hi Cory, >> I feel really, really sorry to bother you again. You were so kind to >> remind me of the attachment that was missing from my earlier question. Now >> It's again two weeks without a reply, although I'm sure you can answer my >> earlier question within a few minutes of your time. Please give me any >> feedback so that I don't have to wait longer for no reason. If you don't >> want to look into this issue, please say so. If my emails got lost in the >> meantime, I can send them again. >> >> Many thanks, >> Jussuf >> >> >> On Thu, Mar 1, 2018 at 10:28 PM, iusadhfoias sidufasipudf < >> asduifhssauidf at gmail.com> wrote: >> >>> I'm sorry, here is the attachment. >>> >>> Many thanks, >>> Jussuf >>> >>> On Thu, Mar 1, 2018 at 4:26 AM, Cory Quammen >>> wrote: >>> >>>> Hi, >>>> >>>> I think you forgot to attach your small example. Could you do so? >>>> >>>> Thanks, >>>> Cory >>>> >>>> On Tue, Feb 27, 2018 at 12:43 PM, iusadhfoias sidufasipudf < >>>> asduifhssauidf at gmail.com> wrote: >>>> >>>>> Hello VTK developers, >>>>> several questions about the correct usage of information_only >>>>> properties have been asked over the years, but I didn't find a working >>>>> solution. >>>>> >>>>> The attached example is a complete, tiny, source plugin >>>>> ("MyInfoSource") for paraview 5.4.1. It generates an empty PolyData output. >>>>> I am only interested in modifying and showing the source's properties. >>>>> >>>>> MyInfoSource has 3 properties (cf. InfoSource.xml): >>>>> 1) InputPoint allows to input three coordinates. >>>>> 2) CalculatedPoint has 'information_only="1"' and will be calculated >>>>> whenever InputPoint is set. >>>>> 3) ShowCalculatedPoint has 'information_property="CalculatedPoint"' >>>>> and is meant to output that calculated value. >>>>> >>>>> I am using a modified vtkInfoSource::SetInputPoint, which sets the >>>>> CalculatedPoint coordinates to twice the InputPoint coordinates whenever >>>>> InputPoint changes (cf. vtkInfoSource.cxx). >>>>> >>>>> I was expecting the "ShowCalculatedPoint" property to update in the >>>>> properties view, whenever I apply changes to InputPoint, but it doesn't >>>>> change. Only when I click "Restore application default setting values" for >>>>> MyInformationSource, then ShowCalculatedPoint shows twice the last value of >>>>> InputPoint. >>>>> >>>>> Can you reproduce this behaviour? >>>>> What needs to be changed, so that ShowCalculatedPoint always shows >>>>> twice the InputPoint coordinates after changes are applied? >>>>> >>>>> Many thanks, >>>>> Jussuf >>>>> >>>>> _______________________________________________ >>>>> 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: >>>>> https://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: > https://public.kitware.com/mailman/listinfo/paraview-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From asduifhssauidf at gmail.com Sat Mar 17 16:58:42 2018 From: asduifhssauidf at gmail.com (iusadhfoias sidufasipudf) Date: Sat, 17 Mar 2018 21:58:42 +0100 Subject: [Paraview-developers] information_only property doesn't update, please help In-Reply-To: References: Message-ID: I never mentioned any obligation to solve my problem. I am just trying to understand what I did wrong, why my question is ignored, but many others that don't put much effort into explaining their problem receive lots of attention. Colleagues were shocked by Kitwares support contract conditions, so this is not an option for me. Other companies are thankful for this kind of bug reports. Jussuf On Sat, Mar 17, 2018 at 3:32 PM, Joachim Pouderoux < joachim.pouderoux at kitware.com> wrote: > Jussuf, > > This mailing list is not a ParaView hot line: the principle of this "free" > mailing list is that people (from Kitware or not) answer, on their > good will, when they have time to do and there is no obligation to answer > at all. > > Cory is certainly busy on lot of other stuff now, especially for the > preparation of 5.5 release but he or someone else will answer > you if you have the patience to wait. - By the way, Cory never promised to > help you on this issue, he just mentionned the fact > that your forget to attach your example code. > > Note that if you need a reactive support, Kitware can setup a specific > support contract with you. > > Best regards, > Joachim > > *Joachim Pouderoux*, PhD > > *Technical Expert - Scientific Computing Team* > *Kitware SAS * > > > 2018-03-17 10:09 GMT-04:00 iusadhfoias sidufasipudf < > asduifhssauidf at gmail.com>: > >> Hi Cory, >> what is the reason, why you ignore my emails? >> After your reminder I attached a complete example that you can compile >> and run within seconds, and I described the problem in sufficient detail. >> In this list many questions are answered that leave out important details >> again and again. But my question is ignored. What is wrong with my problem >> description? >> >> Jussuf >> >> On Tue, Mar 13, 2018 at 2:42 PM, iusadhfoias sidufasipudf < >> asduifhssauidf at gmail.com> wrote: >> >>> Hi Cory, >>> I feel really, really sorry to bother you again. You were so kind to >>> remind me of the attachment that was missing from my earlier question. Now >>> It's again two weeks without a reply, although I'm sure you can answer my >>> earlier question within a few minutes of your time. Please give me any >>> feedback so that I don't have to wait longer for no reason. If you don't >>> want to look into this issue, please say so. If my emails got lost in the >>> meantime, I can send them again. >>> >>> Many thanks, >>> Jussuf >>> >>> >>> On Thu, Mar 1, 2018 at 10:28 PM, iusadhfoias sidufasipudf < >>> asduifhssauidf at gmail.com> wrote: >>> >>>> I'm sorry, here is the attachment. >>>> >>>> Many thanks, >>>> Jussuf >>>> >>>> On Thu, Mar 1, 2018 at 4:26 AM, Cory Quammen >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> I think you forgot to attach your small example. Could you do so? >>>>> >>>>> Thanks, >>>>> Cory >>>>> >>>>> On Tue, Feb 27, 2018 at 12:43 PM, iusadhfoias sidufasipudf < >>>>> asduifhssauidf at gmail.com> wrote: >>>>> >>>>>> Hello VTK developers, >>>>>> several questions about the correct usage of information_only >>>>>> properties have been asked over the years, but I didn't find a working >>>>>> solution. >>>>>> >>>>>> The attached example is a complete, tiny, source plugin >>>>>> ("MyInfoSource") for paraview 5.4.1. It generates an empty PolyData output. >>>>>> I am only interested in modifying and showing the source's properties. >>>>>> >>>>>> MyInfoSource has 3 properties (cf. InfoSource.xml): >>>>>> 1) InputPoint allows to input three coordinates. >>>>>> 2) CalculatedPoint has 'information_only="1"' and will be calculated >>>>>> whenever InputPoint is set. >>>>>> 3) ShowCalculatedPoint has 'information_property="CalculatedPoint"' >>>>>> and is meant to output that calculated value. >>>>>> >>>>>> I am using a modified vtkInfoSource::SetInputPoint, which sets the >>>>>> CalculatedPoint coordinates to twice the InputPoint coordinates whenever >>>>>> InputPoint changes (cf. vtkInfoSource.cxx). >>>>>> >>>>>> I was expecting the "ShowCalculatedPoint" property to update in the >>>>>> properties view, whenever I apply changes to InputPoint, but it doesn't >>>>>> change. Only when I click "Restore application default setting values" for >>>>>> MyInformationSource, then ShowCalculatedPoint shows twice the last value of >>>>>> InputPoint. >>>>>> >>>>>> Can you reproduce this behaviour? >>>>>> What needs to be changed, so that ShowCalculatedPoint always shows >>>>>> twice the InputPoint coordinates after changes are applied? >>>>>> >>>>>> Many thanks, >>>>>> Jussuf >>>>>> >>>>>> _______________________________________________ >>>>>> 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: >>>>>> https://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: >> https://public.kitware.com/mailman/listinfo/paraview-developers >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From haocheng.liu at kitware.com Sat Mar 17 21:38:32 2018 From: haocheng.liu at kitware.com (Haocheng Liu) Date: Sat, 17 Mar 2018 21:38:32 -0400 Subject: [Paraview-developers] Lack of valgrind / test coverage on Cdash In-Reply-To: References: Message-ID: Hi Jonathan, On Fri, Mar 16, 2018 at 2:08 PM, Jonathan Borduas < jonathan.borduas at caboma.com> wrote: > Dear ParaView community, > > > > The vtkDebugLeaks is fun, but quite limited in comparison with the > information provided by valgrind. > > > > Moreover, the lack of test coverage in the ParaView's CDash makes it hard > to know what is well tested, what might be deprecated and go unnoticed by > the community using those functions. > > If you are interested in whether and when certain functions would be deprecated, you can check the documentation in the ParaView source code where deprecation is marked. Ex, pqApplicationCore::getDisplayPolicy() is documented that it would be deprecated in PV5.5. > I heard there was such test until one machine broke down last year? > > > > Best regards, > > > > Jonathan Borduas > > > > I created an issue on gitlab: https://gitlab.kitware.com/ > paraview/paraview/issues/18058 > > > > > > _______________________________________________ > 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: > https://public.kitware.com/mailman/listinfo/paraview-developers > > -- Best regards Haocheng Haocheng LIU Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4421 <(518)%20881-4421> -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Mon Mar 19 10:55:28 2018 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Mon, 19 Mar 2018 10:55:28 -0400 Subject: [Paraview-developers] Survey: Migrating to Discourse Forum In-Reply-To: References: Message-ID: Folks, I'll close the survey later today and then summarize the results along with the pros and cons that folks have raised on the mailing list in a shared document. Thanks Utkarsh On Thu, Mar 15, 2018 at 3:55 PM, Utkarsh Ayachit wrote: > Folks, > > Here's a quick survey to collect community preference on migrating > ParaView mailing lists to a Discourse forum: > > https://goo.gl/forms/6YT6q5biy1685fxZ2 > > Your feedback is appreciated! > > Utkarsh From utkarsh.ayachit at kitware.com Mon Mar 19 11:45:09 2018 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Mon, 19 Mar 2018 11:45:09 -0400 Subject: [Paraview-developers] Adding a fmtlib to ParaView/VTK Message-ID: Folks, I was reviewing MR [1] which got me thinking that we have no standard rules for formatting strings. It would be great it there was uniform mechanism that we can train users on to build strings from fields or numbers which ability to specify precision etc. I've seen fmtlib [2] used before and given that it's formatting syntax is similar to that available in Python, it may be a good choice to adopt. I am thinking all places were we convert numbers to labels e.g. Annotation Time filter/source, Chart titles, Python Annotation filter, etc. can support such format strings. Thoughts? Utkarsh [1] https://gitlab.kitware.com/paraview/paraview/merge_requests/2323 [2] http://fmtlib.net/latest/index.html From wascott at sandia.gov Mon Mar 19 13:10:28 2018 From: wascott at sandia.gov (Scott, W Alan) Date: Mon, 19 Mar 2018 17:10:28 +0000 Subject: [Paraview-developers] [EXTERNAL] Adding a fmtlib to ParaView/VTK In-Reply-To: References: Message-ID: <7a3db8d8f44c435c89c0f7ab34c12f53@ES01AMSNLNT.srn.sandia.gov> +1 > -----Original Message----- > From: Paraview-developers [mailto:paraview-developers- > bounces at public.kitware.com] On Behalf Of Utkarsh Ayachit > Sent: Monday, March 19, 2018 9:45 AM > To: ParaView Developers > Subject: [EXTERNAL] [Paraview-developers] Adding a fmtlib to ParaView/VTK > > Folks, > > I was reviewing MR [1] which got me thinking that we have no standard rules > for formatting strings. It would be great it there was uniform mechanism that > we can train users on to build strings from fields or numbers which ability to > specify precision etc. > > I've seen fmtlib [2] used before and given that it's formatting syntax is similar > to that available in Python, it may be a good choice to adopt. > > I am thinking all places were we convert numbers to labels e.g. > Annotation Time filter/source, Chart titles, Python Annotation filter, etc. can > support such format strings. > > Thoughts? > > Utkarsh > > [1] https://gitlab.kitware.com/paraview/paraview/merge_requests/2323 > [2] http://fmtlib.net/latest/index.html > _______________________________________________ > 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: > https://public.kitware.com/mailman/listinfo/paraview-developers From cory.quammen at kitware.com Mon Mar 19 13:31:08 2018 From: cory.quammen at kitware.com (Cory Quammen) Date: Mon, 19 Mar 2018 13:31:08 -0400 Subject: [Paraview-developers] [EXTERNAL] Adding a fmtlib to ParaView/VTK In-Reply-To: <7a3db8d8f44c435c89c0f7ab34c12f53@ES01AMSNLNT.srn.sandia.gov> References: <7a3db8d8f44c435c89c0f7ab34c12f53@ES01AMSNLNT.srn.sandia.gov> Message-ID: Yeah, looks nice. So the idea would be instead of writing ${TIME} one could write ${TIME:.2f} or even just {TIME:.2f} to produce a formated TIME value? On Mon, Mar 19, 2018 at 1:10 PM, Scott, W Alan wrote: > +1 > > > -----Original Message----- > > From: Paraview-developers [mailto:paraview-developers- > > bounces at public.kitware.com] On Behalf Of Utkarsh Ayachit > > Sent: Monday, March 19, 2018 9:45 AM > > To: ParaView Developers > > Subject: [EXTERNAL] [Paraview-developers] Adding a fmtlib to ParaView/VTK > > > > Folks, > > > > I was reviewing MR [1] which got me thinking that we have no standard > rules > > for formatting strings. It would be great it there was uniform mechanism > that > > we can train users on to build strings from fields or numbers which > ability to > > specify precision etc. > > > > I've seen fmtlib [2] used before and given that it's formatting syntax > is similar > > to that available in Python, it may be a good choice to adopt. > > > > I am thinking all places were we convert numbers to labels e.g. > > Annotation Time filter/source, Chart titles, Python Annotation filter, > etc. can > > support such format strings. > > > > Thoughts? > > > > Utkarsh > > > > [1] https://gitlab.kitware.com/paraview/paraview/merge_requests/2323 > > [2] http://fmtlib.net/latest/index.html > > _______________________________________________ > > 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: > > https://public.kitware.com/mailman/listinfo/paraview-developers > _______________________________________________ > 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: > https://public.kitware.com/mailman/listinfo/paraview-developers > -- Cory Quammen Staff R&D Engineer Kitware, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Mon Mar 19 15:12:04 2018 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Mon, 19 Mar 2018 15:12:04 -0400 Subject: [Paraview-developers] [EXTERNAL] Adding a fmtlib to ParaView/VTK In-Reply-To: References: <7a3db8d8f44c435c89c0f7ab34c12f53@ES01AMSNLNT.srn.sandia.gov> Message-ID: Something like that. We may want to build a registry of keywords available to users in various contexts, e.g. time, timestep, number_of_timesteps etc. On Mon, Mar 19, 2018 at 1:31 PM, Cory Quammen wrote: > Yeah, looks nice. > > So the idea would be instead of writing > > ${TIME} > > one could write > > ${TIME:.2f} > > or even just > > {TIME:.2f} > > to produce a formated TIME value? > > On Mon, Mar 19, 2018 at 1:10 PM, Scott, W Alan wrote: >> >> +1 >> >> > -----Original Message----- >> > From: Paraview-developers [mailto:paraview-developers- >> > bounces at public.kitware.com] On Behalf Of Utkarsh Ayachit >> > Sent: Monday, March 19, 2018 9:45 AM >> > To: ParaView Developers >> > Subject: [EXTERNAL] [Paraview-developers] Adding a fmtlib to >> > ParaView/VTK >> > >> > Folks, >> > >> > I was reviewing MR [1] which got me thinking that we have no standard >> > rules >> > for formatting strings. It would be great it there was uniform mechanism >> > that >> > we can train users on to build strings from fields or numbers which >> > ability to >> > specify precision etc. >> > >> > I've seen fmtlib [2] used before and given that it's formatting syntax >> > is similar >> > to that available in Python, it may be a good choice to adopt. >> > >> > I am thinking all places were we convert numbers to labels e.g. >> > Annotation Time filter/source, Chart titles, Python Annotation filter, >> > etc. can >> > support such format strings. >> > >> > Thoughts? >> > >> > Utkarsh >> > >> > [1] https://gitlab.kitware.com/paraview/paraview/merge_requests/2323 >> > [2] http://fmtlib.net/latest/index.html >> > _______________________________________________ >> > 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: >> > https://public.kitware.com/mailman/listinfo/paraview-developers >> _______________________________________________ >> 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: >> https://public.kitware.com/mailman/listinfo/paraview-developers > > > > > -- > Cory Quammen > Staff R&D Engineer > Kitware, Inc. From david.thompson at kitware.com Mon Mar 19 15:26:44 2018 From: david.thompson at kitware.com (David Thompson) Date: Mon, 19 Mar 2018 15:26:44 -0400 Subject: [Paraview-developers] [Paraview] Past Due Invoice In-Reply-To: <28171643343.2018319131118@paraview.org> References: <28171643343.2018319131118@paraview.org> Message-ID: <1978FA3E-7033-45A4-BFD0-EEAD67C557BE@kitware.com> Hi all, I'm sure this is not actually Berk. Please be careful not to click on the link. I've been getting these "invoice" notices from other people on the VTK and ParaView mailing lists the last few days. David > On Mar 19, 2018, at 10:11, berk.geveci at kitware.com wrote: > > > Attached is invoice 516952 for PO #5V255338. If you have any questions, please give me a call. > > > > > > Many Thanks > berk.geveci at kitware.com > _______________________________________________ > 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: > https://public.kitware.com/mailman/listinfo/paraview From wascott at sandia.gov Mon Mar 19 16:01:51 2018 From: wascott at sandia.gov (Scott, W Alan) Date: Mon, 19 Mar 2018 20:01:51 +0000 Subject: [Paraview-developers] FW: [EXTERNAL] Re: ParaView | Memory consumption on Paraview (#18035) In-Reply-To: References: Message-ID: Boonthanome, Moving this to the developers list. Kitware ? looking at the memory usage below, a few questions: * Why does merge blocks grow so much? Why can?t this filter just do shallow copies? Is this impossible, or just not implemented? * Why can?t Merge Blocks do shallow copies? Is this impossible, or just not implemented? * (I think I know this one, but here it is). Why does the ghost cell generator bloat memory so much? Can?t you just use shallow copies of the primary data, and then add the ghost cells? * Why can?t we have the cell data to point data filter be smart enough to add ghost cells if necessary for calculations, then throw them away? * Any other ideas how to decrease the bloat of about 4 GB of data to be about 18 GB of data? Thanks team, Alan From: Boonthanome Nouanesengsy [mailto:gitlab at gitlab.kitware.com] Sent: Thursday, March 15, 2018 4:39 PM To: Scott, W Alan Subject: [EXTERNAL] Re: ParaView | Memory consumption on Paraview (#18035) I tried the Pass Arrays pipeline again from a clean node. I got the node, and made a client/server connection. I basically got similar values. Using Pass Arrays again: * before loading data: 1.58 GB * after loading data: 5.70 GB * after pass arrays (1 cell array): 5.84 GB * after Merge Blocks: 9.38 GB * after ghost cells: 22.23 GB * after cell data to point data: 22.23 GB * after show surface: 22.43 GB * after contour: 22.43 GB The original data is about 4 GB, so it seems a bit much that the ghost cells filter will add 13 GB. Yes, it does make a copy of the data, padded with ghost cells, but the added ghost cells should not triple the amount of memory used. Alan, the result of using Pass Arrays is that the output of a filter will have less arrays, and take less memory, correct? For example, if I do Pass Arrays -> Merge Blocks, then after applying Merge Blocks I only see one array available. ? Reply to this email directly or view it on GitLab. You're receiving this email because of your account on gitlab.kitware.com. If you'd like to receive fewer emails, you can unsubscribe from this thread or adjust your notification settings. -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Tue Mar 20 10:39:57 2018 From: berk.geveci at kitware.com (Berk Geveci) Date: Tue, 20 Mar 2018 10:39:57 -0400 Subject: [Paraview-developers] [Paraview] Past Due Invoice In-Reply-To: <1978FA3E-7033-45A4-BFD0-EEAD67C557BE@kitware.com> References: <28171643343.2018319131118@paraview.org> <1978FA3E-7033-45A4-BFD0-EEAD67C557BE@kitware.com> Message-ID: Ugh. Thanks for catching this David. This is double nasty because most people have their mailman settings such that their own messages are not sent to them through mailman. So I didn't even see this message. Yeah this is obviously not me. On Mon, Mar 19, 2018 at 3:26 PM, David Thompson wrote: > Hi all, I'm sure this is not actually Berk. Please be careful not to click > on the link. I've been getting these "invoice" notices from other people on > the VTK and ParaView mailing lists the last few days. > > David > > > On Mar 19, 2018, at 10:11, berk.geveci at kitware.com < > Christine at gamewatchers.co.ke> wrote: > > > > > > Attached is invoice 516952 for PO #5V255338. If you have any questions, > please give me a call. > > > > > > > > > > > > Many Thanks > > berk.geveci at kitware.com > > _______________________________________________ > > 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: > > https://public.kitware.com/mailman/listinfo/paraview > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cornelis.bockemuehl at gmail.com Tue Mar 20 13:19:04 2018 From: cornelis.bockemuehl at gmail.com (Cornelis =?ISO-8859-1?Q?Bockem=FChl?=) Date: Tue, 20 Mar 2018 18:19:04 +0100 Subject: [Paraview-developers] Some documentation on MTime handling? Message-ID: <1521566344.3431.44.camel@gmail.com> My short question is: I am having some problems to understand time handling in VTK, so I would like to find some documentations that can enlighten me! So far my Google research has only shown me that a) there have been different approaches in the past (which I do not need to understand) and b) there are many more options available than I will ever need to use... The specific problem that I am dealing with is in a project. In a filter that is supposed to run inside ParaView I am programmatically generating a time series of unsigned grids and tables, i.e. the filter has several several output ports that all have to change per time step. Empirically I found out that I have to put this code into RequestInformation: // tell the caller that we can provide time varying data and specif y the range double tRange[] = {0., 1.}; // generate a vector with the steps - from 0 to NumSteps Steps.resize(NumPeriods + 1); for(int s = 0; s <= NumPeriods; ++s) Steps[s] = (double)s / (double)NumPeriods; for(int n = 0; n < GetNumberOfOutputPorts(); ++n) { vtkInformation* info = outputVector->GetInformationObject(n); info->Set(vtkStreamingDemandDrivenPipeline::TIME_RANGE(), tRange, 2); info->Set(vtkStreamingDemandDrivenPipeline::TIME_STEPS(), Steps.data(), Steps.size()); info->Set(CAN_HANDLE_PIECE_REQUEST(), 1); } Some of the calculations are a bit tedious, so I am caching many data in the filter object, but not more than so far required. This means that in RequestData a decision has to be taken if more data need to be calculated first, or else directly copy from the cached data, like for example this: - jump to step 5 of 20 directly -> calculate steps 1 - 2 - 3 - 4 - 5 internally, then copy data from step 5 to the output ports - jump back to step 3 -> simply copy the data from step 3 to the output ports - jump to step 7 -> calculate steps 6 - 7, then copy etc. During the calculations I am using other filters for some data processing, not attached to the pipeline, for some data transformations. For some time this worked now "somehow", but now I am suddenly getting crashes in one of these "detached filters" - when some "trivial producer" wants to ask for MTime - which is completely irrelevant in that context... In other words: I am now a bit confused - and at the same time I am afraid that I cannot easily strip down my problem to a size that I can easily share! Specifically I am not sure which way to try further: - somehow "tell the filters" that they should not care about time? - reconsider my caching because maybe it interferes with some similar functionality that is already built into ParaView? - somehow "tell" the output unstructured grids and tables which is their current MTime? But so far I thought I had understood that this is managed by ParaView, not by the data objects... ...but then some of the data objects have a GetMTime function, but no way to explicitly set this fabulous MTime: where does it come from? Actually such a call is the location where the program crashes! Regards, Cornelis Bockem?hl -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Tue Mar 20 16:43:23 2018 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Tue, 20 Mar 2018 16:43:23 -0400 Subject: [Paraview-developers] Some documentation on MTime handling? In-Reply-To: <1521566344.3431.44.camel@gmail.com> References: <1521566344.3431.44.camel@gmail.com> Message-ID: Cornelis, I don't see anything fundamentally wrong about your approach (except that you're assuming the input to this will never change dramatically enough to invalidate all the caches, but let's assume that's the case). If you're getting segfaults due to `GetMTime`, it's actually something else that's doing on, some bad ptr, access, etc. MTime is different from the pipeline time. MTime is just a timestamp on VTK objects to indicate when they were last modified, for example. If you share your filter.cxx, I can see if I can spot the issue. Utkarsh On Tue, Mar 20, 2018 at 1:19 PM, Cornelis Bockem?hl < cornelis.bockemuehl at gmail.com> wrote: > My short question is: I am having some problems to understand time > handling in VTK, so I would like to find some documentations that can > enlighten me! So far my Google research has only shown me that a) there > have been different approaches in the past (which I do not need to > understand) and b) there are many more options available than I will ever > need to use... > > The specific problem that I am dealing with is in a project. In a filter > that is supposed to run inside ParaView I am programmatically generating a > time series of unsigned grids and tables, i.e. the filter has several > several output ports that all have to change per time step. Empirically I > found out that I have to put this code into RequestInformation: > > // tell the caller that we can provide time varying data and specify the range > > double tRange[] = {0., 1.}; > > > // generate a vector with the steps - from 0 to NumSteps > > Steps.resize(NumPeriods + 1); > > for(int s = 0; s <= NumPeriods; ++s) > > Steps[s] = (double)s / (double)NumPeriods; > > > for(int n = 0; n < GetNumberOfOutputPorts(); ++n) > > { > > vtkInformation* info = outputVector->GetInformationObject(n); > > info->Set(vtkStreamingDemandDrivenPipeline::TIME_RANGE(), tRange, 2); > > info->Set(vtkStreamingDemandDrivenPipeline::TIME_STEPS(), Steps.data(), Steps.size()); > > info->Set(CAN_HANDLE_PIECE_REQUEST(), 1); > > } > > > Some of the calculations are a bit tedious, so I am caching many data in > the filter object, but not more than so far required. This means that in > RequestData a decision has to be taken if more data need to be calculated > first, or else directly copy from the cached data, like for example this: > > - jump to step 5 of 20 directly -> calculate steps 1 - 2 - 3 - 4 - 5 > internally, then copy data from step 5 to the output ports > > - jump back to step 3 -> simply copy the data from step 3 to the output > ports > > - jump to step 7 -> calculate steps 6 - 7, then copy etc. > > During the calculations I am using other filters for some data processing, > not attached to the pipeline, for some data transformations. For some time > this worked now "somehow", but now I am suddenly getting crashes in one of > these "detached filters" - when some "trivial producer" wants to ask for > MTime - which is completely irrelevant in that context... > > In other words: I am now a bit confused - and at the same time I am afraid > that I cannot easily strip down my problem to a size that I can easily > share! > > Specifically I am not sure which way to try further: > > - somehow "tell the filters" that they should not care about time? > > - reconsider my caching because maybe it interferes with some similar > functionality that is already built into ParaView? > > - somehow "tell" the output unstructured grids and tables which is their > current MTime? But so far I thought I had understood that this is managed > by ParaView, not by the data objects... > > ...but then some of the data objects have a GetMTime function, but no way > to explicitly set this fabulous MTime: where does it come from? > > Actually such a call is the location where the program crashes! > > Regards, > Cornelis Bockem?hl > > _______________________________________________ > 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: > https://public.kitware.com/mailman/listinfo/paraview-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Tue Mar 20 17:08:36 2018 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Tue, 20 Mar 2018 17:08:36 -0400 Subject: [Paraview-developers] FW: [EXTERNAL] Re: ParaView | Memory consumption on Paraview (#18035) In-Reply-To: References: Message-ID: > Why does merge blocks grow so much? Why can?t this filter just do shallow > copies? Is this impossible, or just not implemented? No, merge blocks is not a shallow copy, it needs to combine mutliple vtkDataSet's into a single vtkDataSet merging all points into a single array, same for cells, other attribute arrays etc. Merge Blocks should indeed be considered as a workaround for issue when handling mutliblock datasets in the pipeline and not the go-to solution. There is work currently underway that will revamp multiblock dataset support in VTK/ParaView which should ultimately make Merge Blocks obsolete. Looking at your pipeline, looks like you're doing MergeBlocks so that you can run the Ghost Cells generator filter. What is the nature of your data? Is it truly a multiblock or just has 1 block in it on each rank? If its just 1 block, what is the type of the block? If it's a unstructured grid, it will trivial to create a filter that just passes the input block out as unstructured grid without duplicating. > Why can?t Merge Blocks do shallow copies? Is this impossible, or just not > implemented? It's impossible. See previous comment for justification based on how things are currently. > (I think I know this one, but here it is). Why does the ghost cell > generator bloat memory so much? Can?t you just use shallow copies of the > primary data, and then add the ghost cells? adding ghost cell etc, means adding new elements to existing arrays. since vtk doesn't modify input arrays, when it needs to add new elements, it has to create a deep-copy and then add new elements to it. > Why can?t we have the cell data to point data filter be smart enough to add > ghost cells if necessary for calculations, then throw them away? Unless I am missing something, no reason. Seems to me that's just the way it was written. I can't see why the filter can't request 1 extra ghost-level from its input. (cc, Berk). > Any other ideas how to decrease the bloat of about 4 GB of data to be about > 18 GB of data? Is this for a Catalyst or pvbatch pipeline or for an interactive session? Utkarsh From kmorel at sandia.gov Tue Mar 20 17:51:04 2018 From: kmorel at sandia.gov (Moreland, Kenneth) Date: Tue, 20 Mar 2018 21:51:04 +0000 Subject: [Paraview-developers] FW: [EXTERNAL] Re: ParaView | Memory consumption on Paraview (#18035) In-Reply-To: References: Message-ID: <6E0334EF-FB94-412F-B4FE-EC81EBA6EF9C@sandia.gov> I believe the cell to point/point to cell filters already request an added layer of ghost cells. It's just that if no ghost cells are not available in the data (which is common), they are not automatically computed. I believe the request is that ParaView automatically run the generate ghost cells filter under the covers if the layer of ghost cells is not available upstream. I think this is a dangerous idea. The cell to point filter is fast and takes little memory. Generating ghost cells, in contrast, is slow and will take lots of memory (at least temporarily until the operation completes). Doing an automatic ghost cell generation can create lots of surprising problems, especially when run at large scales. -Ken ?On 3/20/18, 3:08 PM, "Paraview-developers on behalf of Utkarsh Ayachit" wrote: > >Why can?t we have the cell data to point data filter be smart enough to add >ghost cells if necessary for calculations, then throw them away? Unless I am missing something, no reason. Seems to me that's just the way it was written. I can't see why the filter can't request 1 extra ghost-level from its input. (cc, Berk). From boonth at lanl.gov Tue Mar 20 18:00:51 2018 From: boonth at lanl.gov (Boonthanome Nouanesengsy) Date: Tue, 20 Mar 2018 16:00:51 -0600 Subject: [Paraview-developers] FW: [EXTERNAL] Re: ParaView | Memory consumption on Paraview (#18035) In-Reply-To: References: Message-ID: > Unless I am missing something, no reason. Seems to me that's just the > way it was written. I can't see why the filter can't request 1 extra > ghost-level from its input. (cc, Berk). Because we start with cell data, we actually require two layers of ghost cells. The ghost cells filter was developed to allocate as many layers of ghost cells as needed for a distributed dataset. > Any other ideas how to decrease the bloat of about 4 GB of data to be about > 18 GB of data? > Is this for a Catalyst or pvbatch pipeline or for an interactive session? It's for an interactive session. We have a user running out of memory trying to use a certain pipeline. More information is in the issue at https://gitlab.kitware.com/paraview/paraview/issues/18035 Boonth On 03/20/2018 03:08 PM, Utkarsh Ayachit wrote: >> Why does merge blocks grow so much? Why can?t this filter just do shallow >> copies? Is this impossible, or just not implemented? > No, merge blocks is not a shallow copy, it needs to combine mutliple > vtkDataSet's into a single vtkDataSet merging all points into a single > array, same for cells, other attribute arrays etc. Merge Blocks should > indeed be considered as a workaround for issue when handling > mutliblock datasets in the pipeline and not the go-to solution. There > is work currently underway that will revamp multiblock dataset support > in VTK/ParaView which should ultimately make Merge Blocks obsolete. > > Looking at your pipeline, looks like you're doing MergeBlocks so that > you can run the Ghost Cells generator filter. What is the nature of > your data? Is it truly a multiblock or just has 1 block in it on each > rank? If its just 1 block, what is the type of the block? If it's a > unstructured grid, it will trivial to create a filter that just passes > the input block out as unstructured grid without duplicating. > >> Why can?t Merge Blocks do shallow copies? Is this impossible, or just not >> implemented? > It's impossible. See previous comment for justification based on how > things are currently. > >> (I think I know this one, but here it is). Why does the ghost cell >> generator bloat memory so much? Can?t you just use shallow copies of the >> primary data, and then add the ghost cells? > adding ghost cell etc, means adding new elements to existing arrays. > since vtk doesn't modify input arrays, when it needs to add new > elements, it has to create a deep-copy and then add new elements to > it. > >> Why can?t we have the cell data to point data filter be smart enough to add >> ghost cells if necessary for calculations, then throw them away? > Unless I am missing something, no reason. Seems to me that's just the > way it was written. I can't see why the filter can't request 1 extra > ghost-level from its input. (cc, Berk). > >> Any other ideas how to decrease the bloat of about 4 GB of data to be about >> 18 GB of data? > Is this for a Catalyst or pvbatch pipeline or for an interactive session? > > Utkarsh > _______________________________________________ > 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: > https://public.kitware.com/mailman/listinfo/paraview-developers From cornelis.bockemuehl at gmail.com Tue Mar 20 18:50:19 2018 From: cornelis.bockemuehl at gmail.com (=?ISO-8859-1?Q?Cornelis_Bockem=FChl?=) Date: Tue, 20 Mar 2018 23:50:19 +0100 Subject: [Paraview-developers] Some documentation on MTime handling? In-Reply-To: References: <1521566344.3431.44.camel@gmail.com> Message-ID: <9fd0ff1d-e68f-4250-8eaf-7cb2a3a7e053@gmail.com> Thanks - that gives me already a trace to follow: "mtime != pipeline time"! And thanks also for the offer to have a look into the code! However I guess that if I really have some pointer problem, like writing unallocated memory or the like, this is not in one single file but some "fatal cooperation" between program parts... I will have to step by step comment out functionality, see where it goes away and so narrow the potentially "guilty code"... Regards, Cornelis ?Gesendet mit BlueMail ? Am 20. M?rz 2018 21:43, um 21:43, Utkarsh Ayachit schrieb: >Cornelis, > >I don't see anything fundamentally wrong about your approach (except >that >you're assuming the input to this will never change dramatically enough >to >invalidate all the caches, but let's assume that's the case). > >If you're getting segfaults due to `GetMTime`, it's actually something >else >that's doing on, some bad ptr, access, etc. MTime is different from the >pipeline time. MTime is just a timestamp on VTK objects to indicate >when >they were last modified, for example. If you share your filter.cxx, I >can >see if I can spot the issue. > >Utkarsh > >On Tue, Mar 20, 2018 at 1:19 PM, Cornelis Bockem?hl < >cornelis.bockemuehl at gmail.com> wrote: > >> My short question is: I am having some problems to understand time >> handling in VTK, so I would like to find some documentations that can >> enlighten me! So far my Google research has only shown me that a) >there >> have been different approaches in the past (which I do not need to >> understand) and b) there are many more options available than I will >ever >> need to use... >> >> The specific problem that I am dealing with is in a project. In a >filter >> that is supposed to run inside ParaView I am programmatically >generating a >> time series of unsigned grids and tables, i.e. the filter has several >> several output ports that all have to change per time step. >Empirically I >> found out that I have to put this code into RequestInformation: >> >> // tell the caller that we can provide time varying data and >specify the range >> >> double tRange[] = {0., 1.}; >> >> >> // generate a vector with the steps - from 0 to NumSteps >> >> Steps.resize(NumPeriods + 1); >> >> for(int s = 0; s <= NumPeriods; ++s) >> >> Steps[s] = (double)s / (double)NumPeriods; >> >> >> for(int n = 0; n < GetNumberOfOutputPorts(); ++n) >> >> { >> >> vtkInformation* info = outputVector->GetInformationObject(n); >> >> info->Set(vtkStreamingDemandDrivenPipeline::TIME_RANGE(), >tRange, 2); >> >> info->Set(vtkStreamingDemandDrivenPipeline::TIME_STEPS(), >Steps.data(), Steps.size()); >> >> info->Set(CAN_HANDLE_PIECE_REQUEST(), 1); >> >> } >> >> >> Some of the calculations are a bit tedious, so I am caching many data >in >> the filter object, but not more than so far required. This means that >in >> RequestData a decision has to be taken if more data need to be >calculated >> first, or else directly copy from the cached data, like for example >this: >> >> - jump to step 5 of 20 directly -> calculate steps 1 - 2 - 3 - 4 - 5 >> internally, then copy data from step 5 to the output ports >> >> - jump back to step 3 -> simply copy the data from step 3 to the >output >> ports >> >> - jump to step 7 -> calculate steps 6 - 7, then copy etc. >> >> During the calculations I am using other filters for some data >processing, >> not attached to the pipeline, for some data transformations. For some >time >> this worked now "somehow", but now I am suddenly getting crashes in >one of >> these "detached filters" - when some "trivial producer" wants to ask >for >> MTime - which is completely irrelevant in that context... >> >> In other words: I am now a bit confused - and at the same time I am >afraid >> that I cannot easily strip down my problem to a size that I can >easily >> share! >> >> Specifically I am not sure which way to try further: >> >> - somehow "tell the filters" that they should not care about time? >> >> - reconsider my caching because maybe it interferes with some similar >> functionality that is already built into ParaView? >> >> - somehow "tell" the output unstructured grids and tables which is >their >> current MTime? But so far I thought I had understood that this is >managed >> by ParaView, not by the data objects... >> >> ...but then some of the data objects have a GetMTime function, but no >way >> to explicitly set this fabulous MTime: where does it come from? >> >> Actually such a call is the location where the program crashes! >> >> Regards, >> Cornelis Bockem?hl >> >> _______________________________________________ >> 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: >> https://public.kitware.com/mailman/listinfo/paraview-developers >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Tue Mar 20 19:34:21 2018 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Tue, 20 Mar 2018 19:34:21 -0400 Subject: [Paraview-developers] Some documentation on MTime handling? In-Reply-To: <9fd0ff1d-e68f-4250-8eaf-7cb2a3a7e053@gmail.com> References: <1521566344.3431.44.camel@gmail.com> <9fd0ff1d-e68f-4250-8eaf-7cb2a3a7e053@gmail.com> Message-ID: You may also try `valgrind`, if you haven't already. It's great at catching such memory issues. Utkarsh On Tue, Mar 20, 2018 at 6:50 PM, Cornelis Bockem?hl wrote: > Thanks - that gives me already a trace to follow: "mtime != pipeline time"! > > And thanks also for the offer to have a look into the code! However I guess > that if I really have some pointer problem, like writing unallocated memory > or the like, this is not in one single file but some "fatal cooperation" > between program parts... > > I will have to step by step comment out functionality, see where it goes > away and so narrow the potentially "guilty code"... > > Regards, Cornelis > > Gesendet mit BlueMail > Am 20. M?rz 2018, um 21:43, Utkarsh Ayachit > schrieb: >> >> Cornelis, >> >> I don't see anything fundamentally wrong about your approach (except that >> you're assuming the input to this will never change dramatically enough to >> invalidate all the caches, but let's assume that's the case). >> >> If you're getting segfaults due to `GetMTime`, it's actually something >> else that's doing on, some bad ptr, access, etc. MTime is different from the >> pipeline time. MTime is just a timestamp on VTK objects to indicate when >> they were last modified, for example. If you share your filter.cxx, I can >> see if I can spot the issue. >> >> Utkarsh >> >> On Tue, Mar 20, 2018 at 1:19 PM, Cornelis Bockem?hl >> wrote: >>> >>> My short question is: I am having some problems to understand time >>> handling in VTK, so I would like to find some documentations that can >>> enlighten me! So far my Google research has only shown me that a) there have >>> been different approaches in the past (which I do not need to understand) >>> and b) there are many more options available than I will ever need to use... >>> >>> The specific problem that I am dealing with is in a project. In a filter >>> that is supposed to run inside ParaView I am programmatically generating a >>> time series of unsigned grids and tables, i.e. the filter has several >>> several output ports that all have to change per time step. Empirically I >>> found out that I have to put this code into RequestInformation: >>> >>> // tell the caller that we can provide time varying data and specify >>> the range >>> >>> double tRange[] = {0., 1.}; >>> >>> >>> // generate a vector with the steps - from 0 to NumSteps >>> >>> Steps.resize(NumPeriods + 1); >>> >>> for(int s = 0; s <= NumPeriods; ++s) >>> >>> Steps[s] = (double)s / (double)NumPeriods; >>> >>> >>> for(int n = 0; n < GetNumberOfOutputPorts(); ++n) >>> >>> { >>> >>> vtkInformation* info = outputVector->GetInformationObject(n); >>> >>> info->Set(vtkStreamingDemandDrivenPipeline::TIME_RANGE(), tRange, >>> 2); >>> >>> info->Set(vtkStreamingDemandDrivenPipeline::TIME_STEPS(), >>> Steps.data(), Steps.size()); >>> >>> info->Set(CAN_HANDLE_PIECE_REQUEST(), 1); >>> >>> } >>> >>> >>> Some of the calculations are a bit tedious, so I am caching many data in >>> the filter object, but not more than so far required. This means that in >>> RequestData a decision has to be taken if more data need to be calculated >>> first, or else directly copy from the cached data, like for example this: >>> >>> - jump to step 5 of 20 directly -> calculate steps 1 - 2 - 3 - 4 - 5 >>> internally, then copy data from step 5 to the output ports >>> >>> - jump back to step 3 -> simply copy the data from step 3 to the output >>> ports >>> >>> - jump to step 7 -> calculate steps 6 - 7, then copy etc. >>> >>> During the calculations I am using other filters for some data >>> processing, not attached to the pipeline, for some data transformations. For >>> some time this worked now "somehow", but now I am suddenly getting crashes >>> in one of these "detached filters" - when some "trivial producer" wants to >>> ask for MTime - which is completely irrelevant in that context... >>> >>> In other words: I am now a bit confused - and at the same time I am >>> afraid that I cannot easily strip down my problem to a size that I can >>> easily share! >>> >>> Specifically I am not sure which way to try further: >>> >>> - somehow "tell the filters" that they should not care about time? >>> >>> - reconsider my caching because maybe it interferes with some similar >>> functionality that is already built into ParaView? >>> >>> - somehow "tell" the output unstructured grids and tables which is their >>> current MTime? But so far I thought I had understood that this is managed by >>> ParaView, not by the data objects... >>> >>> ...but then some of the data objects have a GetMTime function, but no way >>> to explicitly set this fabulous MTime: where does it come from? >>> >>> Actually such a call is the location where the program crashes! >>> >>> Regards, >>> Cornelis Bockem?hl >>> >>> ______________________________ _________________ >>> 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: >>> https://public.kitware.com/mailman/listinfo/paraview-developers >>> >> > From andy.bauer at kitware.com Tue Mar 20 20:35:05 2018 From: andy.bauer at kitware.com (Andy Bauer) Date: Tue, 20 Mar 2018 20:35:05 -0400 Subject: [Paraview-developers] FW: [EXTERNAL] Re: ParaView | Memory consumption on Paraview (#18035) In-Reply-To: References: Message-ID: Going back to the Merge Blocks filter, I'd say that if the input grid is a vtkUnstructuredGrid and there's only a single block on that process in this case the Merge Blocks filter should do a shallow copy and exit quickly, which it doesn't do. This isn't a silver bullet fix and probably won't matter after the composite dataset rework but for what LANL wants in this case, this would be a very simple and efficient solution. On Tue, Mar 20, 2018 at 6:00 PM, Boonthanome Nouanesengsy wrote: > Unless I am missing something, no reason. Seems to me that's just the >> way it was written. I can't see why the filter can't request 1 extra >> ghost-level from its input. (cc, Berk). >> > Because we start with cell data, we actually require two layers of ghost > cells. The ghost cells filter was developed to allocate as many layers of > ghost cells as needed for a distributed dataset. > > Any other ideas how to decrease the bloat of about 4 GB of data to be about >> 18 GB of data? >> Is this for a Catalyst or pvbatch pipeline or for an interactive session? >> > It's for an interactive session. We have a user running out of memory > trying to use a certain pipeline. More information is in the issue at > https://gitlab.kitware.com/paraview/paraview/issues/18035 > > Boonth > > > > On 03/20/2018 03:08 PM, Utkarsh Ayachit wrote: > >> Why does merge blocks grow so much? Why can?t this filter just do shallow >>> copies? Is this impossible, or just not implemented? >>> >> No, merge blocks is not a shallow copy, it needs to combine mutliple >> vtkDataSet's into a single vtkDataSet merging all points into a single >> array, same for cells, other attribute arrays etc. Merge Blocks should >> indeed be considered as a workaround for issue when handling >> mutliblock datasets in the pipeline and not the go-to solution. There >> is work currently underway that will revamp multiblock dataset support >> in VTK/ParaView which should ultimately make Merge Blocks obsolete. >> >> Looking at your pipeline, looks like you're doing MergeBlocks so that >> you can run the Ghost Cells generator filter. What is the nature of >> your data? Is it truly a multiblock or just has 1 block in it on each >> rank? If its just 1 block, what is the type of the block? If it's a >> unstructured grid, it will trivial to create a filter that just passes >> the input block out as unstructured grid without duplicating. >> >> Why can?t Merge Blocks do shallow copies? Is this impossible, or just not >>> implemented? >>> >> It's impossible. See previous comment for justification based on how >> things are currently. >> >> (I think I know this one, but here it is). Why does the ghost cell >>> generator bloat memory so much? Can?t you just use shallow copies of the >>> primary data, and then add the ghost cells? >>> >> adding ghost cell etc, means adding new elements to existing arrays. >> since vtk doesn't modify input arrays, when it needs to add new >> elements, it has to create a deep-copy and then add new elements to >> it. >> >> Why can?t we have the cell data to point data filter be smart enough to >>> add >>> ghost cells if necessary for calculations, then throw them away? >>> >> Unless I am missing something, no reason. Seems to me that's just the >> way it was written. I can't see why the filter can't request 1 extra >> ghost-level from its input. (cc, Berk). >> >> Any other ideas how to decrease the bloat of about 4 GB of data to be >>> about >>> 18 GB of data? >>> >> Is this for a Catalyst or pvbatch pipeline or for an interactive session? >> >> Utkarsh >> _______________________________________________ >> 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: >> https://public.kitware.com/mailman/listinfo/paraview-developers >> > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensou > rce/opensource.html > > Search the list archives at: http://markmail.org/search/?q= > Paraview-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/paraview-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wascott at sandia.gov Tue Mar 20 20:37:42 2018 From: wascott at sandia.gov (Scott, W Alan) Date: Wed, 21 Mar 2018 00:37:42 +0000 Subject: [Paraview-developers] FW: [EXTERNAL] Re: ParaView | Memory consumption on Paraview (#18035) In-Reply-To: References: Message-ID: Andy, I assume we are way too late in the release process to implement this for 5.5.0. John P., should this be implemented early next release, so you can build an alpha/ master build? Or will you just wait for 5.6.0, out early fall, which should make this question irrelevant? Alan From: Andy Bauer [mailto:andy.bauer at kitware.com] Sent: Tuesday, March 20, 2018 6:35 PM To: Nouanesengsy, Boonthanome (LANL) Cc: Ayachit, Utkarsh (External Contacts) ; Scott, W Alan ; paraview-developers at paraview.org; Patchett, John M. (LANL) Subject: Re: [Paraview-developers] FW: [EXTERNAL] Re: ParaView | Memory consumption on Paraview (#18035) Going back to the Merge Blocks filter, I'd say that if the input grid is a vtkUnstructuredGrid and there's only a single block on that process in this case the Merge Blocks filter should do a shallow copy and exit quickly, which it doesn't do. This isn't a silver bullet fix and probably won't matter after the composite dataset rework but for what LANL wants in this case, this would be a very simple and efficient solution. On Tue, Mar 20, 2018 at 6:00 PM, Boonthanome Nouanesengsy > wrote: Unless I am missing something, no reason. Seems to me that's just the way it was written. I can't see why the filter can't request 1 extra ghost-level from its input. (cc, Berk). Because we start with cell data, we actually require two layers of ghost cells. The ghost cells filter was developed to allocate as many layers of ghost cells as needed for a distributed dataset. Any other ideas how to decrease the bloat of about 4 GB of data to be about 18 GB of data? Is this for a Catalyst or pvbatch pipeline or for an interactive session? It's for an interactive session. We have a user running out of memory trying to use a certain pipeline. More information is in the issue at https://gitlab.kitware.com/paraview/paraview/issues/18035 Boonth On 03/20/2018 03:08 PM, Utkarsh Ayachit wrote: Why does merge blocks grow so much? Why can?t this filter just do shallow copies? Is this impossible, or just not implemented? No, merge blocks is not a shallow copy, it needs to combine mutliple vtkDataSet's into a single vtkDataSet merging all points into a single array, same for cells, other attribute arrays etc. Merge Blocks should indeed be considered as a workaround for issue when handling mutliblock datasets in the pipeline and not the go-to solution. There is work currently underway that will revamp multiblock dataset support in VTK/ParaView which should ultimately make Merge Blocks obsolete. Looking at your pipeline, looks like you're doing MergeBlocks so that you can run the Ghost Cells generator filter. What is the nature of your data? Is it truly a multiblock or just has 1 block in it on each rank? If its just 1 block, what is the type of the block? If it's a unstructured grid, it will trivial to create a filter that just passes the input block out as unstructured grid without duplicating. Why can?t Merge Blocks do shallow copies? Is this impossible, or just not implemented? It's impossible. See previous comment for justification based on how things are currently. (I think I know this one, but here it is). Why does the ghost cell generator bloat memory so much? Can?t you just use shallow copies of the primary data, and then add the ghost cells? adding ghost cell etc, means adding new elements to existing arrays. since vtk doesn't modify input arrays, when it needs to add new elements, it has to create a deep-copy and then add new elements to it. Why can?t we have the cell data to point data filter be smart enough to add ghost cells if necessary for calculations, then throw them away? Unless I am missing something, no reason. Seems to me that's just the way it was written. I can't see why the filter can't request 1 extra ghost-level from its input. (cc, Berk). Any other ideas how to decrease the bloat of about 4 GB of data to be about 18 GB of data? Is this for a Catalyst or pvbatch pipeline or for an interactive session? Utkarsh _______________________________________________ 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: https://public.kitware.com/mailman/listinfo/paraview-developers _______________________________________________ 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: https://public.kitware.com/mailman/listinfo/paraview-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.bauer at kitware.com Tue Mar 20 20:43:42 2018 From: andy.bauer at kitware.com (Andy Bauer) Date: Tue, 20 Mar 2018 20:43:42 -0400 Subject: [Paraview-developers] FW: [EXTERNAL] Re: ParaView | Memory consumption on Paraview (#18035) In-Reply-To: References: Message-ID: Well, I could probably have this done by tomorrow but in the end I leave the decision on whether we wait on the release for this change to Utkarsh and Cory. I'm not sure how much of a wrench it would put into their plans. On the other hand, if this is really the specific use case then a Python Programmable Filter could just as easily do the trick and would be nearly negligible cost. In fact, I'll put together the a python script that does that and send it out shortly. On Tue, Mar 20, 2018 at 8:37 PM, Scott, W Alan wrote: > Andy, > > I assume we are way too late in the release process to implement this for > 5.5.0. > > > > John P., should this be implemented early next release, so you can build > an alpha/ master build? Or will you just wait for 5.6.0, out early fall, > which should make this question irrelevant? > > > > Alan > > > > *From:* Andy Bauer [mailto:andy.bauer at kitware.com] > *Sent:* Tuesday, March 20, 2018 6:35 PM > *To:* Nouanesengsy, Boonthanome (LANL) > *Cc:* Ayachit, Utkarsh (External Contacts) ; > Scott, W Alan ; paraview-developers at paraview.org; > Patchett, John M. (LANL) > *Subject:* Re: [Paraview-developers] FW: [EXTERNAL] Re: ParaView | Memory > consumption on Paraview (#18035) > > > > Going back to the Merge Blocks filter, I'd say that if the input grid is a > vtkUnstructuredGrid and there's only a single block on that process in this > case the Merge Blocks filter should do a shallow copy and exit quickly, > which it doesn't do. This isn't a silver bullet fix and probably won't > matter after the composite dataset rework but for what LANL wants in this > case, this would be a very simple and efficient solution. > > > > On Tue, Mar 20, 2018 at 6:00 PM, Boonthanome Nouanesengsy > wrote: > > Unless I am missing something, no reason. Seems to me that's just the > way it was written. I can't see why the filter can't request 1 extra > ghost-level from its input. (cc, Berk). > > Because we start with cell data, we actually require two layers of ghost > cells. The ghost cells filter was developed to allocate as many layers of > ghost cells as needed for a distributed dataset. > > Any other ideas how to decrease the bloat of about 4 GB of data to be about > 18 GB of data? > Is this for a Catalyst or pvbatch pipeline or for an interactive session? > > It's for an interactive session. We have a user running out of memory > trying to use a certain pipeline. More information is in the issue at > https://gitlab.kitware.com/paraview/paraview/issues/18035 > > Boonth > > > > > On 03/20/2018 03:08 PM, Utkarsh Ayachit wrote: > > Why does merge blocks grow so much? Why can?t this filter just do shallow > copies? Is this impossible, or just not implemented? > > No, merge blocks is not a shallow copy, it needs to combine mutliple > vtkDataSet's into a single vtkDataSet merging all points into a single > array, same for cells, other attribute arrays etc. Merge Blocks should > indeed be considered as a workaround for issue when handling > mutliblock datasets in the pipeline and not the go-to solution. There > is work currently underway that will revamp multiblock dataset support > in VTK/ParaView which should ultimately make Merge Blocks obsolete. > > Looking at your pipeline, looks like you're doing MergeBlocks so that > you can run the Ghost Cells generator filter. What is the nature of > your data? Is it truly a multiblock or just has 1 block in it on each > rank? If its just 1 block, what is the type of the block? If it's a > unstructured grid, it will trivial to create a filter that just passes > the input block out as unstructured grid without duplicating. > > Why can?t Merge Blocks do shallow copies? Is this impossible, or just not > implemented? > > It's impossible. See previous comment for justification based on how > things are currently. > > (I think I know this one, but here it is). Why does the ghost cell > generator bloat memory so much? Can?t you just use shallow copies of the > primary data, and then add the ghost cells? > > adding ghost cell etc, means adding new elements to existing arrays. > since vtk doesn't modify input arrays, when it needs to add new > elements, it has to create a deep-copy and then add new elements to > it. > > Why can?t we have the cell data to point data filter be smart enough to add > ghost cells if necessary for calculations, then throw them away? > > Unless I am missing something, no reason. Seems to me that's just the > way it was written. I can't see why the filter can't request 1 extra > ghost-level from its input. (cc, Berk). > > Any other ideas how to decrease the bloat of about 4 GB of data to be about > 18 GB of data? > > Is this for a Catalyst or pvbatch pipeline or for an interactive session? > > Utkarsh > _______________________________________________ > 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: > https://public.kitware.com/mailman/listinfo/paraview-developers > > > _______________________________________________ > 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: > https://public.kitware.com/mailman/listinfo/paraview-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wascott at sandia.gov Tue Mar 20 20:45:32 2018 From: wascott at sandia.gov (Scott, W Alan) Date: Wed, 21 Mar 2018 00:45:32 +0000 Subject: [Paraview-developers] FW: [EXTERNAL] Re: ParaView | Memory consumption on Paraview (#18035) In-Reply-To: References: Message-ID: Excellent. I?m much more interested in a python programmable filter solution, since it can?t destabilize the code base! Thanks Andy! Alan From: Andy Bauer [mailto:andy.bauer at kitware.com] Sent: Tuesday, March 20, 2018 6:44 PM To: Scott, W Alan Cc: Nouanesengsy, Boonthanome (LANL) ; Ayachit, Utkarsh (External Contacts) ; paraview-developers at paraview.org; Patchett, John M. (LANL) Subject: Re: [Paraview-developers] FW: [EXTERNAL] Re: ParaView | Memory consumption on Paraview (#18035) Well, I could probably have this done by tomorrow but in the end I leave the decision on whether we wait on the release for this change to Utkarsh and Cory. I'm not sure how much of a wrench it would put into their plans. On the other hand, if this is really the specific use case then a Python Programmable Filter could just as easily do the trick and would be nearly negligible cost. In fact, I'll put together the a python script that does that and send it out shortly. On Tue, Mar 20, 2018 at 8:37 PM, Scott, W Alan > wrote: Andy, I assume we are way too late in the release process to implement this for 5.5.0. John P., should this be implemented early next release, so you can build an alpha/ master build? Or will you just wait for 5.6.0, out early fall, which should make this question irrelevant? Alan From: Andy Bauer [mailto:andy.bauer at kitware.com] Sent: Tuesday, March 20, 2018 6:35 PM To: Nouanesengsy, Boonthanome (LANL) > Cc: Ayachit, Utkarsh (External Contacts) >; Scott, W Alan >; paraview-developers at paraview.org; Patchett, John M. (LANL) > Subject: Re: [Paraview-developers] FW: [EXTERNAL] Re: ParaView | Memory consumption on Paraview (#18035) Going back to the Merge Blocks filter, I'd say that if the input grid is a vtkUnstructuredGrid and there's only a single block on that process in this case the Merge Blocks filter should do a shallow copy and exit quickly, which it doesn't do. This isn't a silver bullet fix and probably won't matter after the composite dataset rework but for what LANL wants in this case, this would be a very simple and efficient solution. On Tue, Mar 20, 2018 at 6:00 PM, Boonthanome Nouanesengsy > wrote: Unless I am missing something, no reason. Seems to me that's just the way it was written. I can't see why the filter can't request 1 extra ghost-level from its input. (cc, Berk). Because we start with cell data, we actually require two layers of ghost cells. The ghost cells filter was developed to allocate as many layers of ghost cells as needed for a distributed dataset. Any other ideas how to decrease the bloat of about 4 GB of data to be about 18 GB of data? Is this for a Catalyst or pvbatch pipeline or for an interactive session? It's for an interactive session. We have a user running out of memory trying to use a certain pipeline. More information is in the issue at https://gitlab.kitware.com/paraview/paraview/issues/18035 Boonth On 03/20/2018 03:08 PM, Utkarsh Ayachit wrote: Why does merge blocks grow so much? Why can?t this filter just do shallow copies? Is this impossible, or just not implemented? No, merge blocks is not a shallow copy, it needs to combine mutliple vtkDataSet's into a single vtkDataSet merging all points into a single array, same for cells, other attribute arrays etc. Merge Blocks should indeed be considered as a workaround for issue when handling mutliblock datasets in the pipeline and not the go-to solution. There is work currently underway that will revamp multiblock dataset support in VTK/ParaView which should ultimately make Merge Blocks obsolete. Looking at your pipeline, looks like you're doing MergeBlocks so that you can run the Ghost Cells generator filter. What is the nature of your data? Is it truly a multiblock or just has 1 block in it on each rank? If its just 1 block, what is the type of the block? If it's a unstructured grid, it will trivial to create a filter that just passes the input block out as unstructured grid without duplicating. Why can?t Merge Blocks do shallow copies? Is this impossible, or just not implemented? It's impossible. See previous comment for justification based on how things are currently. (I think I know this one, but here it is). Why does the ghost cell generator bloat memory so much? Can?t you just use shallow copies of the primary data, and then add the ghost cells? adding ghost cell etc, means adding new elements to existing arrays. since vtk doesn't modify input arrays, when it needs to add new elements, it has to create a deep-copy and then add new elements to it. Why can?t we have the cell data to point data filter be smart enough to add ghost cells if necessary for calculations, then throw them away? Unless I am missing something, no reason. Seems to me that's just the way it was written. I can't see why the filter can't request 1 extra ghost-level from its input. (cc, Berk). Any other ideas how to decrease the bloat of about 4 GB of data to be about 18 GB of data? Is this for a Catalyst or pvbatch pipeline or for an interactive session? Utkarsh _______________________________________________ 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: https://public.kitware.com/mailman/listinfo/paraview-developers _______________________________________________ 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: https://public.kitware.com/mailman/listinfo/paraview-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From cory.quammen at kitware.com Tue Mar 20 21:27:18 2018 From: cory.quammen at kitware.com (Cory Quammen) Date: Tue, 20 Mar 2018 21:27:18 -0400 Subject: [Paraview-developers] FW: [EXTERNAL] Re: ParaView | Memory consumption on Paraview (#18035) In-Reply-To: References: Message-ID: On Tue, Mar 20, 2018 at 8:43 PM, Andy Bauer wrote: > Well, I could probably have this done by tomorrow but in the end I leave > the decision on whether we wait on the release for this change to Utkarsh > and Cory. I'm not sure how much of a wrench it would put into their plans. > In my judgement, it's too late to put this in 5.5. It may seem like a simple change, but experience shows time and again that simple changes do not exist :-) We do not have sufficient time to test it and get feedback prior to the release. > On the other hand, if this is really the specific use case then a Python > Programmable Filter could just as easily do the trick and would be nearly > negligible cost. In fact, I'll put together the a python script that does > that and send it out shortly. > Sounds like a good plan. Thanks, Cory > On Tue, Mar 20, 2018 at 8:37 PM, Scott, W Alan wrote: > >> Andy, >> >> I assume we are way too late in the release process to implement this for >> 5.5.0. >> >> >> >> John P., should this be implemented early next release, so you can build >> an alpha/ master build? Or will you just wait for 5.6.0, out early fall, >> which should make this question irrelevant? >> >> >> >> Alan >> >> >> >> *From:* Andy Bauer [mailto:andy.bauer at kitware.com] >> *Sent:* Tuesday, March 20, 2018 6:35 PM >> *To:* Nouanesengsy, Boonthanome (LANL) >> *Cc:* Ayachit, Utkarsh (External Contacts) ; >> Scott, W Alan ; paraview-developers at paraview.org; >> Patchett, John M. (LANL) >> *Subject:* Re: [Paraview-developers] FW: [EXTERNAL] Re: ParaView | >> Memory consumption on Paraview (#18035) >> >> >> >> Going back to the Merge Blocks filter, I'd say that if the input grid is >> a vtkUnstructuredGrid and there's only a single block on that process in >> this case the Merge Blocks filter should do a shallow copy and exit >> quickly, which it doesn't do. This isn't a silver bullet fix and probably >> won't matter after the composite dataset rework but for what LANL wants in >> this case, this would be a very simple and efficient solution. >> >> >> >> On Tue, Mar 20, 2018 at 6:00 PM, Boonthanome Nouanesengsy < >> boonth at lanl.gov> wrote: >> >> Unless I am missing something, no reason. Seems to me that's just the >> way it was written. I can't see why the filter can't request 1 extra >> ghost-level from its input. (cc, Berk). >> >> Because we start with cell data, we actually require two layers of ghost >> cells. The ghost cells filter was developed to allocate as many layers of >> ghost cells as needed for a distributed dataset. >> >> Any other ideas how to decrease the bloat of about 4 GB of data to be >> about >> 18 GB of data? >> Is this for a Catalyst or pvbatch pipeline or for an interactive session? >> >> It's for an interactive session. We have a user running out of memory >> trying to use a certain pipeline. More information is in the issue at >> https://gitlab.kitware.com/paraview/paraview/issues/18035 >> >> Boonth >> >> >> >> >> On 03/20/2018 03:08 PM, Utkarsh Ayachit wrote: >> >> Why does merge blocks grow so much? Why can?t this filter just do shallow >> copies? Is this impossible, or just not implemented? >> >> No, merge blocks is not a shallow copy, it needs to combine mutliple >> vtkDataSet's into a single vtkDataSet merging all points into a single >> array, same for cells, other attribute arrays etc. Merge Blocks should >> indeed be considered as a workaround for issue when handling >> mutliblock datasets in the pipeline and not the go-to solution. There >> is work currently underway that will revamp multiblock dataset support >> in VTK/ParaView which should ultimately make Merge Blocks obsolete. >> >> Looking at your pipeline, looks like you're doing MergeBlocks so that >> you can run the Ghost Cells generator filter. What is the nature of >> your data? Is it truly a multiblock or just has 1 block in it on each >> rank? If its just 1 block, what is the type of the block? If it's a >> unstructured grid, it will trivial to create a filter that just passes >> the input block out as unstructured grid without duplicating. >> >> Why can?t Merge Blocks do shallow copies? Is this impossible, or just not >> implemented? >> >> It's impossible. See previous comment for justification based on how >> things are currently. >> >> (I think I know this one, but here it is). Why does the ghost cell >> generator bloat memory so much? Can?t you just use shallow copies of the >> primary data, and then add the ghost cells? >> >> adding ghost cell etc, means adding new elements to existing arrays. >> since vtk doesn't modify input arrays, when it needs to add new >> elements, it has to create a deep-copy and then add new elements to >> it. >> >> Why can?t we have the cell data to point data filter be smart enough to >> add >> ghost cells if necessary for calculations, then throw them away? >> >> Unless I am missing something, no reason. Seems to me that's just the >> way it was written. I can't see why the filter can't request 1 extra >> ghost-level from its input. (cc, Berk). >> >> Any other ideas how to decrease the bloat of about 4 GB of data to be >> about >> 18 GB of data? >> >> Is this for a Catalyst or pvbatch pipeline or for an interactive session? >> >> Utkarsh >> _______________________________________________ >> 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: >> https://public.kitware.com/mailman/listinfo/paraview-developers >> >> >> _______________________________________________ >> 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: >> https://public.kitware.com/mailman/listinfo/paraview-developers >> >> >> > > > _______________________________________________ > 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: > https://public.kitware.com/mailman/listinfo/paraview-developers > > -- Cory Quammen Staff R&D Engineer Kitware, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wascott at sandia.gov Tue Mar 20 22:18:22 2018 From: wascott at sandia.gov (Scott, W Alan) Date: Wed, 21 Mar 2018 02:18:22 +0000 Subject: [Paraview-developers] FW: [EXTERNAL] Re: ParaView | Memory consumption on Paraview (#18035) In-Reply-To: References: Message-ID: Totally, totally agree. Lets go with the programmable filter solution. From: Cory Quammen [mailto:cory.quammen at kitware.com] Sent: Tuesday, March 20, 2018 7:27 PM To: Bauer, Andy (External Contacts) Cc: Scott, W Alan ; paraview-developers at paraview.org; Patchett, John M. (LANL) Subject: Re: [Paraview-developers] FW: [EXTERNAL] Re: ParaView | Memory consumption on Paraview (#18035) On Tue, Mar 20, 2018 at 8:43 PM, Andy Bauer > wrote: Well, I could probably have this done by tomorrow but in the end I leave the decision on whether we wait on the release for this change to Utkarsh and Cory. I'm not sure how much of a wrench it would put into their plans. In my judgement, it's too late to put this in 5.5. It may seem like a simple change, but experience shows time and again that simple changes do not exist :-) We do not have sufficient time to test it and get feedback prior to the release. On the other hand, if this is really the specific use case then a Python Programmable Filter could just as easily do the trick and would be nearly negligible cost. In fact, I'll put together the a python script that does that and send it out shortly. Sounds like a good plan. Thanks, Cory On Tue, Mar 20, 2018 at 8:37 PM, Scott, W Alan > wrote: Andy, I assume we are way too late in the release process to implement this for 5.5.0. John P., should this be implemented early next release, so you can build an alpha/ master build? Or will you just wait for 5.6.0, out early fall, which should make this question irrelevant? Alan From: Andy Bauer [mailto:andy.bauer at kitware.com] Sent: Tuesday, March 20, 2018 6:35 PM To: Nouanesengsy, Boonthanome (LANL) > Cc: Ayachit, Utkarsh (External Contacts) >; Scott, W Alan >; paraview-developers at paraview.org; Patchett, John M. (LANL) > Subject: Re: [Paraview-developers] FW: [EXTERNAL] Re: ParaView | Memory consumption on Paraview (#18035) Going back to the Merge Blocks filter, I'd say that if the input grid is a vtkUnstructuredGrid and there's only a single block on that process in this case the Merge Blocks filter should do a shallow copy and exit quickly, which it doesn't do. This isn't a silver bullet fix and probably won't matter after the composite dataset rework but for what LANL wants in this case, this would be a very simple and efficient solution. On Tue, Mar 20, 2018 at 6:00 PM, Boonthanome Nouanesengsy > wrote: Unless I am missing something, no reason. Seems to me that's just the way it was written. I can't see why the filter can't request 1 extra ghost-level from its input. (cc, Berk). Because we start with cell data, we actually require two layers of ghost cells. The ghost cells filter was developed to allocate as many layers of ghost cells as needed for a distributed dataset. Any other ideas how to decrease the bloat of about 4 GB of data to be about 18 GB of data? Is this for a Catalyst or pvbatch pipeline or for an interactive session? It's for an interactive session. We have a user running out of memory trying to use a certain pipeline. More information is in the issue at https://gitlab.kitware.com/paraview/paraview/issues/18035 Boonth On 03/20/2018 03:08 PM, Utkarsh Ayachit wrote: Why does merge blocks grow so much? Why can?t this filter just do shallow copies? Is this impossible, or just not implemented? No, merge blocks is not a shallow copy, it needs to combine mutliple vtkDataSet's into a single vtkDataSet merging all points into a single array, same for cells, other attribute arrays etc. Merge Blocks should indeed be considered as a workaround for issue when handling mutliblock datasets in the pipeline and not the go-to solution. There is work currently underway that will revamp multiblock dataset support in VTK/ParaView which should ultimately make Merge Blocks obsolete. Looking at your pipeline, looks like you're doing MergeBlocks so that you can run the Ghost Cells generator filter. What is the nature of your data? Is it truly a multiblock or just has 1 block in it on each rank? If its just 1 block, what is the type of the block? If it's a unstructured grid, it will trivial to create a filter that just passes the input block out as unstructured grid without duplicating. Why can?t Merge Blocks do shallow copies? Is this impossible, or just not implemented? It's impossible. See previous comment for justification based on how things are currently. (I think I know this one, but here it is). Why does the ghost cell generator bloat memory so much? Can?t you just use shallow copies of the primary data, and then add the ghost cells? adding ghost cell etc, means adding new elements to existing arrays. since vtk doesn't modify input arrays, when it needs to add new elements, it has to create a deep-copy and then add new elements to it. Why can?t we have the cell data to point data filter be smart enough to add ghost cells if necessary for calculations, then throw them away? Unless I am missing something, no reason. Seems to me that's just the way it was written. I can't see why the filter can't request 1 extra ghost-level from its input. (cc, Berk). Any other ideas how to decrease the bloat of about 4 GB of data to be about 18 GB of data? Is this for a Catalyst or pvbatch pipeline or for an interactive session? Utkarsh _______________________________________________ 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: https://public.kitware.com/mailman/listinfo/paraview-developers _______________________________________________ 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: https://public.kitware.com/mailman/listinfo/paraview-developers _______________________________________________ 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: https://public.kitware.com/mailman/listinfo/paraview-developers -- Cory Quammen Staff R&D Engineer Kitware, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cornelis.bockemuehl at gmail.com Wed Mar 21 06:03:11 2018 From: cornelis.bockemuehl at gmail.com (Cornelis =?ISO-8859-1?Q?Bockem=FChl?=) Date: Wed, 21 Mar 2018 11:03:11 +0100 Subject: [Paraview-developers] Timing - once more... Message-ID: <1521626591.3431.74.camel@gmail.com> Dear all, My previous question regarding time series and MTime seems to be fixed now (including the memory issues!), but there is still a problem that is obviously really related to animation sequence time handling and which I also need to eventually address. The symptom was that my different output views (render view, table view) in ParaView were often not really all correctly synchronized with the time that I set in the time selector in the toolbar. The code that I put into RequestInformation basically defines the timesteps for all output ports: I posted it in my previous question and Utkarsh Ayachit considered it so far ok. Now in my RequestData function I am retrieving the required time with the following code: info = outputVector->GetInformationObject(0); vtkUnstructuredGrid* outFullGrid = vtkUnstructuredGrid::SafeDownCas t(info->Get(vtkDataObject::DATA_OBJECT())); double reqTime = 0.; if(info->Has(vtkStreamingDemandDrivenPipeline::UPDATE_TIME_STEP())) reqTime = info->Get(vtkStreamingDemandDrivenPipeline::UPDATE_TI ME_STEP()); In other words: I am referring to the info object for the first output port (which happens to refer to an unstructured grid). This always worked for my simple test cases, and "often" it also works now with the more complex setup with many output ports. BUT: it should ALWAYS work! And first of all: It should never simply "stick to some time" - no matter what I do in the time selection toolbar! For testing purposes I added the following code into my RequestData - in order to see whether the time step is the same for all the ports: std::cout << "SEE WHICH TIMES I GET FROM OUTPUT INFOS" << std::endl ; for(int op = 0; op < GetNumberOfOutputPorts(); ++op) { vtkInformation* oinfo = outputVector->GetInformationObject(op); if(oinfo->Has(vtkStreamingDemandDrivenPipeline::UPDATE_TIME_STE P())) { double ot = oinfo->Get(vtkStreamingDemandDrivenPipeline::UP DATE_TIME_STEP()); std::cout << "output port " << op << " has time " << ot << std::endl; } else { std::cout << "output port " << op << " has no time" << std: :endl; } } The amazing finding is: no, you do NOT always get the same time for all the output port! By turning the view for different output ports on and off and also moving a little up and down along the time axis, this is a typical kind of output from the above test code: SEE WHICH TIMES I GET FROM OUTPUT INFOS output port 0 has time 0.05 output port 1 has time 0.1 output port 2 has time 0.05 output port 3 has time 0.2 output port 4 has time 0.05 output port 5 has time 0.2 output port 6 has time 0.2 output port 7 has time 0.2 Obviously this is not very consitent! The time step that is displayed in the timer tool bar is 0.1 at the same moment (so obviously not even the last move from 0.05 to 0.1 triggered a call to RequestData), and what I was trying to watch was the output from port 4. Basically I see that ParaView is that either I am missing still some more checking to find out which of the output port times are really the valid ones, or ParaView is trying to do some optimizations that are not fitting with my "simplistic approach" of just getting the time from output port 0 - or both. Any helpful hints on that one? Thanks for all and regards, Cornelis -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Wed Mar 21 08:36:27 2018 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Wed, 21 Mar 2018 08:36:27 -0400 Subject: [Paraview-developers] Timing - once more... In-Reply-To: <1521626591.3431.74.camel@gmail.com> References: <1521626591.3431.74.camel@gmail.com> Message-ID: Cornelis, The `request` vtkInformation object passed to the any of the Request() methods on an algorithm has a key named vtkExecutive::FROM_OUTPUT_PORT() which indicates which port that request is coming from. Use that determine what time is being requested in the current pass. Yes, VTK indeed updates the pipelines that fan out separately for each output port with the update request coming down each fanned out branch. Utkarsh p.s Berk has a series of blogs that is a good read to understand the VTK pipeline https://blog.kitware.com/?p=12491 https://blog.kitware.com/?p=12489 https://blog.kitware.com/?p=12480 On Wed, Mar 21, 2018 at 6:03 AM, Cornelis Bockem?hl wrote: > Dear all, > > My previous question regarding time series and MTime seems to be fixed now > (including the memory issues!), but there is still a problem that is > obviously really related to animation sequence time handling and which I > also need to eventually address. The symptom was that my different output > views (render view, table view) in ParaView were often not really all > correctly synchronized with the time that I set in the time selector in the > toolbar. > > The code that I put into RequestInformation basically defines the timesteps > for all output ports: I posted it in my previous question and Utkarsh > Ayachit considered it so far ok. > > Now in my RequestData function I am retrieving the required time with the > following code: > > info = outputVector->GetInformationObject(0); > > vtkUnstructuredGrid* outFullGrid = > vtkUnstructuredGrid::SafeDownCast(info->Get(vtkDataObject::DATA_OBJECT())); > > double reqTime = 0.; > > if(info->Has(vtkStreamingDemandDrivenPipeline::UPDATE_TIME_STEP())) > > reqTime = > info->Get(vtkStreamingDemandDrivenPipeline::UPDATE_TIME_STEP()); > > > In other words: I am referring to the info object for the first output port > (which happens to refer to an unstructured grid). This always worked for my > simple test cases, and "often" it also works now with the more complex setup > with many output ports. BUT: it should ALWAYS work! And first of all: It > should never simply "stick to some time" - no matter what I do in the time > selection toolbar! > > For testing purposes I added the following code into my RequestData - in > order to see whether the time step is the same for all the ports: > > std::cout << "SEE WHICH TIMES I GET FROM OUTPUT INFOS" << std::endl; > > for(int op = 0; op < GetNumberOfOutputPorts(); ++op) > > { > > vtkInformation* oinfo = outputVector->GetInformationObject(op); > > if(oinfo->Has(vtkStreamingDemandDrivenPipeline::UPDATE_TIME_STEP())) > > { > > double ot = > oinfo->Get(vtkStreamingDemandDrivenPipeline::UPDATE_TIME_STEP()); > > std::cout << "output port " << op << " has time " << ot << > std::endl; > > } > > else > > { > > std::cout << "output port " << op << " has no time" << > std::endl; > > } > > } > > > The amazing finding is: no, you do NOT always get the same time for all the > output port! By turning the view for different output ports on and off and > also moving a little up and down along the time axis, this is a typical kind > of output from the above test code: > > SEE WHICH TIMES I GET FROM OUTPUT INFOS > > output port 0 has time 0.05 > > output port 1 has time 0.1 > > output port 2 has time 0.05 > > output port 3 has time 0.2 > > output port 4 has time 0.05 > > output port 5 has time 0.2 > > output port 6 has time 0.2 > > output port 7 has time 0.2 > > > Obviously this is not very consitent! The time step that is displayed in the > timer tool bar is 0.1 at the same moment (so obviously not even the last > move from 0.05 to 0.1 triggered a call to RequestData), and what I was > trying to watch was the output from port 4. > > Basically I see that ParaView is that either I am missing still some more > checking to find out which of the output port times are really the valid > ones, or ParaView is trying to do some optimizations that are not fitting > with my "simplistic approach" of just getting the time from output port 0 - > or both. > > Any helpful hints on that one? > > Thanks for all and regards, > Cornelis > > _______________________________________________ > 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: > https://public.kitware.com/mailman/listinfo/paraview-developers > From dave.demarle at kitware.com Wed Mar 21 14:45:56 2018 From: dave.demarle at kitware.com (David E DeMarle) Date: Wed, 21 Mar 2018 14:45:56 -0400 Subject: [Paraview-developers] gitlab down for 30 mins to an hour Message-ID: Passing along a note from kitware sysadmin about downtime for a critical security patch. It should be back up before you know it. thanks for the patience 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 boonth at lanl.gov Wed Mar 21 15:06:37 2018 From: boonth at lanl.gov (Boonthanome Nouanesengsy) Date: Wed, 21 Mar 2018 13:06:37 -0600 Subject: [Paraview-developers] FW: [EXTERNAL] Re: ParaView | Memory consumption on Paraview (#18035) In-Reply-To: References: Message-ID: > Boonth or John, would you mind shooting me an email that you got this > email. I'm worried that a spambot may not let this get through based > on the attachments. Yes, got the email. > Going back to the Merge Blocks filter, I'd say that if the input grid > is a vtkUnstructuredGrid and there's only a single block on that > process in this case the Merge Blocks filter should do a shallow copy > and exit quickly, which it doesn't do. This isn't a silver bullet fix > and probably won't matter after the composite dataset rework but for > what LANL wants in this case, this would be a very simple and > efficient solution. The problem is that in many use cases the number of processes used for writing the data will be different from the number of processes used for visualization. In this particular use case it won't help, but thanks for the programmable filter. It should be helpful in the future. Boonth On 03/20/2018 08:18 PM, Scott, W Alan wrote: > > Totally, totally agree.? Lets go with the programmable filter solution. > > *From:* Cory Quammen [mailto:cory.quammen at kitware.com] > *Sent:* Tuesday, March 20, 2018 7:27 PM > *To:* Bauer, Andy (External Contacts) > *Cc:* Scott, W Alan ; > paraview-developers at paraview.org; Patchett, John M. (LANL) > > *Subject:* Re: [Paraview-developers] FW: [EXTERNAL] Re: ParaView | > Memory consumption on Paraview (#18035) > > On Tue, Mar 20, 2018 at 8:43 PM, Andy Bauer > wrote: > > Well, I could probably have this done by tomorrow but in the end I > leave the decision on whether we wait on the release for this > change to Utkarsh and Cory. I'm not sure how much of a wrench it > would put into their plans. > > In my judgement, it's too late to put this in 5.5. It may seem like a > simple change, but experience shows time and again that simple changes > do not exist :-) We do not have sufficient time to test it and get > feedback prior to the release. > > On the other hand, if this is really the specific use case then a > Python Programmable Filter could just as easily do the trick and > would be nearly negligible cost. In fact, I'll put together the a > python script that does that and send it out shortly. > > Sounds like a good plan. > > Thanks, > > Cory > > On Tue, Mar 20, 2018 at 8:37 PM, Scott, W Alan > wrote: > > Andy, > > I assume we are way too late in the release process to > implement this for 5.5.0. > > John P., should this be implemented early next release, so you > can build an alpha/ master build?? Or will you just wait for > 5.6.0, out early fall, which should make this question irrelevant? > > Alan > > *From:* Andy Bauer [mailto:andy.bauer at kitware.com > ] > *Sent:* Tuesday, March 20, 2018 6:35 PM > *To:* Nouanesengsy, Boonthanome (LANL) > > *Cc:* Ayachit, Utkarsh (External Contacts) > >; Scott, W Alan > >; > paraview-developers at paraview.org > ; Patchett, John M. > (LANL) > > *Subject:* Re: [Paraview-developers] FW: [EXTERNAL] Re: > ParaView | Memory consumption on Paraview (#18035) > > Going back to the Merge Blocks filter, I'd say that if the > input grid is a vtkUnstructuredGrid and there's only a single > block on that process in this case the Merge Blocks filter > should do a shallow copy and exit quickly, which it doesn't > do. This isn't a silver bullet fix and probably won't matter > after the composite dataset rework but for what LANL wants in > this case, this would be a very simple and efficient solution. > > On Tue, Mar 20, 2018 at 6:00 PM, Boonthanome Nouanesengsy > > wrote: > > Unless I am missing something, no reason. Seems to me > that's just the > way it was written. I can't see why the filter can't > request 1 extra > ghost-level from its input. (cc, Berk). > > Because we start with cell data, we actually require two > layers of ghost cells. The ghost cells filter was > developed to allocate as many layers of ghost cells as > needed for a distributed dataset. > > Any other ideas how to decrease the bloat of about 4 > GB of data to be about > 18 GB of data? > Is this for a Catalyst or pvbatch pipeline or for an > interactive session? > > It's for an interactive session. We have a user running > out of memory trying to use a certain pipeline. More > information is in the issue at > https://gitlab.kitware.com/paraview/paraview/issues/18035 > > Boonth > > > > > On 03/20/2018 03:08 PM, Utkarsh Ayachit wrote: > > Why does merge blocks grow so much?? Why can?t > this filter just do shallow > copies?? Is this impossible, or just not implemented? > > No, merge blocks is not a shallow copy, it needs to > combine mutliple > vtkDataSet's into a single vtkDataSet merging all > points into a single > array, same for cells, other attribute arrays etc. > Merge Blocks should > indeed be considered as a workaround for issue when > handling > mutliblock datasets in the pipeline and not the go-to > solution. There > is work currently underway that will revamp multiblock > dataset support > in VTK/ParaView which should ultimately make Merge > Blocks obsolete. > > Looking at your pipeline, looks like you're doing > MergeBlocks so that > you can run the Ghost Cells generator filter. What is > the nature of > your data? Is it truly a multiblock or just has 1 > block in it on each > rank? If its just 1 block, what is the type of the > block? If it's a > unstructured grid, it will trivial to create a filter > that just passes > the input block out as unstructured grid without > duplicating. > > Why can?t Merge Blocks do shallow copies? Is this > impossible, or just not > implemented? > > It's impossible. See previous comment for > justification based on how > things are currently. > > (I think I know this one, but here it is).? Why > does the ghost cell > generator bloat memory so much? Can?t you just use > shallow copies of the > primary data, and then add the ghost cells? > > adding ghost cell etc, means adding new elements to > existing arrays. > since vtk doesn't modify input arrays, when it needs > to add new > elements, it has to create a deep-copy and then add > new elements to > it. > > Why can?t we have the cell data to point data > filter be smart enough to add > ghost cells if necessary for calculations, then > throw them away? > > Unless I am missing something, no reason. Seems to me > that's just the > way it was written. I can't see why the filter can't > request 1 extra > ghost-level from its input. (cc, Berk). > > Any other ideas how to decrease the bloat of about > 4 GB of data to be about > 18 GB of data? > > Is this for a Catalyst or pvbatch pipeline or for an > interactive session? > > Utkarsh > _______________________________________________ > 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: > https://public.kitware.com/mailman/listinfo/paraview-developers > > > _______________________________________________ > 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: > https://public.kitware.com/mailman/listinfo/paraview-developers > > > _______________________________________________ > 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: > https://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: > https://public.kitware.com/mailman/listinfo/paraview-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.bauer at kitware.com Wed Mar 21 15:15:42 2018 From: andy.bauer at kitware.com (Andy Bauer) Date: Wed, 21 Mar 2018 15:15:42 -0400 Subject: [Paraview-developers] FW: [EXTERNAL] Re: ParaView | Memory consumption on Paraview (#18035) In-Reply-To: References: Message-ID: On Wed, Mar 21, 2018 at 3:06 PM, Boonthanome Nouanesengsy wrote: > Boonth or John, would you mind shooting me an email that you got this > email. I'm worried that a spambot may not let this get through based on the > attachments. > > Yes, got the email. > > Going back to the Merge Blocks filter, I'd say that if the input grid is a > vtkUnstructuredGrid and there's only a single block on that process in this > case the Merge Blocks filter should do a shallow copy and exit quickly, > which it doesn't do. This isn't a silver bullet fix and probably won't > matter after the composite dataset rework but for what LANL wants in this > case, this would be a very simple and efficient solution. > > The problem is that in many use cases the number of processes used for > writing the data will be different from the number of processes used for > visualization. In this particular use case it won't help, but thanks for > the programmable filter. It should be helpful in the future. > If multiple blocks per MPI rank is the case then there's currently no way around the memory consumption in the merge blocks filter. In the past there were discussions about "cleaning out a pipeline" where the thought was that a user could essentially have filters that they don't care about the output for any more to release the data from. This would mean that if data was needed again from that filter (e.g. the filter after it wanted to re-execute) though it would have to be constructed from scratch. I think VisIt does this to some extent but when you're going through the data multiple times and requesting different things it will bog down due to all the reconstructing it's doing. I'd think that this would be possible in PV but would require a significant change and would probably be quite confusing to users to enable them to do things efficiently. > > Boonth > > > > On 03/20/2018 08:18 PM, Scott, W Alan wrote: > > Totally, totally agree. Lets go with the programmable filter solution. > > > > *From:* Cory Quammen [mailto:cory.quammen at kitware.com > ] > *Sent:* Tuesday, March 20, 2018 7:27 PM > *To:* Bauer, Andy (External Contacts) > > *Cc:* Scott, W Alan ; > paraview-developers at paraview.org; Patchett, John M. (LANL) > > *Subject:* Re: [Paraview-developers] FW: [EXTERNAL] Re: ParaView | Memory > consumption on Paraview (#18035) > > > > On Tue, Mar 20, 2018 at 8:43 PM, Andy Bauer > wrote: > > Well, I could probably have this done by tomorrow but in the end I leave > the decision on whether we wait on the release for this change to Utkarsh > and Cory. I'm not sure how much of a wrench it would put into their plans. > > > > In my judgement, it's too late to put this in 5.5. It may seem like a > simple change, but experience shows time and again that simple changes do > not exist :-) We do not have sufficient time to test it and get feedback > prior to the release. > > > > On the other hand, if this is really the specific use case then a Python > Programmable Filter could just as easily do the trick and would be nearly > negligible cost. In fact, I'll put together the a python script that does > that and send it out shortly. > > > > Sounds like a good plan. > > > > Thanks, > > Cory > > > > > > On Tue, Mar 20, 2018 at 8:37 PM, Scott, W Alan wrote: > > Andy, > > I assume we are way too late in the release process to implement this for > 5.5.0. > > > > John P., should this be implemented early next release, so you can build > an alpha/ master build? Or will you just wait for 5.6.0, out early fall, > which should make this question irrelevant? > > > > Alan > > > > *From:* Andy Bauer [mailto:andy.bauer at kitware.com] > *Sent:* Tuesday, March 20, 2018 6:35 PM > *To:* Nouanesengsy, Boonthanome (LANL) > *Cc:* Ayachit, Utkarsh (External Contacts) ; > Scott, W Alan ; paraview-developers at paraview.org; > Patchett, John M. (LANL) > *Subject:* Re: [Paraview-developers] FW: [EXTERNAL] Re: ParaView | Memory > consumption on Paraview (#18035) > > > > Going back to the Merge Blocks filter, I'd say that if the input grid is a > vtkUnstructuredGrid and there's only a single block on that process in this > case the Merge Blocks filter should do a shallow copy and exit quickly, > which it doesn't do. This isn't a silver bullet fix and probably won't > matter after the composite dataset rework but for what LANL wants in this > case, this would be a very simple and efficient solution. > > > > On Tue, Mar 20, 2018 at 6:00 PM, Boonthanome Nouanesengsy > wrote: > > Unless I am missing something, no reason. Seems to me that's just the > way it was written. I can't see why the filter can't request 1 extra > ghost-level from its input. (cc, Berk). > > Because we start with cell data, we actually require two layers of ghost > cells. The ghost cells filter was developed to allocate as many layers of > ghost cells as needed for a distributed dataset. > > Any other ideas how to decrease the bloat of about 4 GB of data to be about > 18 GB of data? > Is this for a Catalyst or pvbatch pipeline or for an interactive session? > > It's for an interactive session. We have a user running out of memory > trying to use a certain pipeline. More information is in the issue at > https://gitlab.kitware.com/paraview/paraview/issues/18035 > > Boonth > > > > > On 03/20/2018 03:08 PM, Utkarsh Ayachit wrote: > > Why does merge blocks grow so much? Why can?t this filter just do shallow > copies? Is this impossible, or just not implemented? > > No, merge blocks is not a shallow copy, it needs to combine mutliple > vtkDataSet's into a single vtkDataSet merging all points into a single > array, same for cells, other attribute arrays etc. Merge Blocks should > indeed be considered as a workaround for issue when handling > mutliblock datasets in the pipeline and not the go-to solution. There > is work currently underway that will revamp multiblock dataset support > in VTK/ParaView which should ultimately make Merge Blocks obsolete. > > Looking at your pipeline, looks like you're doing MergeBlocks so that > you can run the Ghost Cells generator filter. What is the nature of > your data? Is it truly a multiblock or just has 1 block in it on each > rank? If its just 1 block, what is the type of the block? If it's a > unstructured grid, it will trivial to create a filter that just passes > the input block out as unstructured grid without duplicating. > > Why can?t Merge Blocks do shallow copies? Is this impossible, or just not > implemented? > > It's impossible. See previous comment for justification based on how > things are currently. > > (I think I know this one, but here it is). Why does the ghost cell > generator bloat memory so much? Can?t you just use shallow copies of the > primary data, and then add the ghost cells? > > adding ghost cell etc, means adding new elements to existing arrays. > since vtk doesn't modify input arrays, when it needs to add new > elements, it has to create a deep-copy and then add new elements to > it. > > Why can?t we have the cell data to point data filter be smart enough to add > ghost cells if necessary for calculations, then throw them away? > > Unless I am missing something, no reason. Seems to me that's just the > way it was written. I can't see why the filter can't request 1 extra > ghost-level from its input. (cc, Berk). > > Any other ideas how to decrease the bloat of about 4 GB of data to be about > 18 GB of data? > > Is this for a Catalyst or pvbatch pipeline or for an interactive session? > > Utkarsh > _______________________________________________ > 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: > https://public.kitware.com/mailman/listinfo/paraview-developers > > > _______________________________________________ > 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: > https://public.kitware.com/mailman/listinfo/paraview-developers > > > > > > > _______________________________________________ > 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: > https://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:https://public.kitware.com/mailman/listinfo/paraview-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.bauer at kitware.com Wed Mar 21 17:49:59 2018 From: andy.bauer at kitware.com (Andy Bauer) Date: Wed, 21 Mar 2018 17:49:59 -0400 Subject: [Paraview-developers] FW: [EXTERNAL] Re: ParaView | Memory consumption on Paraview (#18035) In-Reply-To: References: Message-ID: FYI: there's a merge request for doing the shallow copy in merge blocks for the situation when there's only a single, unstructured grid -- https://gitlab.kitware.com/vtk/vtk/merge_requests/4103. Utkarsh thought that it may be able to make it into 5.5 since it's quite a small change. On Wed, Mar 21, 2018 at 3:15 PM, Andy Bauer wrote: > > > On Wed, Mar 21, 2018 at 3:06 PM, Boonthanome Nouanesengsy > wrote: > >> Boonth or John, would you mind shooting me an email that you got this >> email. I'm worried that a spambot may not let this get through based on the >> attachments. >> >> Yes, got the email. >> >> Going back to the Merge Blocks filter, I'd say that if the input grid is >> a vtkUnstructuredGrid and there's only a single block on that process in >> this case the Merge Blocks filter should do a shallow copy and exit >> quickly, which it doesn't do. This isn't a silver bullet fix and probably >> won't matter after the composite dataset rework but for what LANL wants in >> this case, this would be a very simple and efficient solution. >> >> The problem is that in many use cases the number of processes used for >> writing the data will be different from the number of processes used for >> visualization. In this particular use case it won't help, but thanks for >> the programmable filter. It should be helpful in the future. >> > > If multiple blocks per MPI rank is the case then there's currently no way > around the memory consumption in the merge blocks filter. In the past there > were discussions about "cleaning out a pipeline" where the thought was that > a user could essentially have filters that they don't care about the output > for any more to release the data from. This would mean that if data was > needed again from that filter (e.g. the filter after it wanted to > re-execute) though it would have to be constructed from scratch. I think > VisIt does this to some extent but when you're going through the data > multiple times and requesting different things it will bog down due to all > the reconstructing it's doing. I'd think that this would be possible in PV > but would require a significant change and would probably be quite > confusing to users to enable them to do things efficiently. > > > > >> >> Boonth >> >> >> >> On 03/20/2018 08:18 PM, Scott, W Alan wrote: >> >> Totally, totally agree. Lets go with the programmable filter solution. >> >> >> >> *From:* Cory Quammen [mailto:cory.quammen at kitware.com >> ] >> *Sent:* Tuesday, March 20, 2018 7:27 PM >> *To:* Bauer, Andy (External Contacts) >> >> *Cc:* Scott, W Alan ; >> paraview-developers at paraview.org; Patchett, John M. (LANL) >> >> *Subject:* Re: [Paraview-developers] FW: [EXTERNAL] Re: ParaView | >> Memory consumption on Paraview (#18035) >> >> >> >> On Tue, Mar 20, 2018 at 8:43 PM, Andy Bauer >> wrote: >> >> Well, I could probably have this done by tomorrow but in the end I leave >> the decision on whether we wait on the release for this change to Utkarsh >> and Cory. I'm not sure how much of a wrench it would put into their plans. >> >> >> >> In my judgement, it's too late to put this in 5.5. It may seem like a >> simple change, but experience shows time and again that simple changes do >> not exist :-) We do not have sufficient time to test it and get feedback >> prior to the release. >> >> >> >> On the other hand, if this is really the specific use case then a Python >> Programmable Filter could just as easily do the trick and would be nearly >> negligible cost. In fact, I'll put together the a python script that does >> that and send it out shortly. >> >> >> >> Sounds like a good plan. >> >> >> >> Thanks, >> >> Cory >> >> >> >> >> >> On Tue, Mar 20, 2018 at 8:37 PM, Scott, W Alan >> wrote: >> >> Andy, >> >> I assume we are way too late in the release process to implement this for >> 5.5.0. >> >> >> >> John P., should this be implemented early next release, so you can build >> an alpha/ master build? Or will you just wait for 5.6.0, out early fall, >> which should make this question irrelevant? >> >> >> >> Alan >> >> >> >> *From:* Andy Bauer [mailto:andy.bauer at kitware.com] >> *Sent:* Tuesday, March 20, 2018 6:35 PM >> *To:* Nouanesengsy, Boonthanome (LANL) >> *Cc:* Ayachit, Utkarsh (External Contacts) ; >> Scott, W Alan ; paraview-developers at paraview.org; >> Patchett, John M. (LANL) >> *Subject:* Re: [Paraview-developers] FW: [EXTERNAL] Re: ParaView | >> Memory consumption on Paraview (#18035) >> >> >> >> Going back to the Merge Blocks filter, I'd say that if the input grid is >> a vtkUnstructuredGrid and there's only a single block on that process in >> this case the Merge Blocks filter should do a shallow copy and exit >> quickly, which it doesn't do. This isn't a silver bullet fix and probably >> won't matter after the composite dataset rework but for what LANL wants in >> this case, this would be a very simple and efficient solution. >> >> >> >> On Tue, Mar 20, 2018 at 6:00 PM, Boonthanome Nouanesengsy < >> boonth at lanl.gov> wrote: >> >> Unless I am missing something, no reason. Seems to me that's just the >> way it was written. I can't see why the filter can't request 1 extra >> ghost-level from its input. (cc, Berk). >> >> Because we start with cell data, we actually require two layers of ghost >> cells. The ghost cells filter was developed to allocate as many layers of >> ghost cells as needed for a distributed dataset. >> >> Any other ideas how to decrease the bloat of about 4 GB of data to be >> about >> 18 GB of data? >> Is this for a Catalyst or pvbatch pipeline or for an interactive session? >> >> It's for an interactive session. We have a user running out of memory >> trying to use a certain pipeline. More information is in the issue at >> https://gitlab.kitware.com/paraview/paraview/issues/18035 >> >> Boonth >> >> >> >> >> On 03/20/2018 03:08 PM, Utkarsh Ayachit wrote: >> >> Why does merge blocks grow so much? Why can?t this filter just do shallow >> copies? Is this impossible, or just not implemented? >> >> No, merge blocks is not a shallow copy, it needs to combine mutliple >> vtkDataSet's into a single vtkDataSet merging all points into a single >> array, same for cells, other attribute arrays etc. Merge Blocks should >> indeed be considered as a workaround for issue when handling >> mutliblock datasets in the pipeline and not the go-to solution. There >> is work currently underway that will revamp multiblock dataset support >> in VTK/ParaView which should ultimately make Merge Blocks obsolete. >> >> Looking at your pipeline, looks like you're doing MergeBlocks so that >> you can run the Ghost Cells generator filter. What is the nature of >> your data? Is it truly a multiblock or just has 1 block in it on each >> rank? If its just 1 block, what is the type of the block? If it's a >> unstructured grid, it will trivial to create a filter that just passes >> the input block out as unstructured grid without duplicating. >> >> Why can?t Merge Blocks do shallow copies? Is this impossible, or just not >> implemented? >> >> It's impossible. See previous comment for justification based on how >> things are currently. >> >> (I think I know this one, but here it is). Why does the ghost cell >> generator bloat memory so much? Can?t you just use shallow copies of the >> primary data, and then add the ghost cells? >> >> adding ghost cell etc, means adding new elements to existing arrays. >> since vtk doesn't modify input arrays, when it needs to add new >> elements, it has to create a deep-copy and then add new elements to >> it. >> >> Why can?t we have the cell data to point data filter be smart enough to >> add >> ghost cells if necessary for calculations, then throw them away? >> >> Unless I am missing something, no reason. Seems to me that's just the >> way it was written. I can't see why the filter can't request 1 extra >> ghost-level from its input. (cc, Berk). >> >> Any other ideas how to decrease the bloat of about 4 GB of data to be >> about >> 18 GB of data? >> >> Is this for a Catalyst or pvbatch pipeline or for an interactive session? >> >> Utkarsh >> _______________________________________________ >> 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: >> https://public.kitware.com/mailman/listinfo/paraview-developers >> >> >> _______________________________________________ >> 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: >> https://public.kitware.com/mailman/listinfo/paraview-developers >> >> >> >> >> >> >> _______________________________________________ >> 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: >> https://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:https://public.kitware.com/mailman/listinfo/paraview-developers >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shawn.waldon at kitware.com Thu Mar 22 16:34:26 2018 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Thu, 22 Mar 2018 16:34:26 -0400 Subject: [Paraview-developers] kwrobot unresponsiveness and 'topic is missing checks' errors Message-ID: Hi all, The Gitlab update yesterday caused the robot to no longer get events from gitlab. This is why the robot was nonresponsive from yesterday afternoon until this morning when it was fixed. If your topic was updated during that time, the robot never ran the automatic checks since it didn't get the notification about the update. Before you can merge a topic in this state you need to manually tell the robot to run the checks (Do: check). Shawn -------------- next part -------------- An HTML attachment was scrubbed... URL: From michal.wozniak at caboma.com Sat Mar 24 16:03:47 2018 From: michal.wozniak at caboma.com (Michal Wozniak) Date: Sat, 24 Mar 2018 20:03:47 +0000 Subject: [Paraview-developers] ITK Plugin in paraview - Error Message-ID: Hi, I currently I am trying to build a custom plugin that uses ITK on a Debian machine. During the build I received this error : ItkTest_Plugin.h:49:10: fatal error: 'vtkPVPlugin.h' file not found That same plugin is being built successfully on a window machine. I have joined my plugin CMakeList file to this email. Is there something specific to add in a Linux build? thank you Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: CMakeLists.txt URL: From mathieu.westphal at kitware.com Sun Mar 25 21:52:55 2018 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Mon, 26 Mar 2018 03:52:55 +0200 Subject: [Paraview-developers] ITK Plugin in paraview - Error In-Reply-To: References: Message-ID: Hello Is this plugin part of a bigger cmake project ? In any case, look like your should replace IF (ParaView_SOURCE_DIR) INCLUDE_DIRECTORIES(${VTK_INCLUDE_DIRS}) endif() by find_package(ParaView REQUIRED) include(${PARAVIEW_USE_FILE}) You can find some very good example in paraview/Examples/Plugins/ Best regards, Mathieu Westphal On Sat, Mar 24, 2018 at 9:03 PM, Michal Wozniak wrote: > Hi, > > > I currently I am trying to build a custom plugin that uses ITK on a > Debian machine. > > During the build I received this error : > > ItkTest_Plugin.h:49:10: fatal error: 'vtkPVPlugin.h' file not found > > > That same plugin is being built successfully on a window machine. I have > joined my plugin CMakeList file to this email. Is there something > specific to add in a Linux build? > > > thank you > > Michal > > _______________________________________________ > 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: > https://public.kitware.com/mailman/listinfo/paraview-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From asduifhssauidf at gmail.com Mon Mar 26 12:47:52 2018 From: asduifhssauidf at gmail.com (iusadhfoias sidufasipudf) Date: Mon, 26 Mar 2018 18:47:52 +0200 Subject: [Paraview-developers] information_only property doesn't update, please help In-Reply-To: References: Message-ID: >Cory is certainly busy on lot of other stuff now, especially for the preparation of 5.5 release but he or someone else will answer >you if you have the patience to wait. Dear Joachim and Cory, may I ask if it makes sense to keep my patience up and still hope for a solution, how information_only can be made to properly update? If I can expect an answer within another month, I could plan accordingly. But if this is a problem inherent to Paraview and there is no solution, many many people could benefit if this was clearly stated once and forever. Please let me know if you prefer that I repose my question including example code on the list, because this thread became quite lengthy already. Best regards, Jussuf On Sat, Mar 17, 2018 at 3:32 PM, Joachim Pouderoux < joachim.pouderoux at kitware.com> wrote: > Jussuf, > > This mailing list is not a ParaView hot line: the principle of this "free" > mailing list is that people (from Kitware or not) answer, on their > good will, when they have time to do and there is no obligation to answer > at all. > > Cory is certainly busy on lot of other stuff now, especially for the > preparation of 5.5 release but he or someone else will answer > you if you have the patience to wait. - By the way, Cory never promised to > help you on this issue, he just mentionned the fact > that your forget to attach your example code. > > Note that if you need a reactive support, Kitware can setup a specific > support contract with you. > > Best regards, > Joachim > > *Joachim Pouderoux*, PhD > > *Technical Expert - Scientific Computing Team* > *Kitware SAS * > > > 2018-03-17 10:09 GMT-04:00 iusadhfoias sidufasipudf < > asduifhssauidf at gmail.com>: > >> Hi Cory, >> what is the reason, why you ignore my emails? >> After your reminder I attached a complete example that you can compile >> and run within seconds, and I described the problem in sufficient detail. >> In this list many questions are answered that leave out important details >> again and again. But my question is ignored. What is wrong with my problem >> description? >> >> Jussuf >> >> On Tue, Mar 13, 2018 at 2:42 PM, iusadhfoias sidufasipudf < >> asduifhssauidf at gmail.com> wrote: >> >>> Hi Cory, >>> I feel really, really sorry to bother you again. You were so kind to >>> remind me of the attachment that was missing from my earlier question. Now >>> It's again two weeks without a reply, although I'm sure you can answer my >>> earlier question within a few minutes of your time. Please give me any >>> feedback so that I don't have to wait longer for no reason. If you don't >>> want to look into this issue, please say so. If my emails got lost in the >>> meantime, I can send them again. >>> >>> Many thanks, >>> Jussuf >>> >>> >>> On Thu, Mar 1, 2018 at 10:28 PM, iusadhfoias sidufasipudf < >>> asduifhssauidf at gmail.com> wrote: >>> >>>> I'm sorry, here is the attachment. >>>> >>>> Many thanks, >>>> Jussuf >>>> >>>> On Thu, Mar 1, 2018 at 4:26 AM, Cory Quammen >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> I think you forgot to attach your small example. Could you do so? >>>>> >>>>> Thanks, >>>>> Cory >>>>> >>>>> On Tue, Feb 27, 2018 at 12:43 PM, iusadhfoias sidufasipudf < >>>>> asduifhssauidf at gmail.com> wrote: >>>>> >>>>>> Hello VTK developers, >>>>>> several questions about the correct usage of information_only >>>>>> properties have been asked over the years, but I didn't find a working >>>>>> solution. >>>>>> >>>>>> The attached example is a complete, tiny, source plugin >>>>>> ("MyInfoSource") for paraview 5.4.1. It generates an empty PolyData output. >>>>>> I am only interested in modifying and showing the source's properties. >>>>>> >>>>>> MyInfoSource has 3 properties (cf. InfoSource.xml): >>>>>> 1) InputPoint allows to input three coordinates. >>>>>> 2) CalculatedPoint has 'information_only="1"' and will be calculated >>>>>> whenever InputPoint is set. >>>>>> 3) ShowCalculatedPoint has 'information_property="CalculatedPoint"' >>>>>> and is meant to output that calculated value. >>>>>> >>>>>> I am using a modified vtkInfoSource::SetInputPoint, which sets the >>>>>> CalculatedPoint coordinates to twice the InputPoint coordinates whenever >>>>>> InputPoint changes (cf. vtkInfoSource.cxx). >>>>>> >>>>>> I was expecting the "ShowCalculatedPoint" property to update in the >>>>>> properties view, whenever I apply changes to InputPoint, but it doesn't >>>>>> change. Only when I click "Restore application default setting values" for >>>>>> MyInformationSource, then ShowCalculatedPoint shows twice the last value of >>>>>> InputPoint. >>>>>> >>>>>> Can you reproduce this behaviour? >>>>>> What needs to be changed, so that ShowCalculatedPoint always shows >>>>>> twice the InputPoint coordinates after changes are applied? >>>>>> >>>>>> Many thanks, >>>>>> Jussuf >>>>>> >>>>>> _______________________________________________ >>>>>> 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: >>>>>> https://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: >> https://public.kitware.com/mailman/listinfo/paraview-developers >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.bauer at kitware.com Mon Mar 26 15:25:27 2018 From: andy.bauer at kitware.com (Andy Bauer) Date: Mon, 26 Mar 2018 15:25:27 -0400 Subject: [Paraview-developers] FW: [EXTERNAL] Re: ParaView | Memory consumption on Paraview (#18035) In-Reply-To: References: Message-ID: FYI: This has made it into the PV 5.5 release branch. On Wed, Mar 21, 2018 at 5:49 PM, Andy Bauer wrote: > FYI: there's a merge request for doing the shallow copy in merge blocks > for the situation when there's only a single, unstructured grid -- > https://gitlab.kitware.com/vtk/vtk/merge_requests/4103. Utkarsh thought > that it may be able to make it into 5.5 since it's quite a small change. > > On Wed, Mar 21, 2018 at 3:15 PM, Andy Bauer > wrote: > >> >> >> On Wed, Mar 21, 2018 at 3:06 PM, Boonthanome Nouanesengsy < >> boonth at lanl.gov> wrote: >> >>> Boonth or John, would you mind shooting me an email that you got this >>> email. I'm worried that a spambot may not let this get through based on the >>> attachments. >>> >>> Yes, got the email. >>> >>> Going back to the Merge Blocks filter, I'd say that if the input grid is >>> a vtkUnstructuredGrid and there's only a single block on that process in >>> this case the Merge Blocks filter should do a shallow copy and exit >>> quickly, which it doesn't do. This isn't a silver bullet fix and probably >>> won't matter after the composite dataset rework but for what LANL wants in >>> this case, this would be a very simple and efficient solution. >>> >>> The problem is that in many use cases the number of processes used for >>> writing the data will be different from the number of processes used for >>> visualization. In this particular use case it won't help, but thanks for >>> the programmable filter. It should be helpful in the future. >>> >> >> If multiple blocks per MPI rank is the case then there's currently no way >> around the memory consumption in the merge blocks filter. In the past there >> were discussions about "cleaning out a pipeline" where the thought was that >> a user could essentially have filters that they don't care about the output >> for any more to release the data from. This would mean that if data was >> needed again from that filter (e.g. the filter after it wanted to >> re-execute) though it would have to be constructed from scratch. I think >> VisIt does this to some extent but when you're going through the data >> multiple times and requesting different things it will bog down due to all >> the reconstructing it's doing. I'd think that this would be possible in PV >> but would require a significant change and would probably be quite >> confusing to users to enable them to do things efficiently. >> >> >> >> >>> >>> Boonth >>> >>> >>> >>> On 03/20/2018 08:18 PM, Scott, W Alan wrote: >>> >>> Totally, totally agree. Lets go with the programmable filter solution. >>> >>> >>> >>> *From:* Cory Quammen [mailto:cory.quammen at kitware.com >>> ] >>> *Sent:* Tuesday, March 20, 2018 7:27 PM >>> *To:* Bauer, Andy (External Contacts) >>> >>> *Cc:* Scott, W Alan ; >>> paraview-developers at paraview.org; Patchett, John M. (LANL) >>> >>> *Subject:* Re: [Paraview-developers] FW: [EXTERNAL] Re: ParaView | >>> Memory consumption on Paraview (#18035) >>> >>> >>> >>> On Tue, Mar 20, 2018 at 8:43 PM, Andy Bauer >>> wrote: >>> >>> Well, I could probably have this done by tomorrow but in the end I leave >>> the decision on whether we wait on the release for this change to Utkarsh >>> and Cory. I'm not sure how much of a wrench it would put into their plans. >>> >>> >>> >>> In my judgement, it's too late to put this in 5.5. It may seem like a >>> simple change, but experience shows time and again that simple changes do >>> not exist :-) We do not have sufficient time to test it and get feedback >>> prior to the release. >>> >>> >>> >>> On the other hand, if this is really the specific use case then a Python >>> Programmable Filter could just as easily do the trick and would be nearly >>> negligible cost. In fact, I'll put together the a python script that does >>> that and send it out shortly. >>> >>> >>> >>> Sounds like a good plan. >>> >>> >>> >>> Thanks, >>> >>> Cory >>> >>> >>> >>> >>> >>> On Tue, Mar 20, 2018 at 8:37 PM, Scott, W Alan >>> wrote: >>> >>> Andy, >>> >>> I assume we are way too late in the release process to implement this >>> for 5.5.0. >>> >>> >>> >>> John P., should this be implemented early next release, so you can build >>> an alpha/ master build? Or will you just wait for 5.6.0, out early fall, >>> which should make this question irrelevant? >>> >>> >>> >>> Alan >>> >>> >>> >>> *From:* Andy Bauer [mailto:andy.bauer at kitware.com] >>> *Sent:* Tuesday, March 20, 2018 6:35 PM >>> *To:* Nouanesengsy, Boonthanome (LANL) >>> *Cc:* Ayachit, Utkarsh (External Contacts) ; >>> Scott, W Alan ; paraview-developers at paraview.org; >>> Patchett, John M. (LANL) >>> *Subject:* Re: [Paraview-developers] FW: [EXTERNAL] Re: ParaView | >>> Memory consumption on Paraview (#18035) >>> >>> >>> >>> Going back to the Merge Blocks filter, I'd say that if the input grid is >>> a vtkUnstructuredGrid and there's only a single block on that process in >>> this case the Merge Blocks filter should do a shallow copy and exit >>> quickly, which it doesn't do. This isn't a silver bullet fix and probably >>> won't matter after the composite dataset rework but for what LANL wants in >>> this case, this would be a very simple and efficient solution. >>> >>> >>> >>> On Tue, Mar 20, 2018 at 6:00 PM, Boonthanome Nouanesengsy < >>> boonth at lanl.gov> wrote: >>> >>> Unless I am missing something, no reason. Seems to me that's just the >>> way it was written. I can't see why the filter can't request 1 extra >>> ghost-level from its input. (cc, Berk). >>> >>> Because we start with cell data, we actually require two layers of ghost >>> cells. The ghost cells filter was developed to allocate as many layers of >>> ghost cells as needed for a distributed dataset. >>> >>> Any other ideas how to decrease the bloat of about 4 GB of data to be >>> about >>> 18 GB of data? >>> Is this for a Catalyst or pvbatch pipeline or for an interactive session? >>> >>> It's for an interactive session. We have a user running out of memory >>> trying to use a certain pipeline. More information is in the issue at >>> https://gitlab.kitware.com/paraview/paraview/issues/18035 >>> >>> Boonth >>> >>> >>> >>> >>> On 03/20/2018 03:08 PM, Utkarsh Ayachit wrote: >>> >>> Why does merge blocks grow so much? Why can?t this filter just do >>> shallow >>> copies? Is this impossible, or just not implemented? >>> >>> No, merge blocks is not a shallow copy, it needs to combine mutliple >>> vtkDataSet's into a single vtkDataSet merging all points into a single >>> array, same for cells, other attribute arrays etc. Merge Blocks should >>> indeed be considered as a workaround for issue when handling >>> mutliblock datasets in the pipeline and not the go-to solution. There >>> is work currently underway that will revamp multiblock dataset support >>> in VTK/ParaView which should ultimately make Merge Blocks obsolete. >>> >>> Looking at your pipeline, looks like you're doing MergeBlocks so that >>> you can run the Ghost Cells generator filter. What is the nature of >>> your data? Is it truly a multiblock or just has 1 block in it on each >>> rank? If its just 1 block, what is the type of the block? If it's a >>> unstructured grid, it will trivial to create a filter that just passes >>> the input block out as unstructured grid without duplicating. >>> >>> Why can?t Merge Blocks do shallow copies? Is this impossible, or just >>> not >>> implemented? >>> >>> It's impossible. See previous comment for justification based on how >>> things are currently. >>> >>> (I think I know this one, but here it is). Why does the ghost cell >>> generator bloat memory so much? Can?t you just use shallow copies of the >>> primary data, and then add the ghost cells? >>> >>> adding ghost cell etc, means adding new elements to existing arrays. >>> since vtk doesn't modify input arrays, when it needs to add new >>> elements, it has to create a deep-copy and then add new elements to >>> it. >>> >>> Why can?t we have the cell data to point data filter be smart enough to >>> add >>> ghost cells if necessary for calculations, then throw them away? >>> >>> Unless I am missing something, no reason. Seems to me that's just the >>> way it was written. I can't see why the filter can't request 1 extra >>> ghost-level from its input. (cc, Berk). >>> >>> Any other ideas how to decrease the bloat of about 4 GB of data to be >>> about >>> 18 GB of data? >>> >>> Is this for a Catalyst or pvbatch pipeline or for an interactive session? >>> >>> Utkarsh >>> _______________________________________________ >>> 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: >>> https://public.kitware.com/mailman/listinfo/paraview-developers >>> >>> >>> _______________________________________________ >>> 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: >>> https://public.kitware.com/mailman/listinfo/paraview-developers >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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: >>> https://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:https://public.kitware.com/mailman/listinfo/paraview-developers >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cornelis.bockemuehl at gmail.com Mon Mar 26 17:41:23 2018 From: cornelis.bockemuehl at gmail.com (Cornelis =?ISO-8859-1?Q?Bockem=FChl?=) Date: Mon, 26 Mar 2018 23:41:23 +0200 Subject: [Paraview-developers] state file and int list Message-ID: <1522100483.3250.8.camel@gmail.com> Dear all, For some PV filter (named "WriteValue") I am writing a custom widget (class?pqPropertyGroupWidget). This includes 4 properties: a string, two "double" values and a list of int values. The list of int values I am "attaching" to the widget with this property definition: Q_PROPERTY(QList Ids READ getIds WRITE setIds NOTIFY idsChanged) and then in the code I have getIds, setIds and idsChanged defined and declared properly. Everything works fine and nice so far. Only what I do not see is anything in the "state" file: there my filter is specified as follows: ? ? ?????? ?????? ???????? ???????? ???????? ?????? ?????? ???????? ???????? ?????? ?????? ???????? ?????? ?????? ???????? ???????? ?????? ???? So the "TargetArrayName", the "Value" and the "ReplacementValue" are all fine with their proper values. Only the "Ids" looks like it contains nothing - which is not the case! The specification in the server manager XML looks as follows: ? ? ? ???????? ??????????IDs for which the value should be set ???????? ?????? Is there anything still obviously missing for proper handling of that "Ids" property also in the state file - including the list of values? Or is this simply not a built-in feature, so I need to "dig" even deeper - somehow? Many thanks for any helpful hint! Regards, Cornelis -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Mon Mar 26 21:16:03 2018 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Mon, 26 Mar 2018 21:16:03 -0400 Subject: [Paraview-developers] state file and int list In-Reply-To: <1522100483.3250.8.camel@gmail.com> References: <1522100483.3250.8.camel@gmail.com> Message-ID: I suspect the problem is with the hooking up of the property and the widget. 1. ensure that pqPropertyLinks is setup correctly so that servermanager-property and teh Qt property are linked correct 2. ensure correct signal is fired with the widget is changed by the user 3. add break points in getIds to confirm that it gets called when user changes UI and its returning correct values. Utkarsh On Mon, Mar 26, 2018 at 5:41 PM, Cornelis Bockem?hl < cornelis.bockemuehl at gmail.com> wrote: > Dear all, > > For some PV filter (named "WriteValue") I am writing a custom widget > (class pqPropertyGroupWidget). This includes 4 properties: a string, two > "double" values and a list of int values. The list of int values I am > "attaching" to the widget with this property definition: > > Q_PROPERTY(QList Ids READ getIds WRITE setIds NOTIFY idsChanged) > > and then in the code I have getIds, setIds and idsChanged defined and > declared properly. Everything works fine and nice so far. > > Only what I do not see is anything in the "state" file: there my filter is > specified as follows: > > > > > > > > > number_of_elements="1"> > > > > number_of_elements="1"> > > > > > > > > > So the "TargetArrayName", the "Value" and the "ReplacementValue" are all > fine with their proper values. Only the "Ids" looks like it contains > nothing - which is not the case! > > The specification in the server manager XML looks as follows: > > clean_command="ClearIds" > label="Ids" > name="Ids" > number_of_elements_per_command="1" > repeat_command="1"> > > IDs for which the value should be set > > > > Is there anything still obviously missing for proper handling of that > "Ids" property also in the state file - including the list of values? Or is > this simply not a built-in feature, so I need to "dig" even deeper - > somehow? > > Many thanks for any helpful hint! > > Regards, > Cornelis > > _______________________________________________ > 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: > https://public.kitware.com/mailman/listinfo/paraview-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michal.wozniak at caboma.com Mon Mar 26 21:19:13 2018 From: michal.wozniak at caboma.com (Michal Wozniak) Date: Tue, 27 Mar 2018 01:19:13 +0000 Subject: [Paraview-developers] ITK Plugin in paraview - Error In-Reply-To: References: , Message-ID: Hi, It's a custom plugin built inside ParaView's plugin folder. I moved the "IF (ParaView_SOURCE_DIR) ... include vtk..." part before the find_package ITK and it stops causing the problem. It's now building on Linux! thanks! Michal ________________________________ From: Mathieu Westphal Sent: Sunday, March 25, 2018 9:52 PM To: Michal Wozniak Cc: paraview-developers at paraview.org Subject: Re: [Paraview-developers] ITK Plugin in paraview - Error Hello Is this plugin part of a bigger cmake project ? In any case, look like your should replace IF (ParaView_SOURCE_DIR) INCLUDE_DIRECTORIES(${VTK_INCLUDE_DIRS}) endif() by find_package(ParaView REQUIRED) include(${PARAVIEW_USE_FILE}) You can find some very good example in paraview/Examples/Plugins/ Best regards, Mathieu Westphal On Sat, Mar 24, 2018 at 9:03 PM, Michal Wozniak > wrote: Hi, I currently I am trying to build a custom plugin that uses ITK on a Debian machine. During the build I received this error : ItkTest_Plugin.h:49:10: fatal error: 'vtkPVPlugin.h' file not found That same plugin is being built successfully on a window machine. I have joined my plugin CMakeList file to this email. Is there something specific to add in a Linux build? thank you Michal _______________________________________________ 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: https://public.kitware.com/mailman/listinfo/paraview-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From cornelis.bockemuehl at gmail.com Tue Mar 27 03:50:26 2018 From: cornelis.bockemuehl at gmail.com (Cornelis =?ISO-8859-1?Q?Bockem=FChl?=) Date: Tue, 27 Mar 2018 09:50:26 +0200 Subject: [Paraview-developers] state file and int list In-Reply-To: References: <1522100483.3250.8.camel@gmail.com> Message-ID: <1522137026.3571.2.camel@gmail.com> Thanks: there was something wrong indeed with the property link: now everything is working fine. And again you saved me overnight a lot of time for detours - just by pointing your finger in the right direction! Regards, Cornelis Am Montag, den 26.03.2018, 21:16 -0400 schrieb Utkarsh Ayachit: > > I suspect the problem is with the hooking up of the property and the widget. > > 1. ensure that pqPropertyLinks is setup correctly so that servermanager-property and teh Qt property are linked correct > > 2. ensure correct signal is fired with the widget is changed by the user > > 3. add break points in getIds to confirm that it gets called when user changes UI and its returning correct values. > > > Utkarsh > > > > On Mon, Mar 26, 2018 at 5:41 PM, Cornelis Bockem?hl wrote: > > Dear all, > > > > > > > > > > For some PV filter (named "WriteValue") I am writing a custom widget (class?pqPropertyGroupWidget). This includes 4 properties: a string, two "double" values and a list of int values. The list of int values I am "attaching" to the widget with this property definition: > > > > Q_PROPERTY(QList Ids READ getIds WRITE setIds NOTIFY idsChanged) > > > > > > and then in the code I have getIds, setIds and idsChanged defined and declared properly. Everything works fine and nice so far. > > > > > > Only what I do not see is anything in the "state" file: there my filter is specified as follows: > > > > ? ? > > ?????? > > > > ?????? > > ???????? > > ???????? > > ???????? > > ?????? > > > > ?????? > > ???????? > > ???????? > > ?????? > > > > ?????? > > ???????? > > ?????? > > > > ?????? > > ???????? > > ???????? > > ?????? > > ???? > > > > > > > > So the "TargetArrayName", the "Value" and the "ReplacementValue" are all fine with their proper values. Only the "Ids" looks like it contains nothing - which is not the case! > > > > The specification in the server manager XML looks as follows: > > > > ? ? ? > ?????????????????????????clean_command="ClearIds" > > ?????????????????????????label="Ids" > > ?????????????????????????name="Ids" > > ?????????????????????????number_of_elements_per_command="1" > > ?????????????????????????repeat_command="1"> > > ???????? > > ??????????IDs for which the value should be set > > ???????? > > ?????? > > > > > > > > > > Is there anything still obviously missing for proper handling of that "Ids" property also in the state file - including the list of values? Or is this simply not a built-in feature, so I need to "dig" even deeper - somehow? > > > > Many thanks for any helpful hint! > > > > Regards, > > Cornelis > > > > > > _______________________________________________ > > > > 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: > > > > https://public.kitware.com/mailman/listinfo/paraview-developers > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cory.quammen at kitware.com Wed Mar 28 10:59:32 2018 From: cory.quammen at kitware.com (Cory Quammen) Date: Wed, 28 Mar 2018 10:59:32 -0400 Subject: [Paraview-developers] CGNS reader In-Reply-To: References: Message-ID: Daryl, I've posted a very high-level overview on how to do this in an issue on GitLab: https://gitlab.kitware.com/vtk/vtk/issues/17273 Please post any questions on that issue. Thanks, Cory On Fri, Mar 2, 2018 at 5:10 PM, Daryl L. Bonhaus wrote: > We have a desktop application that uses VTK for visualization, and we need > to deal with CGNS data. We would like to use the CGNS reader in ParaView > rather than develop our own. Does anyone have any pointers for moving > ParaView?s CGNS reader into VTK? > > > > Thanks, > > Daryl Bonhaus > > Director, CFD Software Development > > Concepts NREC > > > Please consider the environment before printing this email. The > information contained in this communication and any attachment(s) and/or > link(s) hereto may contain proprietary and/or confidential information, > which may be privileged or otherwise protected from disclosure, and is > intended only for the sole use of the intended recipient(s). Any > unauthorized review, use, disclosure, or distribution is strictly > prohibited. If you have received this communication in error, please return > it to the sender immediately and delete the original message from your > computer system. If you have any questions concerning this message, please > contact the sender. This email may contain technical data which is > controlled under the International Traffic in Arms Regulations (ITAR Title > 22 U.S.C. Sec 2751 et seq.). Any such data may not be exported to a Foreign > National or Foreign Company (any non-US person or organization as defined > by 8 U. S. C. 1101(a)(20)). The transfer or disclosure of ITAR governed > information without a required export license approved by the United States > Department of State, Directorate of Defense Trade Controls is prohibited > under US Federal law. > > _______________________________________________ > 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: > https://public.kitware.com/mailman/listinfo/paraview-developers > > -- Cory Quammen Staff R&D Engineer Kitware, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.meysonnat at aia.rwth-aachen.de Wed Mar 28 15:15:25 2018 From: p.meysonnat at aia.rwth-aachen.de (Pascal Meysonnat) Date: Wed, 28 Mar 2018 21:15:25 +0200 Subject: [Paraview-developers] DoubleVectorProperty (Slider) range set at run time Message-ID: Dear all, I am currently developing a new plugin for our in-house solver and would like to have a slider to select certain values which are only known at run time. I have seen the property panel configuration for such a case to look similar to: panel_widget="int_range"> I am not fully sure on how to set the range properly at the run time. Let?s for example say i know at run time the range of the slider should be 1?8. How can i set the range properly and how can I set the increment? Is there some small example I can may be have a look at? Thank you very much for your help, Regards, Pascal -- Dr.-Ing. Pascal S. Meysonnat Chair of Fluid Mechanics and Institute of Aerodynamics RWTH Aachen University W?llnerstra?e 5a D-52062 Aachen Germany -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathieu.westphal at kitware.com Wed Mar 28 22:45:59 2018 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Thu, 29 Mar 2018 04:45:59 +0200 Subject: [Paraview-developers] DoubleVectorProperty (Slider) range set at run time In-Reply-To: References: Message-ID: Hello Pascal, First, i would suggest identifying a widget in ParaView that behave the way you would like your widget to behave, then take a look into this widget XML for inspiration. There may be a way to do what you want to do, but you will need to precise, where do these "at run-time min and max" values come from ? Also what do you mean by increment ? There is no such concept of increment in ParaView slider based widgets. Best regards, Mathieu Westphal On Wed, Mar 28, 2018 at 9:15 PM, Pascal Meysonnat wrote: > Dear all, > > I am currently developing a new plugin for our in-house solver and would > like to have a slider to select certain values which are only known at run > time. I have seen the property panel configuration for such a case to look > similar to: > > Name="Values" > command="SetValues" > number_of_elements="1" > default_values="1"> > panel_widget="int_range"> > > > name="Input" /> > > > > > I am not fully sure on how to set the range properly at the run time. > Let?s for example say i know at run time the range of the slider should be > 1?8. How can i set the range properly and how can I set the increment? Is > there some small example I can may be have a look at? > > Thank you very much for your help, > > Regards, > > Pascal > > -- > Dr.-Ing. Pascal S. Meysonnat > > Chair of Fluid Mechanics and Institute of Aerodynamics > RWTH Aachen University > W?llnerstra?e 5a > D-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: > https://public.kitware.com/mailman/listinfo/paraview-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.meysonnat at aia.rwth-aachen.de Thu Mar 29 11:03:25 2018 From: p.meysonnat at aia.rwth-aachen.de (Pascal S. Meysonnat) Date: Thu, 29 Mar 2018 17:03:25 +0200 Subject: [Paraview-developers] DoubleVectorProperty (Slider) range set at run time In-Reply-To: References: Message-ID: <33542d6c-0045-d502-b3ef-eeeaad57a29a@aia.rwth-aachen.de> On 03/29/2018 04:45 AM, Mathieu Westphal wrote: > Hello Pascal, > > First, i would suggest identifying a widget in ParaView that behave > the way you would like your widget to behave, then take a look into > this widget XML for inspiration. > > There may be a way to do what you want to do, but you will need to > precise, where do these "at run-time min and max" values come from ? > > Also what do you mean by increment ? There is no such concept of > increment in ParaView slider based widgets. > > Best regards, > > Mathieu Westphal > > On Wed, Mar 28, 2018 at 9:15 PM, Pascal Meysonnat > > wrote: > > Dear all,? > > I am currently developing a new plugin for our in-house solver and > would like to have a slider to select certain values which are > only known at run time. I have seen the property panel > configuration for such a case to look similar to: > > ? ? ? ? ? ?Name="Values" > ? ? ? ? ?command="SetValues" > ? ? ? ? ?number_of_elements="1" > ? ? ? ? ?default_values="1"> > ? ? ? ? ?panel_widget="int_range"> > ? ? ? ? > ? ? ? ? ? > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?name="Input" /> > ? ? ? ? ? > ? ? ? ? > ? ? ? > > I am not fully sure on how to set the range properly at the run > time. Let?s for example say i know at run time the range of the > slider should be 1?8. How can i set the range properly and how can > I set the increment? Is there some small example I can may be have > a look at? > > Thank you very much for your help,? > > Regards,? > > Pascal? > > -- > Dr.-Ing. Pascal S. Meysonnat > > Chair of Fluid Mechanics and Institute of Aerodynamics > RWTH Aachen University > W?llnerstra?e 5a > D-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: > https://public.kitware.com/mailman/listinfo/paraview-developers > > > Dear Mathieu, I finally managed to get it work in the end, except for one special question which remains open. Here is the solution. In the xml file I hat to use the function RangeInfo (see below): ? ?????? ????? ???? ?????? ????????? ????????????? ????????? ??????? ???? and in the *.h file of the reader, the Macro had to be set vtkGetVector2Macro(LevelRange, int); as well as? int LevelRange[2]; Finished! Now I can read the values into LevelRange from the RequestInformation and the sliders appear correctly. There is just one final thing which is missing. I have integer values and I would like the sliders to be rather of an integer type than being of double type, i.e., i would like them do change in full integer values? Is there a way to achieve this? Best Regards Pascal Meysonnat -------------- next part -------------- An HTML attachment was scrubbed... URL: From cory.quammen at kitware.com Thu Mar 29 14:01:49 2018 From: cory.quammen at kitware.com (Cory Quammen) Date: Thu, 29 Mar 2018 14:01:49 -0400 Subject: [Paraview-developers] ParaView 5.5.0-RC4 tagged, binaries available Message-ID: Dear ParaView community, I am pleased to announce that ParaView 5.5.0-RC4 has been tagged (tag "v5.5.0-RC4"). Binaries are also available on the ParaView downloads web page https://www.paraview.org/download/. If your browser doesn't show the 5.5.0-RC4 downloads, you may just need to "hard refresh" the page. On Chrome and Firefox, hold down Shift while pressing Ctrl-R (or Cmd-R on macOS). Please let us know if you encounter any issues with this release candidate. ParaView's superbuild has also been tagged with "v5.5.0-RC4". Thank you, Cory -- Cory Quammen Staff R&D Engineer Kitware, Inc. From wascott at sandia.gov Thu Mar 29 20:41:59 2018 From: wascott at sandia.gov (Scott, W Alan) Date: Fri, 30 Mar 2018 00:41:59 +0000 Subject: [Paraview-developers] NVIDIA Index plugin Message-ID: Hi team, I have a user asking about an NVIDIA Index plugin for ParaView. Any idea what he is talking about? Thanks, Alan -------------------------------------------------------- W. Alan Scott ParaView Support Manager SAIC Sandia National Laboratories, MS 0807 Org 9326 - Building 880 A1-K (505) 284-0932 FAX (505) 284-5619 "When the facts change, I change my mind. What do you do, sir?" John Maynard Keynes --------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Thu Mar 29 20:43:05 2018 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Thu, 29 Mar 2018 20:43:05 -0400 Subject: [Paraview-developers] NVIDIA Index plugin In-Reply-To: References: Message-ID: He's referring to this: https://blog.kitware.com/nvidia-index-plugin-in-paraview-5-5/ Utkarsh On Thu, Mar 29, 2018 at 8:41 PM, Scott, W Alan wrote: > Hi team, > > I have a user asking about an NVIDIA Index plugin for ParaView. Any idea > what he is talking about? > > > > Thanks, > > > > Alan > > > > -------------------------------------------------------- > > W. Alan Scott > > ParaView Support Manager > > > > SAIC > > Sandia National Laboratories, MS 0807 > > Org 9326 - Building 880 A1-K > > (505) 284-0932 FAX (505) 284-5619 > > > > ?When the facts change, I change my mind. What do you do, sir?? > > John Maynard Keynes > > > > --------------------------------------------------------- > > > > > _______________________________________________ > 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: > https://public.kitware.com/mailman/listinfo/paraview-developers > From wascott at sandia.gov Thu Mar 29 21:02:44 2018 From: wascott at sandia.gov (Scott, W Alan) Date: Fri, 30 Mar 2018 01:02:44 +0000 Subject: [Paraview-developers] [EXTERNAL] Re: NVIDIA Index plugin In-Reply-To: References: Message-ID: <1361ca00af20411986041f1d96c1e80e@ES01AMSNLNT.srn.sandia.gov> Amazing timing. We now have an NVIDIA enabled cluster. So, this is the only way to turn GPUs on on a cluster? Also, there is a licensing fee? Or, should I build using EGL, as per https://www.paraview.org/ParaView/Doc/Nightly/www/cxx-doc/Offscreen.html? Or, am I being stupid - and ParaView, built on a cluster with GPU's will just work after I compile for the cluster? Thanks, Alan > -----Original Message----- > From: Utkarsh Ayachit [mailto:utkarsh.ayachit at kitware.com] > Sent: Thursday, March 29, 2018 6:43 PM > To: Scott, W Alan > Cc: paraview-developers at paraview.org > Subject: [EXTERNAL] Re: [Paraview-developers] NVIDIA Index plugin > > He's referring to this: > https://blog.kitware.com/nvidia-index-plugin-in-paraview-5-5/ > > Utkarsh > > On Thu, Mar 29, 2018 at 8:41 PM, Scott, W Alan wrote: > > Hi team, > > > > I have a user asking about an NVIDIA Index plugin for ParaView. Any > > idea what he is talking about? > > > > > > > > Thanks, > > > > > > > > Alan > > > > > > > > -------------------------------------------------------- > > > > W. Alan Scott > > > > ParaView Support Manager > > > > > > > > SAIC > > > > Sandia National Laboratories, MS 0807 > > > > Org 9326 - Building 880 A1-K > > > > (505) 284-0932 FAX (505) 284-5619 > > > > > > > > ?When the facts change, I change my mind. What do you do, sir?? > > > > John Maynard Keynes > > > > > > > > --------------------------------------------------------- > > > > > > > > > > _______________________________________________ > > 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: > > https://public.kitware.com/mailman/listinfo/paraview-developers > > From utkarsh.ayachit at kitware.com Thu Mar 29 21:18:09 2018 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Thu, 29 Mar 2018 21:18:09 -0400 Subject: [Paraview-developers] [EXTERNAL] Re: NVIDIA Index plugin In-Reply-To: <1361ca00af20411986041f1d96c1e80e@ES01AMSNLNT.srn.sandia.gov> References: <1361ca00af20411986041f1d96c1e80e@ES01AMSNLNT.srn.sandia.gov> Message-ID: NVIDIA IndeX? is a commercial 3D volumetric visualization SDK. It's another way for using GPUs for volume rendering. Other existing VTK volume mappers like the Hardware Accelerated Volume Mapper also uses GPUs for volume rendering, but a different implementation. To simply use GPUs on your cluster, building with EGL indeed would be the way to go (instead of OS Mesa, for example). Then when you use the hardware accelerated volume mapper (which is default for image data), you'll indeed use GPUs. IndeX has a license fee for cluster use. I can get you in touch with the folks I work with form NVidia if you'd like. They should be able to elaborate more on the licensing options etc. Utkarsh On Thu, Mar 29, 2018 at 9:02 PM, Scott, W Alan wrote: > Amazing timing. We now have an NVIDIA enabled cluster. So, this is the only way to turn GPUs on on a cluster? Also, there is a licensing fee? Or, should I build using EGL, as per https://www.paraview.org/ParaView/Doc/Nightly/www/cxx-doc/Offscreen.html? > > Or, am I being stupid - and ParaView, built on a cluster with GPU's will just work after I compile for the cluster? > > Thanks, > > Alan > >> -----Original Message----- >> From: Utkarsh Ayachit [mailto:utkarsh.ayachit at kitware.com] >> Sent: Thursday, March 29, 2018 6:43 PM >> To: Scott, W Alan >> Cc: paraview-developers at paraview.org >> Subject: [EXTERNAL] Re: [Paraview-developers] NVIDIA Index plugin >> >> He's referring to this: >> https://blog.kitware.com/nvidia-index-plugin-in-paraview-5-5/ >> >> Utkarsh >> >> On Thu, Mar 29, 2018 at 8:41 PM, Scott, W Alan wrote: >> > Hi team, >> > >> > I have a user asking about an NVIDIA Index plugin for ParaView. Any >> > idea what he is talking about? >> > >> > >> > >> > Thanks, >> > >> > >> > >> > Alan >> > >> > >> > >> > -------------------------------------------------------- >> > >> > W. Alan Scott >> > >> > ParaView Support Manager >> > >> > >> > >> > SAIC >> > >> > Sandia National Laboratories, MS 0807 >> > >> > Org 9326 - Building 880 A1-K >> > >> > (505) 284-0932 FAX (505) 284-5619 >> > >> > >> > >> > ?When the facts change, I change my mind. What do you do, sir?? >> > >> > John Maynard Keynes >> > >> > >> > >> > --------------------------------------------------------- >> > >> > >> > >> > >> > _______________________________________________ >> > 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: >> > https://public.kitware.com/mailman/listinfo/paraview-developers >> > From wascott at sandia.gov Thu Mar 29 21:36:50 2018 From: wascott at sandia.gov (Scott, W Alan) Date: Fri, 30 Mar 2018 01:36:50 +0000 Subject: [Paraview-developers] [EXTERNAL] Re: NVIDIA Index plugin In-Reply-To: References: <1361ca00af20411986041f1d96c1e80e@ES01AMSNLNT.srn.sandia.gov> Message-ID: <585f9473c3b746f58b459c9d34ee072a@ES01AMSNLNT.srn.sandia.gov> I believe at this point we need EGL. I will let you know if that changes. Thanks, Alan > -----Original Message----- > From: Utkarsh Ayachit [mailto:utkarsh.ayachit at kitware.com] > Sent: Thursday, March 29, 2018 7:18 PM > To: Scott, W Alan > Cc: paraview-developers at paraview.org; Karelitz, David B > > Subject: Re: [EXTERNAL] Re: [Paraview-developers] NVIDIA Index plugin > > NVIDIA IndeX? is a commercial 3D volumetric visualization SDK. It's another > way for using GPUs for volume rendering. Other existing VTK volume mappers > like the Hardware Accelerated Volume Mapper also uses GPUs for volume > rendering, but a different implementation. > > To simply use GPUs on your cluster, building with EGL indeed would be the way > to go (instead of OS Mesa, for example). Then when you use the hardware > accelerated volume mapper (which is default for image data), you'll indeed use > GPUs. > > IndeX has a license fee for cluster use. I can get you in touch with the folks I > work with form NVidia if you'd like. They should be able to elaborate more on > the licensing options etc. > > Utkarsh > > On Thu, Mar 29, 2018 at 9:02 PM, Scott, W Alan wrote: > > Amazing timing. We now have an NVIDIA enabled cluster. So, this is the only > way to turn GPUs on on a cluster? Also, there is a licensing fee? Or, should I > build using EGL, as per > https://www.paraview.org/ParaView/Doc/Nightly/www/cxx- > doc/Offscreen.html? > > > > Or, am I being stupid - and ParaView, built on a cluster with GPU's will just > work after I compile for the cluster? > > > > Thanks, > > > > Alan > > > >> -----Original Message----- > >> From: Utkarsh Ayachit [mailto:utkarsh.ayachit at kitware.com] > >> Sent: Thursday, March 29, 2018 6:43 PM > >> To: Scott, W Alan > >> Cc: paraview-developers at paraview.org > >> Subject: [EXTERNAL] Re: [Paraview-developers] NVIDIA Index plugin > >> > >> He's referring to this: > >> https://blog.kitware.com/nvidia-index-plugin-in-paraview-5-5/ > >> > >> Utkarsh > >> > >> On Thu, Mar 29, 2018 at 8:41 PM, Scott, W Alan > wrote: > >> > Hi team, > >> > > >> > I have a user asking about an NVIDIA Index plugin for ParaView. > >> > Any idea what he is talking about? > >> > > >> > > >> > > >> > Thanks, > >> > > >> > > >> > > >> > Alan > >> > > >> > > >> > > >> > -------------------------------------------------------- > >> > > >> > W. Alan Scott > >> > > >> > ParaView Support Manager > >> > > >> > > >> > > >> > SAIC > >> > > >> > Sandia National Laboratories, MS 0807 > >> > > >> > Org 9326 - Building 880 A1-K > >> > > >> > (505) 284-0932 FAX (505) 284-5619 > >> > > >> > > >> > > >> > ?When the facts change, I change my mind. What do you do, sir?? > >> > > >> > John Maynard Keynes > >> > > >> > > >> > > >> > --------------------------------------------------------- > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > 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: > >> > https://public.kitware.com/mailman/listinfo/paraview-developers > >> > From haocheng.liu at kitware.com Thu Mar 29 21:40:18 2018 From: haocheng.liu at kitware.com (Haocheng Liu) Date: Thu, 29 Mar 2018 21:40:18 -0400 Subject: [Paraview-developers] [EXTERNAL] Re: NVIDIA Index plugin In-Reply-To: References: <1361ca00af20411986041f1d96c1e80e@ES01AMSNLNT.srn.sandia.gov> Message-ID: FYI, If I remember it correctly It's also the best HPC visualization Product of Technology of SC 2017. On Thu, Mar 29, 2018 at 9:18 PM, Utkarsh Ayachit < utkarsh.ayachit at kitware.com> wrote: > NVIDIA IndeX? is a commercial 3D volumetric visualization SDK. It's > another way for using GPUs for volume rendering. Other existing VTK > volume mappers like the Hardware Accelerated Volume Mapper also uses > GPUs for volume rendering, but a different implementation. > > To simply use GPUs on your cluster, building with EGL indeed would be > the way to go (instead of OS Mesa, for example). Then when you use the > hardware accelerated volume mapper (which is default for image data), > you'll indeed use GPUs. > > IndeX has a license fee for cluster use. I can get you in touch with > the folks I work with form NVidia if you'd like. They should be able > to elaborate more on the licensing options etc. > > Utkarsh > > On Thu, Mar 29, 2018 at 9:02 PM, Scott, W Alan wrote: > > Amazing timing. We now have an NVIDIA enabled cluster. So, this is the > only way to turn GPUs on on a cluster? Also, there is a licensing fee? > Or, should I build using EGL, as per https://www.paraview.org/ > ParaView/Doc/Nightly/www/cxx-doc/Offscreen.html? > > > > Or, am I being stupid - and ParaView, built on a cluster with GPU's will > just work after I compile for the cluster? > > > > Thanks, > > > > Alan > > > >> -----Original Message----- > >> From: Utkarsh Ayachit [mailto:utkarsh.ayachit at kitware.com] > >> Sent: Thursday, March 29, 2018 6:43 PM > >> To: Scott, W Alan > >> Cc: paraview-developers at paraview.org > >> Subject: [EXTERNAL] Re: [Paraview-developers] NVIDIA Index plugin > >> > >> He's referring to this: > >> https://blog.kitware.com/nvidia-index-plugin-in-paraview-5-5/ > >> > >> Utkarsh > >> > >> On Thu, Mar 29, 2018 at 8:41 PM, Scott, W Alan > wrote: > >> > Hi team, > >> > > >> > I have a user asking about an NVIDIA Index plugin for ParaView. Any > >> > idea what he is talking about? > >> > > >> > > >> > > >> > Thanks, > >> > > >> > > >> > > >> > Alan > >> > > >> > > >> > > >> > -------------------------------------------------------- > >> > > >> > W. Alan Scott > >> > > >> > ParaView Support Manager > >> > > >> > > >> > > >> > SAIC > >> > > >> > Sandia National Laboratories, MS 0807 > >> > > >> > Org 9326 - Building 880 A1-K > >> > > >> > (505) 284-0932 FAX (505) 284-5619 > >> > > >> > > >> > > >> > ?When the facts change, I change my mind. What do you do, sir?? > >> > > >> > John Maynard Keynes > >> > > >> > > >> > > >> > --------------------------------------------------------- > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > 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: > >> > https://public.kitware.com/mailman/listinfo/paraview-developers > >> > > _______________________________________________ > 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: > https://public.kitware.com/mailman/listinfo/paraview-developers > -- Best regards Haocheng Haocheng LIU Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4421 <(518)%20881-4421> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathieu.westphal at kitware.com Thu Mar 29 22:33:43 2018 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Fri, 30 Mar 2018 04:33:43 +0200 Subject: [Paraview-developers] DoubleVectorProperty (Slider) range set at run time In-Reply-To: <33542d6c-0045-d502-b3ef-eeeaad57a29a@aia.rwth-aachen.de> References: <33542d6c-0045-d502-b3ef-eeeaad57a29a@aia.rwth-aachen.de> Message-ID: Hi Pascal Nice work, thanks for sharing. There is no "pqIntSliderWidget" in ParaView yet, so no, it is not possible. MRs are welcome, so if you want to contribute, please head to https://gitlab.kitware.com/paraview/paraview/ It would also be possible to implement it in a plugin. best, Mathieu Westphal On Thu, Mar 29, 2018 at 5:03 PM, Pascal S. Meysonnat < p.meysonnat at aia.rwth-aachen.de> wrote: > On 03/29/2018 04:45 AM, Mathieu Westphal wrote: > > Hello Pascal, > > First, i would suggest identifying a widget in ParaView that behave the > way you would like your widget to behave, then take a look into this widget > XML for inspiration. > > There may be a way to do what you want to do, but you will need to > precise, where do these "at run-time min and max" values come from ? > > Also what do you mean by increment ? There is no such concept of increment > in ParaView slider based widgets. > > Best regards, > > Mathieu Westphal > > On Wed, Mar 28, 2018 at 9:15 PM, Pascal Meysonnat aachen.de> wrote: > >> Dear all, >> >> I am currently developing a new plugin for our in-house solver and would >> like to have a slider to select certain values which are only known at run >> time. I have seen the property panel configuration for such a case to look >> similar to: >> >> > Name="Values" >> command="SetValues" >> number_of_elements="1" >> default_values="1"> >> panel_widget="int_range"> >> >> >> > name="Input" /> >> >> >> >> >> I am not fully sure on how to set the range properly at the run time. >> Let?s for example say i know at run time the range of the slider should be >> 1?8. How can i set the range properly and how can I set the increment? Is >> there some small example I can may be have a look at? >> >> Thank you very much for your help, >> >> Regards, >> >> Pascal >> >> -- >> Dr.-Ing. Pascal S. Meysonnat >> >> Chair of Fluid Mechanics and Institute of Aerodynamics >> RWTH Aachen University >> W?llnerstra?e 5a >> >> D-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: >> https://public.kitware.com/mailman/listinfo/paraview-developers >> >> > Dear Mathieu, > > I finally managed to get it work in the end, except for one special > question which remains open. Here is the solution. > > In the xml file I hat to use the function RangeInfo (see below): > > command="GetLevelRange" > information_only="1" > number_of_elements="2" > default_values="-1 -10"> > > > > name="MaxLevelToShow" > command="SetMaxLevelToShow" > information_property="LevelRange" > number_of_elements="2" > animateable="1" > default_values="0 0" > panel_widget="double_range"> > > > > > > > > and in the *.h file of the reader, the Macro had to be set > > vtkGetVector2Macro(LevelRange, int); > > as well as > > int LevelRange[2]; > > Finished! Now I can read the values into LevelRange from the > RequestInformation and the sliders appear correctly. There is just one > final thing which is missing. I have integer values and I would like the > sliders to be rather of an integer type than being of double type, i.e., i > would like them do change in full integer values? Is there a way to achieve > this? > > Best Regards > > Pascal Meysonnat > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: