ParaView issueshttps://gitlab.kitware.com/paraview/paraview/-/issues2021-11-15T19:16:40-05:00https://gitlab.kitware.com/paraview/paraview/-/issues/20962Show All Blocks missing on right click menus2021-11-15T19:16:40-05:00W. Alan ScottShow All Blocks missing on right click menusShow All Blocks is now missing on all right click menus. Show All Blocks is needed in case a user hides all of the blocks. Here is how to replicate.
* Nightly (9-14-2021), MacOS, builtin server
* can.exo. Apply.
* Right click on the b...Show All Blocks is now missing on all right click menus. Show All Blocks is needed in case a user hides all of the blocks. Here is how to replicate.
* Nightly (9-14-2021), MacOS, builtin server
* can.exo. Apply.
* Right click on the background of the renderview (i.e., not the can).
We should have a Show All Blocks option. This is a bug.5.10 (Fall 2021)Yohann Bearzi (Kitware)Yohann Bearzi (Kitware)https://gitlab.kitware.com/paraview/paraview/-/issues/20961Hide block only hides one block2021-11-15T19:18:07-05:00W. Alan ScottHide block only hides one blockHide block only hides one block. This is both a bug, and a degradation from what we had. Here is how to replicate:
* Nightly (9-14-2021), MacOS, builtin server.
* Open bake.e. Apply.
* Right click a face. Hide Block.
* Right click a...Hide block only hides one block. This is both a bug, and a degradation from what we had. Here is how to replicate:
* Nightly (9-14-2021), MacOS, builtin server.
* Open bake.e. Apply.
* Right click a face. Hide Block.
* Right click a face. Hide Block.
The first block has appeared again! This is a bug.5.10 (Fall 2021)Yohann Bearzi (Kitware)Yohann Bearzi (Kitware)https://gitlab.kitware.com/paraview/paraview/-/issues/20934IOSS reader not reading CGNS files correctly2021-09-08T22:01:52-04:00W. Alan ScottIOSS reader not reading CGNS files correctlyThe IOSS reader is not reading CGNS files correctly. Here is how to replicate both the problem and a comparison. Note that I could be missing something...
* Master (v5.9.1-1680-g24a9c4f88b), Linux, remote server (16 ranks).
* Load HiF...The IOSS reader is not reading CGNS files correctly. Here is how to replicate both the problem and a comparison. Note that I could be missing something...
* Master (v5.9.1-1680-g24a9c4f88b), Linux, remote server (16 ranks).
* Load HiFiRE dataset, sparc-volume.cgns.144.*. IOSS reader. Apply.
Note that blocks 1, 2, 3 and 6 are turned on. Sets are not.
* Split screen horizontal.
* Load HiFiRE dataset, sparc-volume.cgns.144.*. CGNS Series reader. Apply.
Note that we only see "base". It is turned on. Families are also turned on, with similar names to Sets.
* Turn off Families. We want apples to apples. Apply.
* Link cameras.
Issues:
* The two views are different. The CGNS Series reader has a full airflow around the cone (not shown), where the IOSS reader only shows the lower portion.
* Names are different, and confusing. I assume this is required as we are using the IOSS library for Exodus and CGNS? Example - Family vs Sets. Base vs blocks.
* Turn off Blocks and Base. Turn on Family and Set "In". The IOSS reader reads the set, the CGNS Series Reader doesn't. What should it look like?
Attached is an image of issues.
![Screen_Shot_2021-09-03_at_4.08.26_PM](/uploads/66353d26553d03d50c0a6e701fa92421/Screen_Shot_2021-09-03_at_4.08.26_PM.png)
@utkarsh.ayachit5.10 (Fall 2021)Utkarsh AyachitUtkarsh Ayachithttps://gitlab.kitware.com/paraview/paraview/-/issues/20933vtkTextureObject errors2023-09-08T04:01:36-04:00W. Alan ScottvtkTextureObject errorsI'm seeing errors when drawing the HiRiSE dataset.
Simple to replicate. Master (v5.9.1-1680-g24a9c4f88b), Linux, remote server (16 ranks). Open HiRiSE cgns dataset, using IOSS reader. I may have needed to turn sets on to see it, bu...I'm seeing errors when drawing the HiRiSE dataset.
Simple to replicate. Master (v5.9.1-1680-g24a9c4f88b), Linux, remote server (16 ranks). Open HiRiSE cgns dataset, using IOSS reader. I may have needed to turn sets on to see it, but now it happens no matter what.
The warning is as follows:
```
ERROR: In /projects/viz/paraview/src/stamps/master_paraview_infrastructure/vmaster/paraview_source/VTK/Rendering/OpenGL2/vtkTextureObject.cxx, line 1025
vtkTextureObject (0xe230200): Attempt to use a texture buffer exceeding your hardware's limits. This can happen when trying to color by cell data with a large dataset. Hardware limit is 65536 values while 110464 was requested.
```
From the server side:
```
( 401.358s) [pvserver.3 ] vtkTextureObject.cxx:1025 ERR| vtkTextureObject (0xea325d0): Attempt to use a texture buffer exceeding your hardware's limits. This can happen when trying to color by cell data with a large dataset. Hardware limit is 65536 values while 81728 was requested.
( 401.358s) [pvserver.5 ] vtkTextureObject.cxx:1025 ERR| vtkTextureObject (0xe07bb10): Attempt to use a texture buffer exceeding your hardware's limits. This can happen when trying to color by cell data with a large dataset. Hardware limit is 65536 values while 78464 was requested.
```
Repeat.5.10 (Fall 2021)Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/paraview/paraview/-/issues/20932Crash on temporal interpolator2021-09-08T21:37:24-04:00Eloise BCrash on temporal interpolatorHello,
I was trying to follow the paraview tutorial, particullarly on the time and animation part, and paraview stop with the temporal interpolator filter.
I open the asked database (can.ex2), load all fields and applied. Then i create...Hello,
I was trying to follow the paraview tutorial, particullarly on the time and animation part, and paraview stop with the temporal interpolator filter.
I open the asked database (can.ex2), load all fields and applied. Then i create a Temporal Interpolator and hit "apply". Paraview crash directly with this log errors:
```
Mesa warning: Window 62914569 has no colormap!
Mesa warning: Window 62914572 has no colormap!
Mesa warning: Window 62914582 has no colormap!
( 25.789s) [paraview ]vtkMultiBlockDataSet.cx:78 ERR| vtkMultiBlockDataSet (0xa1ddcb0): vtkPartitionedDataSetCollection cannot be added as a block.
( 25.806s) [paraview ] vtkDataObject.cxx:498 WARN| vtkPartitionedDataSetCollection (0x7a9a4b0): Attempted to ShallowCopy from null.
Loguru caught a signal: SIGSEGV
Stack trace:
58 0x40b8da paraview() [0x40b8da]
57 0x7f1281bc1bf7 __libc_start_main + 231
56 0x40b705 paraview() [0x40b705]
55 0x7f127f01db2c QCoreApplication::exec() + 124
54 0x7f127f015dc3 QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 275
53 0x7f127f06f41d QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 109
52 0x7f126313b00f g_main_context_iteration + 47
51 0x7f126313af80 /home/billae/develop/spackinstaller/spack/opt/spack/linux-ubuntu18.04-skylake/gcc-9.3.0/glib-2.68.3-ftqrdd26x3a3efke73vrjztadihaidjl/lib/libglib-2.0.so.0(+0x5bf80) [0x7f126313af80]
50 0x7f126313ad17 g_main_context_dispatch + 599
49 0x7f125b1f4f2a /home/billae/develop/spackinstaller/spack/opt/spack/linux-ubuntu18.04-skylake/gcc-9.3.0/qt-5.15.2-5xitr7lkdgaeebnku5kkaabra6f4zv32/plugins/platforms/../../lib/libQt5XcbQpa.so.5(+0x62f2a) [0x7f125b1f4f2a]
48 0x7f127f61948b QWindowSystemInterface::sendWindowSystemEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 171
47 0x7f127f63ec69 QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) + 569
46 0x7f127f63d74b QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*) + 1691
45 0x7f127f017050 QCoreApplication::notifyInternal2(QObject*, QEvent*) + 272
44 0x7f1280fb2c00 QApplication::notify(QObject*, QEvent*) + 400
43 0x7f1280faa46f QApplicationPrivate::notify_helper(QObject*, QEvent*) + 127
42 0x7f1281006eac /home/billae/develop/spackinstaller/spack/opt/spack/linux-ubuntu18.04-skylake/gcc-9.3.0/qt-5.15.2-5xitr7lkdgaeebnku5kkaabra6f4zv32/lib/libQt5Widgets.so.5(+0x1d0eac) [0x7f1281006eac]
41 0x7f1281003e88 /home/billae/develop/spackinstaller/spack/opt/spack/linux-ubuntu18.04-skylake/gcc-9.3.0/qt-5.15.2-5xitr7lkdgaeebnku5kkaabra6f4zv32/lib/libQt5Widgets.so.5(+0x1cde88) [0x7f1281003e88]
40 0x7f1280fb20e1 QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&, bool, bool) + 433
39 0x7f127f017050 QCoreApplication::notifyInternal2(QObject*, QEvent*) + 272
38 0x7f1280fb2dd0 QApplication::notify(QObject*, QEvent*) + 864
37 0x7f1280faa46f QApplicationPrivate::notify_helper(QObject*, QEvent*) + 127
36 0x7f1280fe9f18 QWidget::event(QEvent*) + 584
35 0x7f128109aa43 QAbstractButton::mouseReleaseEvent(QMouseEvent*) + 195
34 0x7f128109a89f /home/billae/develop/spackinstaller/spack/opt/spack/linux-ubuntu18.04-skylake/gcc-9.3.0/qt-5.15.2-5xitr7lkdgaeebnku5kkaabra6f4zv32/lib/libQt5Widgets.so.5(+0x26489f) [0x7f128109a89f]
33 0x7f128109956a /home/billae/develop/spackinstaller/spack/opt/spack/linux-ubuntu18.04-skylake/gcc-9.3.0/qt-5.15.2-5xitr7lkdgaeebnku5kkaabra6f4zv32/lib/libQt5Widgets.so.5(+0x26356a) [0x7f128109956a]
32 0x7f1281099382 QAbstractButton::clicked(bool) + 50
31 0x7f127f04ba05 /home/billae/develop/spackinstaller/spack/opt/spack/linux-ubuntu18.04-skylake/gcc-9.3.0/qt-5.15.2-5xitr7lkdgaeebnku5kkaabra6f4zv32/lib/libQt5Core.so.5(+0x2dea05) [0x7f127f04ba05]
30 0x7f128086b9b8 pqPropertiesPanel::apply() + 1096
29 0x7f1280750912 pqPropertiesPanel::applied(pqProxy*) + 50
28 0x7f127f04ba05 /home/billae/develop/spackinstaller/spack/opt/spack/linux-ubuntu18.04-skylake/gcc-9.3.0/qt-5.15.2-5xitr7lkdgaeebnku5kkaabra6f4zv32/lib/libQt5Core.so.5(+0x2dea05) [0x7f127f04ba05]
27 0x7f12817ac1d6 pqApplyBehavior::applied(pqPropertiesPanel*, pqProxy*) + 198
26 0x7f12817ad00a pqApplyBehavior::showData(pqPipelineSource*, pqView*) + 378
25 0x7f127a0a5ea2 vtkSMParaViewPipelineControllerWithRendering::ShowInPreferredView(vtkSMSourceProxy*, int, vtkSMViewProxy*) + 146
24 0x7f127a0a4052 vtkSMParaViewPipelineControllerWithRendering::UpdatePipelineBeforeDisplay(vtkSMSourceProxy*, int, vtkSMViewProxy*) + 226
23 0x7f127a20bf9f vtkSMSourceProxy::UpdatePipeline(double) + 79
22 0x7f127a1a0df8 vtkSMOutputPort::UpdatePipelineInternal(double, bool) + 184
21 0x7f127a10fca4 vtkPVSessionBase::ExecuteStream(unsigned int, vtkClientServerStream const&, bool) + 52
20 0x7f127a110a80 vtkPVSessionCore::ExecuteStream(unsigned int, vtkClientServerStream const&, bool) + 64
19 0x7f127a110c33 vtkPVSessionCore::ExecuteStreamInternal(vtkClientServerStream const&, bool) + 243
18 0x7f127cb9b3cd vtkClientServerInterpreter::ProcessStream(vtkClientServerStream const&) + 29
17 0x7f127cb9af07 vtkClientServerInterpreter::ProcessOneMessage(vtkClientServerStream const&, int) + 167
16 0x7f127cb9ae05 vtkClientServerInterpreter::ProcessCommandInvoke(vtkClientServerStream const&, int) + 1189
15 0x7f127cb9a881 vtkClientServerInterpreter::CallCommandFunction(char const*, vtkObjectBase*, char const*, vtkClientServerStream const&, vtkClientServerStream&) + 193
14 0x7f1267bbf2b3 vtkSISourceProxyCommand(vtkClientServerInterpreter*, vtkObjectBase*, char const*, vtkClientServerStream const&, vtkClientServerStream&, void*) + 2211
13 0x7f127a140ac0 vtkSISourceProxy::UpdatePipeline(int, double, bool) + 416
12 0x7f126aac7534 vtkStreamingDemandDrivenPipeline::Update(int, vtkInformationVector*) + 276
11 0x7f126aa8afbd vtkDemandDrivenPipeline::UpdateData(int) + 141
10 0x7f126aac64e9 vtkStreamingDemandDrivenPipeline::ProcessRequest(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 1305
9 0x7f126aa8c032 vtkDemandDrivenPipeline::ProcessRequest(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 290
8 0x7f126aa85674 vtkCompositeDataPipeline::ForwardUpstream(vtkInformation*) + 340
7 0x7f126aac64e9 vtkStreamingDemandDrivenPipeline::ProcessRequest(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 1305
6 0x7f126aa8c1ed vtkDemandDrivenPipeline::ProcessRequest(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 733
5 0x7f126aa86741 vtkCompositeDataPipeline::ExecuteData(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 113
4 0x7f126aa89ad9 vtkDemandDrivenPipeline::ExecuteData(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 57
3 0x7f126aa8f272 vtkExecutive::CallAlgorithm(vtkInformation*, int, vtkInformationVector**, vtkInformationVector*) + 66
2 0x7f126aa9ccb0 vtkMultiTimeStepAlgorithm::ProcessRequest(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 1488
1 0x7f1274e7ac9f vtkTemporalInterpolator::RequestData(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 799
0 0x7f1281bdf040 /lib/x86_64-linux-gnu/libc.so.6(+0x3f040) [0x7f1281bdf040]
( 25.807s) [paraview ] :0 FATL| Signal: SIGSEGV
Erreur de segmentation (core dumped)
```
I work on a ubuntu (18) laptop with the master branch of paraview not totally up to date (commit 1f20710).
Is the problem only on my installation ?
Thanks5.10 (Fall 2021)Utkarsh AyachitUtkarsh Ayachithttps://gitlab.kitware.com/paraview/paraview/-/issues/20922Rename Ioss to IOSS2021-09-02T23:31:45-04:00Utkarsh AyachitRename Ioss to IOSSRename Ioss to IOSSRename Ioss to IOSS5.10 (Fall 2021)https://gitlab.kitware.com/paraview/paraview/-/issues/20908Ioss: changing block colors2021-09-03T20:29:46-04:00Utkarsh AyachitIoss: changing block colors open `can.e.4.*` using builtin server then a 2 rank pvserver. The colors are different both times. This is a bug. We should have consistent colors. open `can.e.4.*` using builtin server then a 2 rank pvserver. The colors are different both times. This is a bug. We should have consistent colors.5.10 (Fall 2021)Utkarsh AyachitUtkarsh Ayachithttps://gitlab.kitware.com/paraview/paraview/-/issues/20898Enable easier 3DConnexion device usage by ParaView2022-09-08T15:47:10-04:00Cory Quammencory.quammen@kitware.comEnable easier 3DConnexion device usage by ParaViewCurrently ParaView supports interaction via 3DConnexion devices (e.g. SpaceNavigator) through the VRPlugin. Using this plugin requires a somewhat complex configuration procedure, and requires that the 3DConnexion system drivers not be pr...Currently ParaView supports interaction via 3DConnexion devices (e.g. SpaceNavigator) through the VRPlugin. Using this plugin requires a somewhat complex configuration procedure, and requires that the 3DConnexion system drivers not be present on the system. Please provide an alternative implementation that does not require the VRPlugin that works with the 3DConnexion system drivers.5.11 (Spring 2022)Aron HelserAron Helserhttps://gitlab.kitware.com/paraview/paraview/-/issues/20892Update website tutorials2021-09-21T16:36:07-04:00W. Alan ScottUpdate website tutorialsPlease DO NOT work on this bug August 17th. This page is needed for a tutorial.
Please update the ParaView website tutorials links.
- [x] Resources/ Tutorials should change "The ParaView Tutorial" to be "ParaView Self-directed Tutori...Please DO NOT work on this bug August 17th. This page is needed for a tutorial.
Please update the ParaView website tutorials links.
- [x] Resources/ Tutorials should change "The ParaView Tutorial" to be "ParaView Self-directed Tutorial"
- [x] Resources/ Tutorials should change "ParaView SNL Tutorial" to be "ParaView Classroom Tutorials"
- [x] Resources/ Wiki/ "The ParaView Tutorial" should be "ParaView Self-directed Tutorial"
- [x] Resources/ Wiki/ "SNL ParaView Tutorials" should be "ParaView Classroom Tutorial" (
- [x] Change the title of the main page of the "SNL ParaView Tutorial" to be "ParaView Classroom Tutorial"
- [x] The underlying link is SNL_Paraview_4_Totorial. Could we change that link to something better, such as ParaView_Classroom_Tutorial.5.10 (Fall 2021)https://gitlab.kitware.com/paraview/paraview/-/issues/20885Resample to Image -> Surface Representation Is not consistent with different ...2021-08-24T14:57:13-04:00Ethan StamResample to Image -> Surface Representation Is not consistent with different levels of parallelism@utkarsh.ayachit @cory.quammen
@patchett2002 Can you prioritize this?
Tested with client-server. Client: MacOS nightly binary. Server: Spack build of `paraview@master` on linux
The surface representation of resample to image filter o...@utkarsh.ayachit @cory.quammen
@patchett2002 Can you prioritize this?
Tested with client-server. Client: MacOS nightly binary. Server: Spack build of `paraview@master` on linux
The surface representation of resample to image filter output varies when scaling the number of ranks used.
Pipeline to reproduce (using default values for everything):
1. Open headsq.vti
2. Tetrahedralize
3. Resample to image
4. Show surface
1 MPI Rank:
![1-ranks_head-tet-resample-surface](/uploads/0e257fefa6a957e8633eb5ade25b2ca4/1-ranks_head-tet-resample-surface.png)
9 MPI Ranks:
![9-ranks_head-tet-resample-surface](/uploads/f802d4ee751f4350c9f93724ff572757/9-ranks_head-tet-resample-surface.png)
18 MPI Ranks:
![18-ranks_head-tet-resample-surface](/uploads/4d95bf0726ca8853ed6f95a633a55a0b/18-ranks_head-tet-resample-surface.png)
36 MPI Ranks:
![36-ranks_head-tet-resample-surface](/uploads/3a8f89bbb112ab799c632c39c3b54a63/36-ranks_head-tet-resample-surface.png)
72 MPI Ranks:
![72-ranks_head-tet-resample-surface](/uploads/1cad45db3974b92b29c37bc04e93d3b2/72-ranks_head-tet-resample-surface.png)5.10 (Fall 2021)Utkarsh AyachitUtkarsh Ayachithttps://gitlab.kitware.com/paraview/paraview/-/issues/20879Assemblies need underlying blocks layout in properties tab2021-08-24T17:09:47-04:00W. Alan ScottAssemblies need underlying blocks layout in properties tabAssemblies also need underlying blocks layout added to the properties tab. Please make the layout look similar to the Information tab. #20875. Here is the rational from my customer:
If we think about your example where you have a doz...Assemblies also need underlying blocks layout added to the properties tab. Please make the layout look similar to the Information tab. #20875. Here is the rational from my customer:
If we think about your example where you have a dozen assemblies with a dozen parts in each, typically speaking we would expect in a tree like structure you would expect to have to expand the assemblies to see the parts within them. So if we assume there are ~100 parts in the exodus file you have now reduced the tree to 12 items that you can expand on. So the "scroll problem from hell" wont really happen and there will likely actually be an improvement.
You could argue that a user might go ahead and expand all of the assemblies but realistically the whole point of assemblies is to not do this and make large models easier to navigate.
User also gave me this example from a competitor: https://www.programmersought.com/article/64558516771/
As this is so tied to assemblies in the information tab, marking for 5.10. OK to slip to 5.11.5.10 (Fall 2021)Utkarsh AyachitUtkarsh Ayachithttps://gitlab.kitware.com/paraview/paraview/-/issues/20875Assemblies need underlying blocks layout in information tab2021-08-24T17:06:49-04:00W. Alan ScottAssemblies need underlying blocks layout in information tabIn the information tab, for Exodus datasets that include assemblies and are read in the IOSS reader, please add the underlying blocks for each assembly. As an example, I have the following Information tab layout presently. Note, exampl...In the information tab, for Exodus datasets that include assemblies and are read in the IOSS reader, please add the underlying blocks for each assembly. As an example, I have the following Information tab layout presently. Note, example is from file Cylinders_NS.e (given to Utkarsh).
![Screen_Shot_2021-08-05_at_7.29.24_PM](/uploads/6cdae6cd7908a100ea97dc1b86393767/Screen_Shot_2021-08-05_at_7.29.24_PM.png)
I want optionally, default on, the assemblies to have blocks shown, looking like this (note, I don't know what blocks go into each assembly, so am making this up). Alternatively, allow each assembly to be expanded by ... clicking on it?
```
assemblies
Inner_136
cylinder_1_12
cylinder_2_22
nodelist_21
TopMiddle_138
nodelist_31
nodelist_32
Base_122
cylinder_1_12
cylinder_2_22
nodelist_32
Outer_134
4_cheese_pizza
anchovies_1
sausage_4
```
@utkarsh.ayachit5.10 (Fall 2021)Utkarsh AyachitUtkarsh Ayachithttps://gitlab.kitware.com/paraview/paraview/-/issues/20873IOSS reader is slow reading headers in parallel2023-01-31T13:19:12-05:00W. Alan ScottIOSS reader is slow reading headers in parallelThe IOSS reader is slow when reading a multifile dataset in parallel. I have a test case with 512 files, 344 timesteps and about 100 blocks. It reads as follows:
* Header load (i.e., before Apply button is active): IOSS reader - 3:15 ,...The IOSS reader is slow when reading a multifile dataset in parallel. I have a test case with 512 files, 344 timesteps and about 100 blocks. It reads as follows:
* Header load (i.e., before Apply button is active): IOSS reader - 3:15 , Exodus reader - :06
* Apply to data loaded: IOSS reader - :30, Exodus reader - :34
* Timestep 50: IOSS reader - :11, Exodus reader - :08
What is happening is probably two fold:
* My guess is that the IOSS reader is reading the header for every file. The Exodus reader reads one header, and passes the data around to all of the other file header structures.
* To make matters worse, time data is stored throughout the files. To acquire time data for the Information tab, I suspect the IOSS reader is reading all time data throughout the files for every single file in the dataset. It then throws this data away, except process 0.
@cory.quammen As I have users that have up to a million files, this is a showstopper bug for the 5.10 release.
I have a dataset that replicates this issue, but it is 238 Gbytes... I can share it with Kitware. (I could make it one or two timesteps...)
@utkarsh.ayachit5.10 (Fall 2021)Utkarsh AyachitUtkarsh Ayachithttps://gitlab.kitware.com/paraview/paraview/-/issues/20872Python detects `mpicc` as an Intel compiler even when wrapping gcc2022-08-16T21:26:25-04:00W. Alan ScottPython detects `mpicc` as an Intel compiler even when wrapping gccWe see an error when configuring/building python from superbuild on some of our HPC machines when we build with gcc (not an issue with icc).
The nature of the problem is this: After unpacking the python zip file downloaded from the su...We see an error when configuring/building python from superbuild on some of our HPC machines when we build with gcc (not an issue with icc).
The nature of the problem is this: After unpacking the python zip file downloaded from the superbuild tarball site, the python/src/configure.ac file has the following items in it:
```
7517 case "$CC" in
7518 *icc*)
7519 CFLAGS_NODIST="$CFLAGS_NODIST -fp-model strict"
7520 ;;
7521 esac
```
The apparent intent is to add the “-fp-model strict” argument when using the intel compiler.
However, for many of our HPC module setups, the compiler gets aliased from “gcc” (or “icc”) to “mpicc”. Thus we are building with gcc, but $CC in the config file is “mpicc”. “mpicc” contains “icc” so the configuration script thinks we are using the intel compiler and adds the -fp-model strict argument. The gcc compiler then fails to work with the added arguments -fp-model strict (I think because it would ignore the extraneous option, but then it doesn’t know what to do with “strict”).
My current workaround is to surround this section with an if argument when looks for an environment variable, and if the environment variable is true it doesn’t check for “icc” and doesn’t add -fp-model strict:
```
7514 if test "$PYTHON_BUILD_EXCLUDE_FP_MODEL_ARGUMENT" = "true"; then
7515 echo "do not use fp-model strict argument"
7516 else
7517 case "$CC" in
7518 *icc*)
7519 CFLAGS_NODIST="$CFLAGS_NODIST -fp-model strict"
7520 ;;
7521 esac
7522 fi
```
But of course that means I have a slightly different .zip file for the python, and thus a different crc check too.
The ultimate fix I need is to have the configure.ac file correctly identify whether we are using the intel compiler or the gcc (or clang) compiler even if the aliased name of the compiler is mpicc. But I absolutely need a way to prevent the configuration from adding “-fp-model strict” to the gcc builds, even when gcc is aliased to “mpicc”
@ben.boeckel @jamauld
@cory.quammen - Can't slip past 5.10.5.11 (Spring 2022)https://gitlab.kitware.com/paraview/paraview/-/issues/20868Spack build of paraview@master fails with 'Could not find the SEACASIoss exte...2021-08-17T13:46:04-04:00Ethan StamSpack build of paraview@master fails with 'Could not find the SEACASIoss external dependency.'@utkarsh.ayachit @cory.quammen
Last night (8/3/21), our spack builds of `paraview@master` failed with:
```console
CMake Warning at VTK/CMake/vtkModule.cmake:4360 (find_package):
By not providing "FindSEACASIoss.cmake" in CMAKE_MODUL...@utkarsh.ayachit @cory.quammen
Last night (8/3/21), our spack builds of `paraview@master` failed with:
```console
CMake Warning at VTK/CMake/vtkModule.cmake:4360 (find_package):
By not providing "FindSEACASIoss.cmake" in CMAKE_MODULE_PATH this project
has asked CMake to find a package configuration file provided by
"SEACASIoss", but CMake did not find one.
Could not find a package configuration file provided by "SEACASIoss" with
any of the following names:
SEACASIossConfig.cmake
seacasioss-config.cmake
Add the installation prefix of "SEACASIoss" to CMAKE_PREFIX_PATH or set
"SEACASIoss_DIR" to a directory containing one of the above files. If
"SEACASIoss" provides a separate development package or SDK, be sure it has
been installed.
Call Stack (most recent call first):
VTK/CMake/vtkModule.cmake:4960 (vtk_module_find_package)
VTK/CMake/vtkModule.cmake:4831 (vtk_module_third_party_external)
VTK/ThirdParty/ioss/CMakeLists.txt:6 (vtk_module_third_party)
CMake Error at VTK/CMake/vtkModule.cmake:4366 (message):
Could not find the SEACASIoss external dependency.
Call Stack (most recent call first):
VTK/CMake/vtkModule.cmake:4960 (vtk_module_find_package)
VTK/CMake/vtkModule.cmake:4831 (vtk_module_third_party_external)
VTK/ThirdParty/ioss/CMakeLists.txt:6 (vtk_module_third_party)
-- Configuring incomplete, errors occurred!
```
This error happened across the board, so it should be reproducible with just `spack install paraview@master`.
I'm guessing we need to let paraview build `SEACASIoss`, or is there a spack package that is preferred?5.10 (Fall 2021)https://gitlab.kitware.com/paraview/paraview/-/issues/20866Add sum option to Plot Data and Plot Data Over Time2022-03-21T15:58:36-04:00Boonthanome NouanesengsyAdd sum option to Plot Data and Plot Data Over TimeThe current pipeline to get a summation of a point data variable is overly complicated. Currently the pipeline is `MergeBlocks` -> `Descriptive Statistics` -> `Extract Blocks` (extract the second block named `Derived Statistics`) -> `Plo...The current pipeline to get a summation of a point data variable is overly complicated. Currently the pipeline is `MergeBlocks` -> `Descriptive Statistics` -> `Extract Blocks` (extract the second block named `Derived Statistics`) -> `Plot Data Over Time`.
It would be good to have an option in the `Plot Data` and `Plot Data Over Time` filters to show the sum.
@patchett2002 @cory.quammen @utkarsh.ayachit5.11 (Spring 2022)Yohann Bearzi (Kitware)Yohann Bearzi (Kitware)https://gitlab.kitware.com/paraview/paraview/-/issues/20864Saving screenshot with transparent background not working2022-01-06T13:21:43-05:00Utkarsh AyachitSaving screenshot with transparent background not workingSaving screenshot with transparent background not workingSaving screenshot with transparent background not working5.10 (Fall 2021)Utkarsh AyachitUtkarsh Ayachithttps://gitlab.kitware.com/paraview/paraview/-/issues/20860Ghost cell generator crashes with SIGSEGV in Wavelet -> Threshold -> Aggregat...2021-10-04T17:34:24-04:00Ethan StamGhost cell generator crashes with SIGSEGV in Wavelet -> Threshold -> Aggregate Data -> Generate Ghost Cells pipeline@yohann.bearzi @cory.quammen @utkarsh.ayachit @patchett2002
Local linux client from [here](https://open.cdash.org/upload/c40a054ee43b11b15a90698c6bf9b0385f057222/ParaView-5.9.1-1451-g686e45e-MPI-Linux-Python3.9-x86_64.tar.gz)
Server i...@yohann.bearzi @cory.quammen @utkarsh.ayachit @patchett2002
Local linux client from [here](https://open.cdash.org/upload/c40a054ee43b11b15a90698c6bf9b0385f057222/ParaView-5.9.1-1451-g686e45e-MPI-Linux-Python3.9-x86_64.tar.gz)
Server is intel, openmpi, osmesa build with spack of ParaView @ 686e45ea1c890c370960498dcbc7c44b54b4dc56
The server crashed on Apply of the ghost cell generator after this pipeline with `Loguru caught a signal: SIGSEGV`
To reproduce:
1. Default wavelet source (36 MPI ranks)
2. Threshold filter (capture everything)
3. Aggregate Dataset filter (Down to 8 MPI ranks)
4. Default Generate Ghost Cells filter -> Apply
Stack trace:
```console
Stack trace:
26 0x403589 /yellow/usr/projects/paraview/pilotlight/tmp_snow_master_intel_19.0.4.243/spack/opt/spack/linux-rhel7-broadwell/intel-19.0.4.243/paraview-master-2ryfgurki4x53k4cdbmnehmtt7repmgi/bin/pvserver() [0x403589]
25 0x2b1ace8c8555 __libc_start_main + 245
24 0x403828 /yellow/usr/projects/paraview/pilotlight/tmp_snow_master_intel_19.0.4.243/spack/opt/spack/linux-rhel7-broadwell/intel-19.0.4.243/paraview-master-2ryfgurki4x53k4cdbmnehmtt7repmgi/bin/pvserver() [0x403828]
23 0x2b1ac5f86711 vtkMultiProcessController::ProcessRMIs(int, int) + 657
22 0x2b1ac5f86fb4 vtkMultiProcessController::BroadcastProcessRMIs(int, int) + 164
21 0x2b1ac5f86d33 vtkMultiProcessController::ProcessRMI(int, void*, int, int) + 963
20 0x2b1ac4eb8f9a vtkPVSessionCore::ExecuteStreamSatelliteCallback() + 170
19 0x2b1ac4eb8417 vtkPVSessionCore::ExecuteStreamInternal(vtkClientServerStream const&, bool) + 167
18 0x2b1ac4391309 vtkClientServerInterpreter::ProcessStream(vtkClientServerStream const&) + 41
17 0x2b1ac438dc72 vtkClientServerInterpreter::ProcessOneMessage(vtkClientServerStream const&, int) + 1922
16 0x2b1ac438fd5d vtkClientServerInterpreter::ProcessCommandInvoke(vtkClientServerStream const&, int) + 301
15 0x2b1ac4391697 vtkClientServerInterpreter::CallCommandFunction(char const*, vtkObjectBase*, char const*, vtkClientServerStream const&, vtkClientServerStream&) + 855
14 0x2b1ac21997fc vtkSISourceProxyCommand(vtkClientServerInterpreter*, vtkObjectBase*, char const*, vtkClientServerStream const&, vtkClientServerStream&, void*) + 1772
13 0x2b1ac4efcdc6 vtkSISourceProxy::UpdatePipeline(int, double, bool) + 326
12 0x2b1aca472bd5 vtkStreamingDemandDrivenPipeline::Update(int, vtkInformationVector*) + 261
11 0x2b1aca408acf vtkDemandDrivenPipeline::UpdateData(int) + 143
10 0x2b1aca4726d1 vtkStreamingDemandDrivenPipeline::ProcessRequest(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 1809
9 0x2b1aca4078fc vtkDemandDrivenPipeline::ProcessRequest(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 252
8 0x2b1aca402c3a vtkCompositeDataPipeline::ForwardUpstream(vtkInformation*) + 314
7 0x2b1aca4726d1 vtkStreamingDemandDrivenPipeline::ProcessRequest(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 1809
6 0x2b1aca4079aa vtkDemandDrivenPipeline::ProcessRequest(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 426
5 0x2b1aca403240 vtkCompositeDataPipeline::ExecuteData(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 64
4 0x2b1aca408e59 vtkDemandDrivenPipeline::ExecuteData(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 57
3 0x2b1aca40cc7d vtkExecutive::CallAlgorithm(vtkInformation*, int, vtkInformationVector**, vtkInformationVector*) + 61
2 0x2b1ac5d09494 vtkGhostCellsGenerator::RequestData(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 3156
1 0x2b1ac5d12434 int vtkDIYGhostUtilities::GenerateGhostCells<vtkUnstructuredGrid>(std::vector<vtkUnstructuredGrid*>&, std::vector<vtkUnstructuredGrid*>&, int, vtkMultiProcessController*) + 2100
0 0x2b1ac5d82c6c vtkDIYGhostUtilities::SetupBlockSelfInformation(vtkdiy2::Master&, std::vector<vtkUnstructuredGrid*>&) + 1084
```5.10 (Fall 2021)Yohann Bearzi (Kitware)Yohann Bearzi (Kitware)https://gitlab.kitware.com/paraview/paraview/-/issues/20858Trace recorder misses resetting to axis2022-04-05T14:35:37-04:00W. Alan ScottTrace recorder misses resetting to axisThe trace recorder is missing setting the camera to an axis, i.e., CameraViewUp. Here is how to replicate.
* 5.9.1, Linux, builtin server.
* Start trace.
* Open Can.exo. Apply. (incredibly, Sources/ Box works correctly. Further, it...The trace recorder is missing setting the camera to an axis, i.e., CameraViewUp. Here is how to replicate.
* 5.9.1, Linux, builtin server.
* Start trace.
* Open Can.exo. Apply. (incredibly, Sources/ Box works correctly. Further, it opens with a different orientation.)
* 2d rotate the can.
* Save Screenshot. Call it deleteMeA.png
* +Z
* Save Screenshot. Call it deleteMeB.png
* Stop Trace. Save as deleteMeRotate.py
Notice that deleteMeB will be lined up horizontally and vertically.
* Delete deleteMeA and deleteMeB.
* pvbatch deleteMeRotate.py
deleteMeB.png is still rotated. This is a bug.
The trace won't have a second CameraViewUp in it after the +Z.
Here's the critical section:
START TRACE
```
# current camera placement for renderView1
renderView1.CameraPosition = [0.21706008911132812, 4.0, 46.62962661474568]
renderView1.CameraFocalPoint = [0.21706008911132812, 4.0, -5.110947132110596]
renderView1.CameraViewUp = [-0.4567642696140838, 0.8895877708264164, 0.0]
renderView1.CameraParallelScale = 13.391445890217907
# save screenshot
SaveScreenshot('/snip/deleteMeA.png', renderView1, ImageResolution=[1950, 966])
# reset view to fit data
renderView1.ResetCamera()
# reset view to fit data
renderView1.ResetCamera()
# layout/tab size in pixels
layout1.SetSize(1950, 966)
############ Just above here, we did a +Z
############ Notice that we are missing a CameraViewUp here...
# current camera placement for renderView1
renderView1.CameraPosition = [0.21706008911132812, 4.0, 46.62962661474573]
renderView1.CameraFocalPoint = [0.21706008911132812, 4.0, -5.110947132110596]
renderView1.CameraParallelScale = 13.391445890217907
# save screenshot
SaveScreenshot('/snip/deleteMeB.png', renderView1, ImageResolution=[1950, 966])
```5.11 (Spring 2022)https://gitlab.kitware.com/paraview/paraview/-/issues/20855conduit_cpp::cpp_node creates a copy instead of a wrapper2021-08-10T16:46:51-04:00Francois Mazenconduit_cpp::cpp_node creates a copy instead of a wrapperWhen modify the `conduit_cpp::Node` created via `conduit_cpp::cpp_node(conduit_node* n)`, then the original `conduit_node` is not modified. It seems that we are modifying a copy of the underlying `conduit_node` instead of pointing to the...When modify the `conduit_cpp::Node` created via `conduit_cpp::cpp_node(conduit_node* n)`, then the original `conduit_node` is not modified. It seems that we are modifying a copy of the underlying `conduit_node` instead of pointing to the same data.
To reproduce:
```cpp
conduit_cpp::Node first_node;
conduit_node* first_node_c_node = conduit_cpp::c_node(&first_node);
conduit_cpp::Node second_node = conduit_cpp::cpp_node(first_node_c_node);
second_node["test"] = 2;
std::cout << "first_node:" << std::endl;
first_node.print();
std::cout << "second_node:" << std::endl;
second_node.print();
```
produces this output:
```
first_node:
null
second_node:
{
"test": 2
}
```
we expect the same values for first_node and second_node.
The same unwanted behavior could be reproduced using the C API:
```c
conduit_node* n = conduit_node_create();
conduit_node* n2 = conduit_node_create();
conduit_node_set_external_node(n2, n);
conduit_node* child_node = conduit_node_fetch(n2, "test");
conduit_node_set_int(child_node, 2);
std::cout << "n:" << std::endl;
conduit_node_print(n);
std::cout << "n2:" << std::endl;
conduit_node_print(n2);
```
Same output:
```
n:
null
n2:
{
"test": 2
}
```
(In case of this is intended behavior, what method can create a real C++ wrapper of a `conduit_node*`?)5.10 (Fall 2021)