ParaView issues
https://gitlab.kitware.com/paraview/paraview/-/issues
2020-05-04T23:59:53-04:00
https://gitlab.kitware.com/paraview/paraview/-/issues/19124
Pvbatch/pvpython can't find valid OpenGL context, while ParaView GUI can
2020-05-04T23:59:53-04:00
Paul Melis
Pvbatch/pvpython can't find valid OpenGL context, while ParaView GUI can
On a Linux 3.10.0 compute node with two Tesla K40m's, with an X server running:
```
paulm@gcn4 17:07 ~$ nvidia-smi
Tue Jun 25 17:07:31 2019
+-----------------------------------------------------------------------------+
| NVIDIA...
On a Linux 3.10.0 compute node with two Tesla K40m's, with an X server running:
```
paulm@gcn4 17:07 ~$ nvidia-smi
Tue Jun 25 17:07:31 2019
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 418.39 Driver Version: 418.39 CUDA Version: 10.1 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
|===============================+======================+======================|
| 0 Tesla K40m On | 00000000:02:00.0 Off | 0 |
| N/A 32C P8 19W / 235W | 6MiB / 11441MiB | 0% Default |
+-------------------------------+----------------------+----------------------+
| 1 Tesla K40m On | 00000000:82:00.0 Off | 0 |
| N/A 27C P8 19W / 235W | 6MiB / 11441MiB | 0% Default |
+-------------------------------+----------------------+----------------------+
+-----------------------------------------------------------------------------+
| Processes: GPU Memory |
| GPU PID Type Process name Usage |
|=============================================================================|
| 0 54980 G /usr/bin/X 5MiB |
| 1 54980 G /usr/bin/X 5MiB |
+-----------------------------------------------------------------------------+
paulm@gcn4 17:07 ~$ DISPLAY=:0.0 glxinfo | grep OpenGL
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: Tesla K40m/PCIe/SSE2
OpenGL core profile version string: 4.6.0 NVIDIA 418.39
OpenGL core profile shading language version string: 4.60 NVIDIA
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.6.0 NVIDIA 418.39
OpenGL shading language version string: 4.60 NVIDIA
OpenGL context flags: (none)
OpenGL profile mask: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 418.39
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: Tesla K40m/PCIe/SSE2
OpenGL core profile version string: 4.6.0 NVIDIA 418.39
OpenGL core profile shading language version string: 4.60 NVIDIA
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.6.0 NVIDIA 418.39
OpenGL shading language version string: 4.60 NVIDIA
OpenGL context flags: (none)
OpenGL profile mask: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 418.39
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:
```
With ParaView 5.6.0 compiled against real NVIDIA OpenGL (i.e. not Mesa). If I run the ParaView GUI directly on the X server it seems to work (can't check as it's a headless node). Glxgears also reports good framerates, so I assume the OpenGL drivers and access through X are working (if I use the same node through VNC and VirtualGL all is fine with the ParaView GUI and its rendering, same for Blender, etc):
```
paulm@gcn4 17:09 ~$ DISPLAY=:0.0 paraview
<no errors>...
paulm@gcn4 17:08 ~$ DISPLAY=:0.0 glxgears
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
73762 frames in 5.0 seconds = 14752.353 FPS
74113 frames in 5.0 seconds = 14822.405 FPS
```
However, using pvpython and pvbatch fail to allocate an OpenGL context:
```
paulm@gcn4 17:11 ~$ cat pvbatch_test.py
from paraview.simple import *
cone = Cone(Resolution=32)
cone.Center = [1, 2, 3]
shrinkFilter = Shrink(cone)
shrinkFilter.UpdatePipeline()
Show(shrinkFilter)
Render()
WriteImage('test2.png')
paulm@gcn4 17:11 ~$ DISPLAY=:0.0 pvbatch pvbatch_test.py > out 2>&1
Aborted (core dumped)
paulm@gcn4 17:11 ~$ cat out
ERROR: In /tmp/pma55/ParaView/5.6.0/foss-2017b-mpi-nvidia/ParaView-v5.6.0/VTK/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx, line 749
vtkXOpenGLRenderWindow (0x4f1a600): Unable to find a valid OpenGL 3.2 or later implementation. Please update your video card driver to the latest version. If you are using Mesa please make sure you have version 11.2 or later and make sure your driver in Mesa supports OpenGL 3.2 such as llvmpipe or openswr. If you are on windows and using Microsoft remote desktop note that it only supports OpenGL 3.2 with nvidia quadro cards. You can use other remoting software such as nomachine to avoid this issue.
ERROR: In /tmp/pma55/ParaView/5.6.0/foss-2017b-mpi-nvidia/ParaView-v5.6.0/VTK/Rendering/OpenGL2/vtkXOpenGLRenderWindow.cxx, line 796
vtkXOpenGLRenderWindow (0x4f1a600): failed to create offscreen window
ERROR: In /tmp/pma55/ParaView/5.6.0/foss-2017b-mpi-nvidia/ParaView-v5.6.0/VTK/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx, line 736
vtkXOpenGLRenderWindow (0x4f1a600): GLEW could not be initialized.
...
```
See attached log file for full error trace.
[out.gz](/uploads/b0b566cd5f081bae120e05780135ef51/out.gz)
https://gitlab.kitware.com/paraview/paraview/-/issues/19185
ParaView 5.7.0-RC1: ray tracing seems to cause unexpected behaviours with han...
2021-03-24T05:35:58-04:00
Philippe Morrain
ParaView 5.7.0-RC1: ray tracing seems to cause unexpected behaviours with handle widgets.
See this post for gifs and description: https://discourse.paraview.org/t/paraview-5-7-rc1-ray-tracing-seems-to-cause-unexpected-behaviours-with-handle-widgets/
See this post for gifs and description: https://discourse.paraview.org/t/paraview-5-7-rc1-ray-tracing-seems-to-cause-unexpected-behaviours-with-handle-widgets/
https://gitlab.kitware.com/paraview/paraview/-/issues/19341
glTF exported streamlines ends up in wrong position
2021-03-24T05:52:49-04:00
Lars Olsson
glTF exported streamlines ends up in wrong position
When exporting streamlines (streamtracer + tubes and glyphs) to glTF in 5.7 RC4, the exported geometries ends up in the wrong position. The export worked correctly in RC3. Note: we're also exporting stl and they end up in the correct pos...
When exporting streamlines (streamtracer + tubes and glyphs) to glTF in 5.7 RC4, the exported geometries ends up in the wrong position. The export worked correctly in RC3. Note: we're also exporting stl and they end up in the correct position....so it seems to be streamline specific.
https://gitlab.kitware.com/paraview/paraview/-/issues/19377
legend font size settings not respected when saving animation for split-view ...
2021-04-07T11:04:23-04:00
Paul Navrátil
legend font size settings not respected when saving animation for split-view layout
Hello,
I stumbled on a corner case in the Save Animation feature that I at least wanted to put on the radar. If you change the font size for a legend in a split-view layout and then use Save Animation and click "Save All Views", the leg...
Hello,
I stumbled on a corner case in the Save Animation feature that I at least wanted to put on the radar. If you change the font size for a legend in a split-view layout and then use Save Animation and click "Save All Views", the legend font size resets to default (16 point). If you only save one view, the legend font size settings are kept. It appears to be related to the window adjustments that ParaView makes in order to combine the views for the final render.
I've attached a screen-capture showing the legends (set to Arial 12 for title and Arial 8 for text/annotation) and an output frame from the animation showing the larger font results.
Thanks!
![Screen_Shot_2019-10-09_at_3.23.26_PM](/uploads/7b238b6786bbe23de5845c4b88733794/Screen_Shot_2019-10-09_at_3.23.26_PM.png)
![3d_diptych.0047](/uploads/f92ef95846c6edb5ed0db9b1e5642c1d/3d_diptych.0047.png)
https://gitlab.kitware.com/paraview/paraview/-/issues/19385
StreamTracerWithCustomSource of ParaView 5.7 with SurfaceStreamlines = 1 goes...
2022-08-22T11:07:19-04:00
Emanuele Leggio
StreamTracerWithCustomSource of ParaView 5.7 with SurfaceStreamlines = 1 goes up to 20 times slower than previous versions of ParaView
I conducted many tests with ParaView 5.7 and I noticed that by activating the SurfaceStreamlines in StreamTracerWithCustomSource filter the processing times have increased a lot.
To prove this claim I considered 3 cases with increasing...
I conducted many tests with ParaView 5.7 and I noticed that by activating the SurfaceStreamlines in StreamTracerWithCustomSource filter the processing times have increased a lot.
To prove this claim I considered 3 cases with increasing numbers of cells, all surfaces are with triangular mesh, seed point come from the surfaces.
| case | seed point | cell |
| :-----: | :-----: | :-----: |
| A | 1260 | 688294 |
| B | 11044 | 5531204 |
| C | 92947 | 40727434 |
I have tested 4 pre-builded versions of ParaView and two SuperBuild:
Pre-build:
* 5.3.0
* 5.4.1
* 5.5.2
* 5.7.0
SuperBuild:
* 5.6.0 (PV5.6SB)
* 5.7.0 (PV5.7SB)
I tested both the case with SurfaceStreamlines = 1 and SurfaceStreamlines = 0.
Each test was repeated 3 times in order to average the times; only with PV5.7SB I did only one run for each test. A little less than 100 runs in total.
To complete the analysis I report the number of points and cells of the final result in addition to the processing times.
Obviously all the tests were conducted on the same machine with the same operating system and in a serial manner without other processes.
RESULTS:
![results1](/uploads/6c1f2899eadfa1ddd2994f55b2a0167d/results1.png)
in the attachment you can find the two simple scripts I used to do this analysis and all the intermediate results logs.
[execute_streamTraceWCS.py](/uploads/b6ea9703fcb78bd4cd8ff13a631fba39/execute_streamTraceWCS.py)
[main_launch.py](/uploads/0a0d86374565e7b8aeb300f9f78b2425/main_launch.py)
[results.tar.gz](/uploads/f3a762a2546bfad325cb50a01d2c3d98/results.tar.gz)
https://gitlab.kitware.com/paraview/paraview/-/issues/19504
Non UTF8 char incorrectly writtten by the python state file saver
2022-09-24T00:10:40-04:00
Mathieu Westphal (Kitware)
Non UTF8 char incorrectly writtten by the python state file saver
When saving a python state containing file with non utf8 char in their name, the resulting state file contains garbage char.
Steps to reproduce :
* Open [tést.pvd](/uploads/7a8b116ba99ad61889689a8f2aa8324a/tést.pvd), Apply
* File -> Sa...
When saving a python state containing file with non utf8 char in their name, the resulting state file contains garbage char.
Steps to reproduce :
* Open [tést.pvd](/uploads/7a8b116ba99ad61889689a8f2aa8324a/tést.pvd), Apply
* File -> Save State -> python -> test.py
* ResetSession
* File -> Load State -> test.py
```
( 72.517s) [paraview ] vtkXMLReader.cxx:299 ERR| vtkPVDReader (0x7f353c019120): Error opening file /home/glow/tmp/tést.pvd
( 72.517s) [paraview ] vtkPVDReader.cxx:134 ERR| vtkPVDReader (0x7f353c019120): Could not read file information
( 72.518s) [paraview ] vtkExecutive.cxx:782 ERR| vtkPVCompositeDataPipeline (0x89d2850): Algorithm vtkPVDReader(0x7f353c019120) returned failure for request: vtkInformation (0x89d2660)
Debug: Off
Modified Time: 1866892
Reference Count: 1
Registered Events: (none)
Request: REQUEST_DATA_OBJECT
ALGORITHM_AFTER_FORWARD: 1
FORWARD_DIRECTION: 0
```
The resulting test.py contains :
```
tstpvd = PVDReader(FileName='/home/glow/tmp/tést.pvd')
```
Note : Strangely, the python trace behave correctly in this case.
https://gitlab.kitware.com/paraview/paraview/-/issues/19521
Filter: Limited number of output ports
2021-03-24T06:44:32-04:00
Mario Binkowski
Filter: Limited number of output ports
Following the documentation of [util.vtkAlgorithm](https://kitware.github.io/paraview-docs/latest/python/paraview.util.vtkAlgorithm.html) I want to write a filter which provides multiple output ports.
```
n = 10
from vtkmodules.util.vt...
Following the documentation of [util.vtkAlgorithm](https://kitware.github.io/paraview-docs/latest/python/paraview.util.vtkAlgorithm.html) I want to write a filter which provides multiple output ports.
```
n = 10
from vtkmodules.util.vtkAlgorithm import VTKPythonAlgorithmBase
from paraview.util.vtkAlgorithm import smproxy, smproperty, smdomain
@smproxy.filter(label='testMultipleOutput')
@smproperty.input(name='Input')
@smdomain.datatype(dataTypes=['vtkDataSet'], composite_data_supported=False)
class TestMultipleOutput(VTKPythonAlgorithmBase):
def __init__(self):
VTKPythonAlgorithmBase.__init__(self, nOutputPorts=n, outputType='vtkUnstructuredGrid')
def RequestData(self, request, inInfo, outInfo):
print(outInfo.GetNumberOfInformationObjects())
for i in range(n):
print(outInfo.GetInformationObject(i))
return 1
```
The above filter is doing fine. But if n is increased to some value > 10 the for loop crashes when i >= 10.
https://gitlab.kitware.com/paraview/paraview/-/issues/19559
Crash on SEG-Y files (ParaView 5.7 on MacOS)
2021-03-24T06:52:49-04:00
Alexey
Crash on SEG-Y files (ParaView 5.7 on MacOS)
This SEG-Y file works fine in ParaView 5.6.2 but not in ParaView 5.7. ParaView 5.6.2 requires ~2GB RAM to open the file but ParaView 5.7 crashes on ~50GB allocated memory (8GB RAM + swap).
The file is split to parts by command `split -b...
This SEG-Y file works fine in ParaView 5.6.2 but not in ParaView 5.7. ParaView 5.6.2 requires ~2GB RAM to open the file but ParaView 5.7 crashes on ~50GB allocated memory (8GB RAM + swap).
The file is split to parts by command `split -b 8000000 sample.sgy` due to upload size limit.
[xab](/uploads/c3fa630cc48784083bf365f73581c11d/xab)
[xaa](/uploads/96194defc763fadfcf29ca0d1c360b6f/xaa)
[xac](/uploads/dc17ac82a700c056f7eca6d46dc5911d/xac)
https://gitlab.kitware.com/paraview/paraview/-/issues/19571
If Python3 is turned off, ParaView fails on install
2020-12-10T21:51:32-05:00
W. Alan Scott
If Python3 is turned off, ParaView fails on install
If you turn Python3 off (no clue why yo), the Paraview make won't make pvbatch or pvpython. make install will try to install pvbatch and pvpython - and will then die. Here are the switches I (accidentally) flipped:
I did NOT have '...
If you turn Python3 off (no clue why yo), the Paraview make won't make pvbatch or pvpython. make install will try to install pvbatch and pvpython - and will then die. Here are the switches I (accidentally) flipped:
I did NOT have '-DENABLE_python3:BOOL=ON '
I DID have '-DUSE_SYSTEM_python3:BOOL=ON '
I DID have '-DENABLE_python:BOOL=ON '+\
and '-DENABLE_numpy:BOOL=ON '
W. Alan Scott
W. Alan Scott
https://gitlab.kitware.com/paraview/paraview/-/issues/19693
AMReX Boxlib Grid Reader segfault on plotfile with multiple levels
2021-03-24T07:11:10-04:00
Maikel Nadolski
AMReX Boxlib Grid Reader segfault on plotfile with multiple levels
Hi,
Given a plotfile with multiple AMR levels the Paraview-5.8 version for MacOs crashes with SegFault.
I haven't tried it for other OSes yet.
I append a plotfile which crashes for me.
[Ramp.zip](/uploads/3627d4b0ebbd992e891498a9705d...
Hi,
Given a plotfile with multiple AMR levels the Paraview-5.8 version for MacOs crashes with SegFault.
I haven't tried it for other OSes yet.
I append a plotfile which crashes for me.
[Ramp.zip](/uploads/3627d4b0ebbd992e891498a9705dd07e/Ramp.zip)
Stacktrace:
```
Loguru caught a signal: SIGSEGV
Stack trace:
65 0x7fff62d96ed9 start + 1
64 0x1052ba2f9 main + 521
63 0x106ab11c2 QCoreApplication::exec() + 402
62 0x106aac5b2 QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 418
61 0x119c96ea0 qt_plugin_instance + 178688
60 0x7fff3308e165 -[NSApplication run] + 699
59 0x7fff33094102 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1362
58 0x7fff33095363 _DPSNextEvent + 997
57 0x7fff34dda568 _BlockUntilNextEventMatchingListInModeWithFilter + 64
56 0x7fff34dda6f4 ReceiveNextEventCommon + 371
55 0x7fff34ddaab5 RunCurrentEventLoopInMode + 293
54 0x7fff35b43c64 CFRunLoopRunSpecific + 463
53 0x7fff35b4437a __CFRunLoopRun + 1219
52 0x7fff35b44dd1 __CFRunLoopDoSources0 + 195
51 0x7fff35b6133b __CFRunLoopDoSource0 + 108
50 0x7fff35b61395 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
49 0x119c98099 qt_plugin_instance + 183289
48 0x10639bedb QWindowSystemInterface::sendWindowSystemEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 155
47 0x1063b4336 QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*) + 3398
46 0x106ab0aaf QCoreApplication::notifyInternal2(QObject*, QEvent*) + 159
45 0x10564c9c9 QApplication::notify(QObject*, QEvent*) + 553
44 0x10564b622 QApplicationPrivate::notify_helper(QObject*, QEvent*) + 306
43 0x1056a6290 QDesktopWidget::qt_metacall(QMetaObject::Call, int, void**) + 5120
42 0x1056a7609 QDesktopWidget::qt_metacall(QMetaObject::Call, int, void**) + 10105
41 0x10564bf40 QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&, bool, bool) + 880
40 0x106ab0aaf QCoreApplication::notifyInternal2(QObject*, QEvent*) + 159
39 0x10564e3bd QApplication::notify(QObject*, QEvent*) + 7197
38 0x10564b622 QApplicationPrivate::notify_helper(QObject*, QEvent*) + 306
37 0x10582eec1 QToolButton::event(QEvent*) + 321
36 0x105739bc1 QAbstractButton::event(QEvent*) + 145
35 0x1056876bb QWidget::event(QEvent*) + 491
34 0x10582e90f QToolButton::mouseReleaseEvent(QMouseEvent*) + 15
33 0x10573a05f QAbstractButton::mouseReleaseEvent(QMouseEvent*) + 271
32 0x105738d99 QAbstractButton::isCheckable() const + 361
31 0x105641f05 QAction::activate(QAction::ActionEvent) + 309
30 0x106ae281a QMetaObject::activate(QObject*, int, int, void**) + 2954
29 0x1054c63e9 pqLoadDataReaction::onTriggered() + 41
28 0x10541ba71 pqLoadDataReaction::loadData() + 785
27 0x10541c395 pqLoadDataReaction::loadData(QList<QStringList> const&, QString const&, QString const&, pqServer*) + 1237
26 0x10541d454 pqLoadDataReaction::LoadFile(QStringList const&, pqServer*, QPair<QString, QString> const&) + 52
25 0x10604eb20 pqObjectBuilder::createReader(QString const&, QString const&, QStringList const&, pqServer*) + 2176
24 0x10604d064 pqObjectBuilderNS::postCreatePipelineProxy(vtkSMParaViewPipelineController*, vtkSMProxy*, pqServer*, QString const&) + 36
23 0x10a752713 vtkSMParaViewPipelineControllerWithRendering::PostInitializeProxy(vtkSMProxy*) + 51
22 0x106fc7a3e vtkSMParaViewPipelineController::PostInitializeProxy(vtkSMProxy*) + 510
21 0x10701cc7e vtkSMSourceProxy::UpdatePipelineInformation() + 110
20 0x106f46de7 vtkPVSessionBase::ExecuteStream(unsigned int, vtkClientServerStream const&, bool) + 55
19 0x106f49785 vtkPVSessionCore::ExecuteStream(unsigned int, vtkClientServerStream const&, bool) + 85
18 0x106f49a54 vtkPVSessionCore::ExecuteStreamInternal(vtkClientServerStream const&, bool) + 276
17 0x10748a52d vtkClientServerInterpreter::ProcessStream(vtkClientServerStream const&) + 61
16 0x10748a800 vtkClientServerInterpreter::ProcessOneMessage(vtkClientServerStream const&, int) + 688
15 0x10748b29a vtkClientServerInterpreter::ProcessCommandInvoke(vtkClientServerStream const&, int) + 346
14 0x10748c686 vtkClientServerInterpreter::CallCommandFunction(char const*, vtkObjectBase*, char const*, vtkClientServerStream const&, vtkClientServerStream&) + 374
13 0x1097f488a vtkSIMetaReaderProxyCommand(vtkClientServerInterpreter*, vtkObjectBase*, char const*, vtkClientServerStream const&, vtkClientServerStream&, void*) + 874
12 0x10748c686 vtkClientServerInterpreter::CallCommandFunction(char const*, vtkObjectBase*, char const*, vtkClientServerStream const&, vtkClientServerStream&) + 374
11 0x1097f7a9b vtkSISourceProxyCommand(vtkClientServerInterpreter*, vtkObjectBase*, char const*, vtkClientServerStream const&, vtkClientServerStream&, void*) + 939
10 0x106f6ff55 vtkSISourceProxy::UpdatePipelineInformation() + 181
9 0x1087836aa vtkStreamingDemandDrivenPipeline::ProcessRequest(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 1130
8 0x10873bd6f vtkDemandDrivenPipeline::ProcessRequest(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 799
7 0x1087842ea vtkStreamingDemandDrivenPipeline::ExecuteInformation(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 42
6 0x1087419d5 vtkExecutive::CallAlgorithm(vtkInformation*, int, vtkInformationVector**, vtkInformationVector*) + 69
5 0x10a654e25 vtkFileSeriesReader::ProcessRequest(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 277
4 0x10a655317 vtkFileSeriesReader::RequestInformation(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 279
3 0x10a655806 vtkFileSeriesReader::RequestInformationForInput(int, vtkInformation*, vtkInformationVector*) + 390
2 0x11161eb28 vtkAMRBaseReader::RequestInformation(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 248
1 0x108aa8b11 vtkAMRInformation::GenerateParentChildInformation() + 225
0 0x1062734e8 4 ??? 0x00000001062734e8 0x0 + 4398200040
( 10.521s) [paraview ] :0 FATL| Signal: SIGSEGV
fish: '/Applications/ParaView-5.8.0-RC…' terminated by signal SIGSEGV (Address boundary error)
```
In VisIt:
![Bildschirmfoto_2020-02-15_um_07.00.15](/uploads/1f4c0da2a9808e34c94bfb136a2765fb/Bildschirmfoto_2020-02-15_um_07.00.15.png)
Maikel
https://gitlab.kitware.com/paraview/paraview/-/issues/19694
directory or filename with mutated vowel fail to load
2020-05-06T22:55:27-04:00
Sassan Ghanai
directory or filename with mutated vowel fail to load
Hi,
since paraview version 5.8 there is no possibility to open directorys or load files with german mutated vowels? It worked with 5.7 though. Is this some unicode error???
keep the good work up:-)
Hi,
since paraview version 5.8 there is no possibility to open directorys or load files with german mutated vowels? It worked with 5.7 though. Is this some unicode error???
keep the good work up:-)
https://gitlab.kitware.com/paraview/paraview/-/issues/19720
Per-cell colored surfaces rendering fails on Intel Iris Plus Graphics
2021-03-24T07:21:03-04:00
Andras Lasso
Per-cell colored surfaces rendering fails on Intel Iris Plus Graphics
When rendering a mesh with coloring using cell data with Intel Iris Plus Graphics, the surface is rendered with randomly changing colored triangles.
This is confirmed in multiple computers, such as:
- Surface Laptop 3: Intel Iris Plus G...
When rendering a mesh with coloring using cell data with Intel Iris Plus Graphics, the surface is rendered with randomly changing colored triangles.
This is confirmed in multiple computers, such as:
- Surface Laptop 3: Intel Iris Plus Graphics driver date 2019-12-21, version 26.20.100.7641
- Surface Pro 7 (model 1866): Intel Iris Plus Graphics driver version 26.20.100.7870.
Screen capture video: https://youtu.be/9UzU8FCALNQ
Test data: https://1drv.ms/u/s!Arm_AFxB9yqHuroxLpY2DfhNA5ppWQ?e=E21iyv
Additional information:
- This is reproducible the same way with multiple VTK-based applications that uses OpenGL2 rendering backend, such as ParaView and 3D Slicer.
- This is not a recent VTK regression, because VTK version about 1-2 years ago has the same issue.
- The legacy OpenGL backend renders correctly.
- Rendering works well on other graphics cards.
- Coloring by point scalars works well.
See discussion at https://discourse.vtk.org/t/rendering-problems-with-per-cell-colored-surfaces-on-surface-7/2698
https://gitlab.kitware.com/paraview/paraview/-/issues/19782
ANL Halo Finder Causes Paraview Crash
2021-03-24T07:28:20-04:00
Nick Thompson
ANL Halo Finder Causes Paraview Crash
![HaloFinderCrash](/uploads/dd2efceb712e4d46ab1baa51852c6fd7/HaloFinderCrash.mov)
Paraview Info:
![Screen_Shot_2020-03-19_at_9.33.26_AM](/uploads/6d61aac1ed25000d7a15e1b9e350f384/Screen_Shot_2020-03-19_at_9.33.26_AM.png)
Also happens ...
![HaloFinderCrash](/uploads/dd2efceb712e4d46ab1baa51852c6fd7/HaloFinderCrash.mov)
Paraview Info:
![Screen_Shot_2020-03-19_at_9.33.26_AM](/uploads/6d61aac1ed25000d7a15e1b9e350f384/Screen_Shot_2020-03-19_at_9.33.26_AM.png)
Also happens with ANL sub-halo finder.
Data attached.
[euler_spiral.vtk](/uploads/3c1fe27cc1c1a4cc62e7405c4039ede8/euler_spiral.vtk)
https://gitlab.kitware.com/paraview/paraview/-/issues/19792
Outline does not overlap with Slice and Volume representations
2022-03-11T13:49:59-05:00
Dan Lipsa
Outline does not overlap with Slice and Volume representations
This happens on both 5.8 release and on master.
Snapshot shows the same data loaded twice, once shown with Outline and once shown with Slice representations.
![misalligned](/uploads/277d20f168ae037031fbb0ef8095d0ac/misalligned.png)
Pa...
This happens on both 5.8 release and on master.
Snapshot shows the same data loaded twice, once shown with Outline and once shown with Slice representations.
![misalligned](/uploads/277d20f168ae037031fbb0ef8095d0ac/misalligned.png)
ParaView State File:
[misalligned.pvsm](/uploads/3b9cc24d7fd6cec4ccecc9c6ba1e34a3/misalligned.pvsm)
Data:
[idFile1.vti](/uploads/13bb8a554be3dd74918cfd0ec80ca451/idFile1.vti)
Seems to be something specific to this file, as other files don't have this problem. Probably with the new Direction attribute of an ImageDataset.
https://gitlab.kitware.com/paraview/paraview/-/issues/19896
Paraview UI does not render `Filters->Alphabetical` dropdown menu correctly o...
2020-07-10T10:07:53-04:00
Amit Singh
Paraview UI does not render `Filters->Alphabetical` dropdown menu correctly on fedora
I filed a bug report for Fedora in [Bugzilla](https://bugzilla.redhat.com/show_bug.cgi?id=1830199). But I was redirected here.
When I use Paraview installed from latest Fedora Workstation Repository, the drop down menu for Filters-> Alp...
I filed a bug report for Fedora in [Bugzilla](https://bugzilla.redhat.com/show_bug.cgi?id=1830199). But I was redirected here.
When I use Paraview installed from latest Fedora Workstation Repository, the drop down menu for Filters-> Alphabetical shows text for the menu-items only in the first column although the menu occupies the whole screen. This does not happen when I use the Paraview binary for the same version from Paraview website. I have attached two GIFs showing the faulty and the correct behaviour. Please see the animations. They explain the issue much better than my paragraph.
Any pointers what build parameter could cause such a glitch?
| Item | Description |
| -----: | ----------: |
| Version | 5.8.0 |
| Qt Version | 5.13.2 |
| OpenGL Vendor | Intel |
| OpenGL Version | 4.6 (Core Profile) Mesa 20.0.6 |
| OpenGL Renderer | Mesa Intel(R) HD Graphics 530 (SKL GT2) |
[FaultyVsExpected.zip](/uploads/29c5a4be6c9bc2171ea259714ada18e7/FaultyVsExpected.zip)
https://gitlab.kitware.com/paraview/paraview/-/issues/19898
VTK errors do not raise or return failure in pvpython
2020-05-07T22:10:08-04:00
Shannon Keough
VTK errors do not raise or return failure in pvpython
I recently discovered an issue in the macOS conda-forge build of Paraview, where the vtkPNGWriter would fail to write due to a libpng mismatch (reported [here](https://github.com/conda-forge/paraview-feedstock/issues/85#event-3303767446)...
I recently discovered an issue in the macOS conda-forge build of Paraview, where the vtkPNGWriter would fail to write due to a libpng mismatch (reported [here](https://github.com/conda-forge/paraview-feedstock/issues/85#event-3303767446)). It seems like that issue has been rectified in that build, but it has highlighted a different bug in Paraview.
My script that failed to write the png exited cleanly as though nothing had gone wrong, with the only evidence being a vtkPNGWriter error on stderr and a missing png file. This seems incorrect.
If the vtk c++ code being called fails and throws an error, that should raise an exception in the python code accordingly, or at the very least return something representing failure. In this case my call to `paraview.simple.SaveScreenshot` returned `True`.
I have tried to follow the code a bit more to see what's happening here but quickly ran into compiled .so's at `servermanager.misc.Screenshot` so I'm all outta juice.
https://gitlab.kitware.com/paraview/paraview/-/issues/19907
We are missing a render
2021-03-24T07:37:38-04:00
W. Alan Scott
We are missing a render
We are missing a render. This is hard to replicate, do EXACTLY as follows:
* master (from about May 1, 2020), local server, Linux.
* Open can.exo. All vars on. Apply.
* Plot over line. Use the on screen icon. Apply.
* Reset session.
...
We are missing a render. This is hard to replicate, do EXACTLY as follows:
* master (from about May 1, 2020), local server, Linux.
* Open can.exo. All vars on. Apply.
* Plot over line. Use the on screen icon. Apply.
* Reset session.
* Open can.exo. All vars on. Apply.
* Plot over line. Use the on screen icon. Apply. I was moving my mouse across the 3d view, I don't think this matters.
Now, you will notice that we have not correctly resized the left viewport. The can, and color legend, looks squished horizontally. This is a bug.
* Step forward one timestep. We will jump to the correct image.
This bug appears to have appeared POST 5.8.0.
@cory.quammen @utkarsh.ayachit Can either of you guys replicate?
https://gitlab.kitware.com/paraview/paraview/-/issues/19909
unable to run paraview 5.8 ( no mpi) on MS window 2016 server
2021-03-24T07:37:08-04:00
peter
unable to run paraview 5.8 ( no mpi) on MS window 2016 server
unable to run paraview 5.8 ( no mpi) on MS window 2016 server.
first getting vcom140.dll missing errors and after install the visul c++ distruction from ms. no getting
![image](/uploads/4ca76d27e26019852997f974cd1bb837/image.png)
unable to run paraview 5.8 ( no mpi) on MS window 2016 server.
first getting vcom140.dll missing errors and after install the visul c++ distruction from ms. no getting
![image](/uploads/4ca76d27e26019852997f974cd1bb837/image.png)
https://gitlab.kitware.com/paraview/paraview/-/issues/19947
10 Tet PointData Rendering Issue
2020-05-28T21:44:46-04:00
Paul Dawson
10 Tet PointData Rendering Issue
[debug_mesh_ebe.vtk](/uploads/6ccc9bd59a44da33051a84b55ca42f8a/debug_mesh_ebe.vtk)
[paraview_plotting_issue.pdf](/uploads/45217546187229e64cfb2a7e7208660c/paraview_plotting_issue.pdf)
[debug_mesh_ebe.vtk](/uploads/6ccc9bd59a44da33051a84b55ca42f8a/debug_mesh_ebe.vtk)
[paraview_plotting_issue.pdf](/uploads/45217546187229e64cfb2a7e7208660c/paraview_plotting_issue.pdf)
https://gitlab.kitware.com/paraview/paraview/-/issues/20063
Need to escape path separator in Save State for CreateTexture function in Win...
2020-07-07T05:11:42-04:00
R-e-M
Need to escape path separator in Save State for CreateTexture function in Windows
In ParaView 5.8.0 on Windows 8.1 64 bit:
1. Create a sphere source
1. Add a "Texture Map To Sphere"
1. Load any *.png file as new texture
1. Save state in python format.
1. Reload this state from a fresh paraview: it crashes.
The proble...
In ParaView 5.8.0 on Windows 8.1 64 bit:
1. Create a sphere source
1. Add a "Texture Map To Sphere"
1. Load any *.png file as new texture
1. Save state in python format.
1. Reload this state from a fresh paraview: it crashes.
The problem is that path separator was not escaped in the CreateTexture function, as it is in readers. We have something like `path\to\texture` instead of `path\\to\\texture`. In my case I had a `\t` in my path read as tab for example.
https://gitlab.kitware.com/paraview/paraview/-/issues/20093
ResampleToImage crashes when memory buffers are too big
2021-03-24T08:18:24-04:00
Jean M. Favre
ResampleToImage crashes when memory buffers are too big
in an attempt to resample a large (10 B cells) rectilinear grid to an Image Data, using ResampleToImage(), I run into crashes due to 'std::bad_alloc'.
Yet, physical memory is not an issue, because as it turns out, I can continue to incre...
in an attempt to resample a large (10 B cells) rectilinear grid to an Image Data, using ResampleToImage(), I run into crashes due to 'std::bad_alloc'.
Yet, physical memory is not an issue, because as it turns out, I can continue to increase the number of pvservers running on the *same* compute nodes, and then above a certain threshold, it just works fine. This had already been suggested to me by @kmorel with the idea that MPI messages are too big.
in the case at hand, I have a mesh of 257*4608*9216 grid points. Using a fixed set of compute nodes (4), ResampletoImage will crash for all jobs with a number of pvservers less than 128. A few questions come to mind:
1) is there a way to do a back-of-the-envelope calculation to find out what is the minimum number of pvserver tasks to allocate?
2) is this dependent on the shape (ratio of dimensions in i,j,k) of the grid as well?
3) could we do this in a streaming fashion with less pvserver tasks?
https://gitlab.kitware.com/paraview/paraview/-/issues/20172
NRRD file support
2021-03-24T08:31:03-04:00
Chris Rorden
NRRD file support
Reposted from [discourse](https://discourse.paraview.org/t/nrrd-file-support/5233):
The [NRRD format specification](http://teem.sourceforge.net/nrrd/format.html#general.2) requires
that `extra whitespace after the field descriptor and b...
Reposted from [discourse](https://discourse.paraview.org/t/nrrd-file-support/5233):
The [NRRD format specification](http://teem.sourceforge.net/nrrd/format.html#general.2) requires
that `extra whitespace after the field descriptor and before the line termination is ignored`. However, the function [ParseVector vtkNrrdReader.cxx](https://github.com/Kitware/VTK/blob/master/IO/Image/vtkNrrdReader.cxx) trims the input string, but does not ignore white space within a string.
Therefore, Paraview will parse the vectors:
space directions: (2.9356703758239746,0,0) (0,2.949852466583252,0) (0,0,2.9361956119537354)
space origin: (-75.762535095214844,-110.76253509521484,-71.762535095214844)
But fail to parse the vectors:
space directions: (2.9356703758239746, 0, 0) (0, 2.949852466583252, 0) (0, 0, 2.9361956119537354)
space origin: (-75.762535095214844, -110.76253509521484, -71.762535095214844)
The user is provided with no feedback regarding an error, but no image is displayed. Careful inspection of the image properties will reveal that the spatial "Bounds" all have a delta of zero (e.g. all voxels collapsed to single point).
Here is a small [example](https://drive.google.com/open?id=1aQ9Q50-eowiVtuR-2OHWE8XtLao3ElbJ) illustrating this issue.
https://gitlab.kitware.com/paraview/paraview/-/issues/20245
Raytracing + Nonlinear Subdivision Level + Surface with Edges draws too many ...
2024-02-21T10:20:56-05:00
GregVernon
Raytracing + Nonlinear Subdivision Level + Surface with Edges draws too many edges
## See attached file which is a sphere meshed with quadratic hex elements.
When showing the element edges (i.e. render as `Surface With Edges`) and increasing the `Nonlinear Subdivision Level` from 0 -> 4, the render facets' edges are b...
## See attached file which is a sphere meshed with quadratic hex elements.
When showing the element edges (i.e. render as `Surface With Edges`) and increasing the `Nonlinear Subdivision Level` from 0 -> 4, the render facets' edges are being drawn when using raytracing.
[sphere_hex27.e](/uploads/e4f75b2e59cf0d9c87e63e169e7c00b5/sphere_hex27.e)
## Here's the correct behavior _when not_ using raytracing, numbered by the value of `Nonlinear Subdivision Level`
0. ![image](/uploads/e189b191235fe552f53ca06a837cfbc5/image.png)
1. ![image](/uploads/3af84765d7b80a4da1f8114c50e6f4fa/image.png)
2. ![image](/uploads/c60c23a80937aa13a4b674e788f801dd/image.png)
3. ![image](/uploads/4682920f126e2cc5a06c880890bdcbce/image.png)
4. ![image](/uploads/566e1c7622e06897c2427d79c8bff37f/image.png)
## And here is the behavior _when using_ raytracing, numbered by the value of `Nonlinear Subdivision Level`
0. ![image](/uploads/82ce8ee28aa474581c7afb98e97d697b/image.png)
1. ![image](/uploads/1bf2763687759f87a15f1bb2f3feb19c/image.png)
2. ![image](/uploads/3b7ab0adf40cd274f47841afa92e9378/image.png)
3. ![image](/uploads/e215818194d82dd69dd432194248d0a0/image.png)
4. ![image](/uploads/0c167c783a84b137662bf40b3f418c41/image.png)
https://gitlab.kitware.com/paraview/paraview/-/issues/20250
Volume Rendering + Log Scale Fails
2023-06-15T11:59:12-04:00
Nick Thompson
Volume Rendering + Log Scale Fails
Volume rendering of rectilinear grids using a log scale fails.
On Linux, the message is:
```
Warning: In /builds/gitlab-kitware-sciviz-ci/source-paraview/VTK/Rendering/VolumeOpenGL2/vtkOpenGLVolumeLookupTable.cxx, line 87
vtkOpenGLVolu...
Volume rendering of rectilinear grids using a log scale fails.
On Linux, the message is:
```
Warning: In /builds/gitlab-kitware-sciviz-ci/source-paraview/VTK/Rendering/VolumeOpenGL2/vtkOpenGLVolumeLookupTable.cxx, line 87
vtkOpenGLVolumeRGBTable (0x1c23ade0): This OpenGL implementation does not support the required texture size of 134217728, falling back to maximum allowed, 32768.This may cause an incorrect lookup table mapping.
```
The render without a log scale is as follows:
![VolumeRender](/uploads/35d75d3533bf820a6d882f1959f34e12/VolumeRender.png)
Log scaling it gives:
![LogScale](/uploads/32602c3fbf3347d82aa434cca9f7c4de/LogScale.png)
I have also "rescaled to custom range" to remove any spurious zeros out of the dataset; no joy, the image is still black.
(I can share the data to reproduce with the assignee, but not with publicly.)
Extra information:
```
$ nvidia-smi
Mon Oct 5 16:10:41 2020
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 440.100 Driver Version: 440.100 CUDA Version: 10.2 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
|===============================+======================+======================|
| 0 GeForce RTX 2070 Off | 00000000:65:00.0 On | N/A |
| 0% 48C P8 2W / 185W | 1379MiB / 7979MiB | 3% Default |
+-------------------------------+----------------------+----------------------+
+-----------------------------------------------------------------------------+
| Processes: GPU Memory |
| GPU PID Type Process name Usage |
|=============================================================================|
| 0 1367 G /usr/lib/xorg/Xorg 40MiB |
| 0 1444 G /usr/bin/gnome-shell 114MiB |
| 0 14427 G /usr/lib/xorg/Xorg 398MiB |
| 0 14564 G /usr/bin/gnome-shell 363MiB |
| 0 30525 G ...Linux-Python3.7-64bit/bin/paraview-real 458MiB |
+-----------------------------------------------------------------------------+
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.4 LTS
Release: 18.04
Codename: bionic
```
The problem appears to be related to the background. If I log-scale with a white background, you can see that my color table is ignored and the image becomes black and white:
![BlackAndWhite](/uploads/2b9bb59cf1c77aed726e4302ebff878c/BlackAndWhite.png)
https://gitlab.kitware.com/paraview/paraview/-/issues/20306
pvpython generated states have empty selections
2021-03-24T08:41:21-04:00
Andreas Naumann
pvpython generated states have empty selections
I generate a selection of (one) point using its id and store the generated state in a state file. With the GUI I get the correct state [extractSelState.pvsm](/uploads/5b19f23c70daf13fbae5ebf0a4e08e69/extractSelState.pvsm) with the select...
I generate a selection of (one) point using its id and store the generated state in a state file. With the GUI I get the correct state [extractSelState.pvsm](/uploads/5b19f23c70daf13fbae5ebf0a4e08e69/extractSelState.pvsm) with the selection containing the point.
At the same time, I traced the selection and obtained the python trace [trace.py](/uploads/75cd05e445603ea35a3a6d623e47b34c/trace.py). If I add the line
```
SaveState('stateFromPython.pvsm')
```
to the end, I get the state file [stateFromPython.pvsm](/uploads/3c246f10f9ebf25b6857262191707997/stateFromPython.pvsm), which have an empty selection. Furthermore the selection does not show the query anymore.
The selection is correctly generated and contains the point. But it is missing in the state file. Is there a **simple** workaround for that? At the moment I use generate a python-programmable filter in the pvpython generated state file, which selects the points by hand.
My paraview and pvpython versions are 5.8.0, where pvpython used the python3.7-64bit backend.
https://gitlab.kitware.com/paraview/paraview/-/issues/20320
Compiling and running paraview with Anaconda
2021-03-24T08:40:17-04:00
Robert Manson-Sawko
Compiling and running paraview with Anaconda
> “We've had enough." He took back the report and jammed it under his arm. "We've had a bellyful, in fact."
"And like everyone who's had enough," said Control as Alleline noisily left the room, "he wants more.”
― John le Carré, _Tinker,...
> “We've had enough." He took back the report and jammed it under his arm. "We've had a bellyful, in fact."
"And like everyone who's had enough," said Control as Alleline noisily left the room, "he wants more.”
― John le Carré, _Tinker, Tailor, Soldier, Spy_
Hello again!
After successfully [compiling version 5.8.1 on ppc64le](https://gitlab.kitware.com/paraview/paraview/-/issues/20316) I am now extending my build to include Python. Now I thought I will be hip and modern and data-science friendly by using anaconda as python provider. I load the correct module, activate `base` environment and it appears that the build runs successfully.
`pvserver` though crashes immediately upon start with the errors below. If you have any experience in building and running paraview with anaconda please let me know. I think this should be possible in principle and I still think I am making some rookie error with `*PATH`s.
```
pvserver: /gpfs/users/shared/apps/core/anaconda/2020.02/lib/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /gpfs/users/shared/apps/mpi/gcc/9.2/openmpi/3.1/paraview-egl/5.8.1/bin/../lib64/libvtkRemotingServerManager-pv5.8.so.1)
pvserver: /gpfs/users/shared/apps/core/anaconda/2020.02/lib/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /gpfs/users/shared/apps/mpi/gcc/9.2/openmpi/3.1/paraview-egl/5.8.1/bin/../lib64/libvtkjsoncpp-pv5.8.so.1)
pvserver: /gpfs/users/shared/apps/core/anaconda/2020.02/lib/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /gpfs/users/shared/apps/mpi/gcc/9.2/openmpi/3.1/paraview-egl/5.8.1/bin/../lib64/libvtkCommonCore-pv5.8.so.1)
pvserver: /gpfs/users/shared/apps/core/anaconda/2020.02/lib/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /gpfs/users/shared/apps/mpi/gcc/9.2/openmpi/3.1/paraview-egl/5.8.1/bin/../lib64/libvtksys-pv5.8.so.1)
pvserver: /gpfs/users/shared/apps/core/anaconda/2020.02/lib/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /gpfs/users/shared/apps/mpi/gcc/9.2/openmpi/3.1/paraview-egl/5.8.1/bin/../lib64/libvtkRemotingServerManagerPython-pv5.8.so.1)
pvserver: /gpfs/users/shared/apps/core/anaconda/2020.02/lib/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /gpfs/users/shared/apps/mpi/gcc/9.2/openmpi/3.1/paraview-egl/5.8.1/bin/../lib64/libvtkIOImport-pv5.8.so.1)
pvserver: /gpfs/users/shared/apps/core/anaconda/2020.02/lib/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /gpfs/users/shared/apps/mpi/gcc/9.2/openmpi/3.1/paraview-egl/5.8.1/bin/../lib64/libvtkIOGeometry-pv5.8.so.1)
pvserver: /gpfs/users/shared/apps/core/anaconda/2020.02/lib/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /gpfs/users/shared/apps/mpi/gcc/9.2/openmpi/3.1/paraview-egl/5.8.1/bin/../lib64/libvtkIOExport-pv5.8.so.1)
pvserver: /gpfs/users/shared/apps/core/anaconda/2020.02/lib/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /gpfs/users/shared/apps/mpi/gcc/9.2/openmpi/3.1/paraview-egl/5.8.1/bin/../lib64/libvtkFiltersParallelDIY2-pv5.8.so.1)
pvserver: /gpfs/users/shared/apps/core/anaconda/2020.02/lib/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /gpfs/users/shared/apps/mpi/gcc/9.2/openmpi/3.1/paraview-egl/5.8.1/bin/../lib64/libvtkAcceleratorsVTKm-pv5.8.so.1)
```
https://gitlab.kitware.com/paraview/paraview/-/issues/20328
pqFlatTreeView hides collapsed items from pipeline
2021-03-24T08:48:24-04:00
Artem Bodrin
pqFlatTreeView hides collapsed items from pipeline
Hello, Developers!
pqFlatTreeView have a major bug with correctly displaying pipeline in certain situations. Video explains a situation and how to reproduce it, some explanation will follow:
![pqFlatTreeView_bug](/uploads/d5e7a8765587de...
Hello, Developers!
pqFlatTreeView have a major bug with correctly displaying pipeline in certain situations. Video explains a situation and how to reproduce it, some explanation will follow:
![pqFlatTreeView_bug](/uploads/d5e7a8765587deb52ca3fbaa23d9c0a0/pqFlatTreeView_bug.mp4)
I have noticed, that if an item travels between tree levels, if "problematic" item was once expanded manually, it does creates tree items in treeview internals and when it becomes a "toplevel" it rolls out kind of successfully.
Here is the place, where item becomes visually unexpandable:
https://gitlab.kitware.com/paraview/paraview/-/blob/master/Qt/Widgets/pqFlatTreeView.cxx#L1384
As a temporary workaround I've made these changes:
![screenshot](/uploads/89eca7dbf08b381313ed3e330b768ea0/screenshot.png)
Not sure if this is correct approach, but pqFlatTreeView is quite complex, it will need a time to understand fully how it functions.
I have to say that pipeline model itself seem intact, because disappeared filters are actually still there, we can see it on rendering view.
Here is a file with a state from video: [pqFlatTreeView_bug.pvsm](/uploads/7ec7bf357c0ba53cb40c119864a1d1f5/pqFlatTreeView_bug.pvsm)
ParaView versions affected: 5.7-5.9rc1, maybe even earlier versions too.
https://gitlab.kitware.com/paraview/paraview/-/issues/20339
Faulty Mollweide Projection in CDI Reader
2021-03-24T08:45:47-04:00
Florian Ziemen
Faulty Mollweide Projection in CDI Reader
The reader has a faulty implementation of the Mollweide projection, and only does one iteration, so data projected with this reader does not align with a map that is remapped with a correct Mollweide projection (e.g. via GDAL).
The term...
The reader has a faulty implementation of the Mollweide projection, and only does one iteration, so data projected with this reader does not align with a map that is remapped with a correct Mollweide projection (e.g. via GDAL).
The term in the cos function of the theta-iteration has to be 2*theta, in the original code, it is only theta (called lat in the code).
The new code is easier to compare with the mathematical description of the mollweide function, and yields maps that line up well with images reprojected using GDAL.
Sea ice thickness data projected with the current CDI reader Mollweide projection does not align with the coast of Southern America, and takes a big bite out of Antarctica when overlain onto a GDAL projected NASA Blue Marble image.
![patagonia](/uploads/e9e4b73a8130f66b1bf74f5dc6b540b9/patagonia.png)
The same data projected with a correct implementation of the projection
![patagonia-fixed](/uploads/1c462d243e03affd23b65f7786f38cf5/patagonia-fixed.png)
I'll provide the patched version of the reader once I have submitted this issue.
Here's the full background image
![Mollweide Projection background image](/uploads/278e448e5ff09fae37405faa6a979eb6/world.200408.3x5400x2700_moll.jpg)
The relevant netcdf
![Ocean model data (subset around Patagonia / Antarctica). ](/uploads/fdf7b2beb7af1883be07786b00e51719/region.nc)
And a state file (links to both files will need updating)
[mollweide-test.pvsm](/uploads/725c60eba109e76e7ff28a1c137aec7f/mollweide-test.pvsm)
https://gitlab.kitware.com/paraview/paraview/-/issues/20342
CDI reader crashes when loading grid with quad cells
2021-03-24T08:45:27-04:00
Florian Ziemen
CDI reader crashes when loading grid with quad cells
The CDI reader crashes paraview when loading a netcdf with grid cells with 4 vertices per cell, because in vtkCDIReader::ConstructGridGeometry() there is one division by 3 instead of dividing by the number of vertices per cell in
[line ...
The CDI reader crashes paraview when loading a netcdf with grid cells with 4 vertices per cell, because in vtkCDIReader::ConstructGridGeometry() there is one division by 3 instead of dividing by the number of vertices per cell in
[line 1730 of the CDIReader plugin](Plugins/CDIReader/Reader/vtkCDIReader.cxx#L1730)
` this->NumberLocalCells = floor(new_cells[0] / 3.0);`
can be fixed by dividing by PointsPerCell
` this->NumberLocalCells = new_cells[0] / this->PointsPerCell;`
The `floor()` can be omitted as this is integer division.
[NetCDF file with a few grid cells that crashes paraview without the bugfix](/uploads/f7ef7158da8e7f40520d3d73577fbf63/1x1.nc)
I'll file a merge request after submitting this issue.
https://gitlab.kitware.com/paraview/paraview/-/issues/20400
v5.9-RC2 No module named 'vtkmodules.vtkFiltersVerdict when compiling the REN...
2021-03-24T08:49:40-04:00
Jean M. Favre
v5.9-RC2 No module named 'vtkmodules.vtkFiltersVerdict when compiling the RENDERING edition
```
from vtk.numpy_interface import algorithms as algs
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/scratch/e1000/jfavre/ParaView5.9/lib64/python3.8/site-packages/vtkmodules/numpy_interface/algorithms...
```
from vtk.numpy_interface import algorithms as algs
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/scratch/e1000/jfavre/ParaView5.9/lib64/python3.8/site-packages/vtkmodules/numpy_interface/algorithms.py", line 20, in <module>
from . import internal_algorithms as algs
File "/scratch/e1000/jfavre/ParaView5.9/lib64/python3.8/site-packages/vtkmodules/numpy_interface/internal_algorithms.py", line 8, in <module>
from vtkmodules.vtkFiltersVerdict import vtkCellSizeFilter, vtkCellQuality, vtkMatrixMathFilter
ModuleNotFoundError: No module named 'vtkmodules.vtkFiltersVerdict'
```
https://gitlab.kitware.com/paraview/paraview/-/issues/20428
v5.9-RC3 SkyBoxBackground rendering with OSMesa gives errors
2021-03-24T08:56:54-04:00
Jean M. Favre
v5.9-RC3 SkyBoxBackground rendering with OSMesa gives errors
I use the following code:
```
tex1 = CreateTexture('model.hdr')
renderView1.BackgroundTexture = tex1
renderView1.UseSkyboxBackground = 1
```
using Mesa 18.3.3 in batch mode,I get the following errors, although the image gets saved corr...
I use the following code:
```
tex1 = CreateTexture('model.hdr')
renderView1.BackgroundTexture = tex1
renderView1.UseSkyboxBackground = 1
```
using Mesa 18.3.3 in batch mode,I get the following errors, although the image gets saved correctly
```
( 76.256s) [pvbatch ]vtkOpenGLFramebufferObj:456 ERR| vtkOpenGLFramebufferObject (0x225506f0): Frame buffer object was not initialized correctly.
Current framebuffer is bind to framebuffer object 8
color attachment 0:
this attachment is a texture with name: 19
its mipmap level is: 0
this is a cube map texture and the image is contained in face 34069
this is a 3D texture and the zoffset of the attached image is 34069
color attachment 1:
this attachment is a texture with name: 19
its mipmap level is: 0
this is a cube map texture and the image is contained in face 34070
this is a 3D texture and the zoffset of the attached image is 34070
color attachment 2:
this attachment is a texture with name: 19
( 76.256s) [pvbatch ]vtkOpenGLFramebufferObj:1376 ERR| vtkOpenGLFramebufferObject (0x225506f0): The framebuffer is incomplete : FRAMEBUFFER_INCOMPLETE_ATTACHMENT
its mipmap level is: 0
```
https://gitlab.kitware.com/paraview/paraview/-/issues/20474
UI warning with empty list
2021-11-16T11:16:45-05:00
JPC
UI warning with empty list
On ParaView 5.9.0 Windows 10 64 bits.
1. Load a CGNS file that only contains point data.
2. Create a _Calculator_ filter and change _Attribute Type_ to _Cell Data_.
3. Try to drop down the _Vectors_ button.
4. The following message is i...
On ParaView 5.9.0 Windows 10 64 bits.
1. Load a CGNS file that only contains point data.
2. Create a _Calculator_ filter and change _Attribute Type_ to _Cell Data_.
3. Try to drop down the _Vectors_ button.
4. The following message is issued:\
**warning: In unknown, line 0
warning: QWindowsWindow::setMouseGrabEnabled: Not setting mouse grab for invisible window QWidgetWindow/'QMenuClassWindow'**
https://gitlab.kitware.com/paraview/paraview/-/issues/20480
Python filter with TemporalShiftScale not working correctly
2021-03-24T09:28:10-04:00
Jacob Merson
Python filter with TemporalShiftScale not working correctly
I see very strange behavior when doing computations with the results from a temporal shift operator. I'm using the temporal shift operator to try to subtract the value of one frame from the next. To do this I apply the temporal shift sca...
I see very strange behavior when doing computations with the results from a temporal shift operator. I'm using the temporal shift operator to try to subtract the value of one frame from the next. To do this I apply the temporal shift scale operator with a scale of 1 and post shift of 1. I then use the following equation in my python filter `inputs[0].PointData["Displacement"]-inputs[1].PointData["Displacement"]`. Where `inputs[0]` should be the original data, and `inputs[1]` should be the shifted data.
When I initially apply the filters I get the expected result. However, if I advance the timestep the data immediately goes to zero. If I reapply the python filter, the numerical values return to the expected result.
https://gitlab.kitware.com/paraview/paraview/-/issues/20486
Paraview-5.9.0 on macOS becomes unresponsive when zooming with data axes
2023-05-23T17:24:24-04:00
Chris Talley
Paraview-5.9.0 on macOS becomes unresponsive when zooming with data axes
OS: macOS High Sierra (10.13)
ParaView Version: 5.9.0
Qt Version: 5.15.1
Zooming in to a data set feature with Data Axes Grid enabled gets progressively slower the more you zoom in while using more memory until you get the spinning whee...
OS: macOS High Sierra (10.13)
ParaView Version: 5.9.0
Qt Version: 5.15.1
Zooming in to a data set feature with Data Axes Grid enabled gets progressively slower the more you zoom in while using more memory until you get the spinning wheel of death. Paraview becomes unresponsive and you must use Force Quit to kill the app. I do not get this problem on version Paraview-5.4.1 on macOS.
My data set consisted of 187500 quad faces read in from a .vtu file. The domain extents were x(-1.687e-5:0.4),y(0:0.102448) with z=0. Paraview became unresponsive when zooming to a rectangle of size approximately 3e-5 while trying to verify a fine geometric feature of the mesh.
https://gitlab.kitware.com/paraview/paraview/-/issues/20497
Wrong fontsize with HiDPI
2021-10-07T03:59:46-04:00
Guanyang Xue
Wrong fontsize with HiDPI
ParaView 5.9.0, macOS 11.2.1 (I believe it happens to all versions)
This is the screenshot of ParaView GUI
![Screen_Shot_2021-02-22_at_3.12.40_PM](/uploads/0f34e6a2a5543eaa95d77a6b725dcc47/Screen_Shot_2021-02-22_at_3.12.40_PM.png)
This ...
ParaView 5.9.0, macOS 11.2.1 (I believe it happens to all versions)
This is the screenshot of ParaView GUI
![Screen_Shot_2021-02-22_at_3.12.40_PM](/uploads/0f34e6a2a5543eaa95d77a6b725dcc47/Screen_Shot_2021-02-22_at_3.12.40_PM.png)
This is the screenshot exported by ParaView
![1234](/uploads/16eae581f135b5af2de51a16cbd941a7/1234.png)
Currently I'm using a 1920x1080 monitor, with 1680x945 HiDPI(87.5%). The output resolution is absolutely wrong
![Screen_Shot_2021-02-22_at_3.23.09_PM](/uploads/6b4bdf6b5ccf3dbc0aa8a0497440c178/Screen_Shot_2021-02-22_at_3.23.09_PM.png)
So I guess Paraview cannot correctly process a non-integer HiDPI scale factor.
https://gitlab.kitware.com/paraview/paraview/-/issues/20523
TimeValues not updating from OpenFoam reader when using Python interface
2021-06-15T17:17:32-04:00
chart3388
TimeValues not updating from OpenFoam reader when using Python interface
Might be related to #20418
TimestepValues are not being updated when using the OpenFOAM Reader via Python Shell. I performed these actions via the Pipeline Browser / Properties panel and always got the correct values back. When I wro...
Might be related to #20418
TimestepValues are not being updated when using the OpenFOAM Reader via Python Shell. I performed these actions via the Pipeline Browser / Properties panel and always got the correct values back. When I wrote a test case, and then just used the trace mechanism you can see the values are not what are expected. Via Pipeline Browser With Skip Zero Time unchecked I get back
> runfoam.TimestepValues
> [0.0, 1.0, 2.0, 3.0, 4.0, 5.0]
![image](/uploads/d5604913cd42d828aa1f7bcb89d53d53/image.png)
With Skip Zero Time checked I get back
> runfoam.TimestepValues
> [1.0, 2.0, 3.0, 4.0, 5.0]
![image](/uploads/d22e0db892994667b8e0bbe6806ff1c7/image.png)
When I do this via python
```python
# trace generated using paraview version 5.9.0
#### import the simple module from the paraview
from paraview.simple import *
#### disable automatic camera reset on 'Show'
paraview.simple._DisableFirstRenderCameraReset()
# create a new 'OpenFOAMReader'
runfoam = OpenFOAMReader(registrationName='run.foam', FileName='/opt/dev/temp/reconstruct/run.foam')
# get animation scene
animationScene1 = GetAnimationScene()
# update animation scene based on data timesteps
animationScene1.UpdateAnimationUsingDataTimeSteps()
# Properties modified on runfoam
runfoam.SkipZeroTime = 0
# get active view
renderView1 = GetActiveViewOrCreate('RenderView')
# show data in view
runfoamDisplay = Show(runfoam, renderView1, 'UnstructuredGridRepresentation')
# trace defaults for the display properties.
runfoamDisplay.Representation = 'Surface'
# reset view to fit data
renderView1.ResetCamera(False)
# show color bar/color legend
runfoamDisplay.SetScalarBarVisibility(renderView1, True)
# update the view to ensure updated data information
renderView1.Update()
# get color transfer function/color map for 'p'
pLUT = GetColorTransferFunction('p')
# get opacity transfer function/opacity map for 'p'
pPWF = GetOpacityTransferFunction('p')
# get TimestepValues
runfoam.TimestepValues
# Properties modified on runfoam
runfoam.SkipZeroTime = 1
# update the view to ensure updated data information
renderView1.Update()
# get TimestepValues
runfoam.TimestepValues
```
TimestepValues comes back the same
> runfoam.TimestepValues
> [1.0, 2.0, 3.0, 4.0, 5.0]
The only way to get the TimestepValues correct is to utilize the pipeline browser and properties panel and force something to expose the apply button to trigger the operation again.
https://gitlab.kitware.com/paraview/paraview/-/issues/20535
Incorrect visualization of large hex meshes
2021-03-24T09:37:05-04:00
Stefan Jakobsson
Incorrect visualization of large hex meshes
For large hex meshes I have had several cases with incorrect visualization. This is exemplified in the screenshot below. The upper left subfigure shows the whole mesh (which should be if cubical shape) where we have some irregularities i...
For large hex meshes I have had several cases with incorrect visualization. This is exemplified in the screenshot below. The upper left subfigure shows the whole mesh (which should be if cubical shape) where we have some irregularities in one of the upper corners. The upper right subfigure shows a view created with the threshold filter where I have extracted 12 rods from the mesh. Here we have many spikes which should not be there. In the lower right subfigure I have extracted the rods myself from the same .xmf and .h5 file but outside paraview, written an new .xmf and .h5 file and imported this into paraview. Now all spikes are gone. ![pv3](/uploads/8a56dd432d83adeef87da57c1dfeac72/pv3.PNG)The mesh has around 11 million cells and 20 million points. For smaller meshes I have not had this problem. I suspect that there are some internal overflow errors causing this problem.
https://gitlab.kitware.com/paraview/paraview/-/issues/20554
Visualization of Line integral convolution on a surface
2021-03-24T09:42:38-04:00
Silvia Escayola
Visualization of Line integral convolution on a surface
Hello!!
I am using the desktop 5.9.0 version for windows and when I try to visualize the LIC representation of magnetic currents using the state file (3D-LIC.pvsm) for opening the *vti and *cml files I get weird results. The images looks...
Hello!!
I am using the desktop 5.9.0 version for windows and when I try to visualize the LIC representation of magnetic currents using the state file (3D-LIC.pvsm) for opening the *vti and *cml files I get weird results. The images looks like broken and I have no idea how to solve the problem. I am sure that the files are not corrupted because the images look fine in onother computer (I attach both, ugly and nice pictures, they don't correspond to the same system but still the difference between the good ones and the "wrong" is visible). I would be very happy if someone can suggest or share any idea on how to solve that.
This is the correctly visualized system (which I could obtain when v. 5.2.0 was working on my pc):
[s_a0](/uploads/375d0544f3736b539dacc7a7388762cb/s_a0.png)
This is the erroneous:
[image__1_](/uploads/97076606fae1020fb60bdc0bb859866a/image__1_.png)
More details: I use the desktop version for windows. I was using v 5.2.0 and it was working fine, but now when I try to open the state file the program crashes completely. My guess is that the last windows update is the source of the problem. Anyway, I tried versions 5.5.2, 5.6.2 and 5.9.0 and all of them can open the state file but then the images look like the ugly plots attached.
Thanks a lot.
[3D-LIC.pvsm](/uploads/55c99809eb0a8dc4e584c953247c43b0/3D-LIC.pvsm)!
[mol-bohr.cml](/uploads/b994c59318543a2725a0538947cc278a/mol-bohr.cml)
[jvec.rar](/uploads/ebf2fa1230b2a40b27cd951d2c9bb8bf/jvec.rar)
https://gitlab.kitware.com/paraview/paraview/-/issues/20597
In case of multiple screen, paraview dialogs pop up on the wrong screen
2022-05-18T13:21:06-04:00
MelanieCarriere
In case of multiple screen, paraview dialogs pop up on the wrong screen
This bug is reproducible on Windows OS (the issue is not on Linux), with multiple screens.
Steps to reproduce the bug :
- Open Paraview 5.9 (on Windows, with at least 2 screens)
- Try to open a dialog ("export spreadsheet", "Open", "Sa...
This bug is reproducible on Windows OS (the issue is not on Linux), with multiple screens.
Steps to reproduce the bug :
- Open Paraview 5.9 (on Windows, with at least 2 screens)
- Try to open a dialog ("export spreadsheet", "Open", "Save State", "Load State", ...)
- The dialog should pop up on the same screen as ParaView, close it
- Move Paraview to the other screen
- Try to re-open the dialog
- The dialog will pop up on the previous screen
https://gitlab.kitware.com/paraview/paraview/-/issues/20608
Non integer powers of 10 cause segfault when finding
2021-04-01T04:22:13-04:00
Lorenzo Bertini
Non integer powers of 10 cause segfault when finding
In the `Edit->Find Data` window, entering a query comparing a column with a value that has a non-integer power of 10 in the form (1e7.5) causes the program to crash by segmentation fault. It seems the program can't handle such values. I ...
In the `Edit->Find Data` window, entering a query comparing a column with a value that has a non-integer power of 10 in the form (1e7.5) causes the program to crash by segmentation fault. It seems the program can't handle such values. I only tested two files, can someone reproduce consistently?
I suggest instead to produce an error message (preferably a window) stating what input values are permitted.
https://gitlab.kitware.com/paraview/paraview/-/issues/20880
Background issues in exported image with headless pvpython
2021-08-10T15:28:46-04:00
Argonaut-J
Background issues in exported image with headless pvpython
When building Paraview (headless) with the non-default options listed below, the following issues occur in some background properties when running a `pvpython` script that exports an image:
1. `Background()` method is ignored, i.e. the...
When building Paraview (headless) with the non-default options listed below, the following issues occur in some background properties when running a `pvpython` script that exports an image:
1. `Background()` method is ignored, i.e. the setting the color of the background does not work.
1. `TransparentBackground=1` parameter in `SaveScreenshot()` is ignored, i.e. background is not exported transparently.
Building Paraview 5.9.1 is done on a Linux Mint Xfce 20.2 machine with installed packages `libosmesa6-dev` `libgl1-mesa-dev` and `libxt-dev`, which succeeds with 116 warnings and no errors, with the following cmake options set:
```
PARAVIEW_USE_PYTHON=ON
PARAVIEW_USE_QT=OFF
PARAVIEW_USE_QTHELP=OFF
PARAVIEW_USE_VTKM=OFF
VTK_USE_X=OFF
VTK_OPENGL_HAS_OSMESA=ON
```
Steps to reproduce:
1. Build paraview with the options above
1. Download the two attached files
1. Run the following code with pvpython (replacing the 2nd and last line if necessary):
```
from paraview.simple import *
xdmf = XDMFReader(FileNames=[online_solution_y.xdmf'])
renderView1 = GetActiveViewOrCreate('RenderView')
xdmfDisplay = Show(xdmf, renderView1)
renderView1.ResetCamera()
renderView1.Background = [0.8333333333333, 0.6666666666666666, 0.0]
renderView1.Update()
SaveScreenshot('image.png', renderView1, ImageResolution=[594, 519], TransparentBackground=0)
```
Now:
1. Check if the background is orange.
1. Set `TransparentBackground=1` in the code above and rerun, check that the background is transparent.
Can you reproduce either non-orange background or non-transparent background or both, in the last two steps?
[online_solution_y.h5](/uploads/c72d4f4d8e7a7a7f4458d0cae4ba9f3b/online_solution_y.h5)
[online_solution_y.xdmf](/uploads/04c2fc1b0c6285fbcf889c5e4544cd50/online_solution_y.xdmf)
https://gitlab.kitware.com/paraview/paraview/-/issues/21532
Animated clip flickering in 5.11 RC 1
2023-06-15T09:38:04-04:00
Nicolas Vuaille
Animated clip flickering in 5.11 RC 1
Steps to reproduce:
* Sphere
* Clip
* AnimationView: add track for Clip1 / Clip type - Offset
* configure track: value go from -1 to 1
* play animation
It happens to have some random flickering. See also attached video.
![animated...
Steps to reproduce:
* Sphere
* Clip
* AnimationView: add track for Clip1 / Clip type - Offset
* configure track: value go from -1 to 1
* play animation
It happens to have some random flickering. See also attached video.
![animatedClipFlicker](/uploads/211fd0334165159aa6d4b7436ee3fc12/animatedClipFlicker.mp4)
Tested on linux with official binaries of 5.11 RC 1. GPU: NVIDIA GeForce RTX 3070 Mobile
Also seen on Windows (off. binaries of RC1 too)
Not able to reproduce on master, nor in my own build of 5.11 RC1
https://gitlab.kitware.com/paraview/paraview/-/issues/21696
Crash using Explicit Structured Grid Slice and Cells Extractor filter (from E...
2023-06-15T10:45:39-04:00
Francois Mazen
Crash using Explicit Structured Grid Slice and Cells Extractor filter (from Explicit Structured Grid ParaView Plugin)
Using Explicit Structured Grid Slice and Cells Extractor filter triggers crashes ParaView (master branch).
Steps to reproduce:
- Load the ExplicitStructuredGrid plugin
- Create Explicit Structured Grid Generator Source, Apply
- Creat...
Using Explicit Structured Grid Slice and Cells Extractor filter triggers crashes ParaView (master branch).
Steps to reproduce:
- Load the ExplicitStructuredGrid plugin
- Create Explicit Structured Grid Generator Source, Apply
- Create Explicit Structured Grid Slice and Cells Extractor, Apply
- Crash!
Call stack (relevant part only):
```
6 0x7fc01708a63d vtkExecutive::CallAlgorithm(vtkInformation*, int, vtkInformationVector**, vtkInformationVector*) + 199
5 0x7fc01708ca36 vtkExplicitStructuredGridAlgorithm::ProcessRequest(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 92
4 0x7fbfd06571f0 vtkExplicitStructuredGridPythonExtractor::RequestData(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 488
3 0x7fc0164a1db7 vtkExplicitStructuredGrid::DeepCopy(vtkDataObject*) + 237
2 0x7fc0163bfbd1 vtkCellArray::DeepCopy(vtkCellArray*) + 129
1 0x7fc01633cdee /home/francois/dev/paraview/build_paraview/bin/../lib/libvtkCommonDataModel-pv5.11.so.1(+0x13cdee) [0x7fc01633cdee]
0 0x7fc01e7a2a00 /usr/lib/libc.so.6(+0x38a00) [0x7fc01e7a2a00]
( 132.129s) [paraview ] :0 FATL| Signal: SIGSEGV
```
Reproduced with master branch. Do not crash with official release 5.11.0, 5.10.1 nor 5.9.1.
https://gitlab.kitware.com/paraview/paraview/-/issues/21697
Loading identical .py state and .pvsm states give inconsistent results
2022-12-14T12:59:12-05:00
Alankar Dutta
Loading identical .py state and .pvsm states give inconsistent results
I’m having a ParaView state saved as .pvsm gives correct position of colorbars and other elements. However, when the same state is stored and loaded as a .py script the colorbars get misplaced. What is the issue? (version: ParaView 5.10....
I’m having a ParaView state saved as .pvsm gives correct position of colorbars and other elements. However, when the same state is stored and loaded as a .py script the colorbars get misplaced. What is the issue? (version: ParaView 5.10.1)
I’m putting in the relevant images.
Loading .pvsm state:
![image](/uploads/f697316d154c68a0ded8584968661408/image.png)
Misplaced colorbars on loading .py state produced at the same time in the GUI:
![image](/uploads/3ce703f37ba4df837afdffce2eb48bab/image.png)
The placement of the colorbars become consistent when the .py script is loaded and generated in ParaView 5.11.0 version compared to the inconsistencies in 5.10.1 version. However, the font sizes are still in-consistent and don’t give identical results. The same happens if I change the orientation axes position (not shown in these images), the python saved state keeps the orientation axes at the default lower left position but the .pvsm file works correctly and puts the orientation axes at the changed location. As a result of the font size inconsistency, parts of the text get cut off at the edges. Also, most likely because of this, same issues happen for Catalyst python states as well. Can someone more experienced in the community help me fix this issue?
Here is the screenshot of what happens on loading the .py state script in ParaView 5.11.0:
![image](/uploads/332b62d3e3627864ecc00e6785e68159/image.png)
Related: https://discourse.paraview.org/t/loading-identical-py-state-and-pvsm-states-give-inconsistent-results/10939
https://gitlab.kitware.com/paraview/paraview/-/issues/21820
ParaView Simple import into Python fails on Linux
2023-03-15T07:04:58-04:00
Cory
ParaView Simple import into Python fails on Linux
When trying to import ```paraview.simple``` into my Python script, I get the following error:
```
Traceback (most recent call last):
File "/home/cory/git-repos/MachLine/dev/helper_scripts/paraview_functions.py", line 3, in <module>
...
When trying to import ```paraview.simple``` into my Python script, I get the following error:
```
Traceback (most recent call last):
File "/home/cory/git-repos/MachLine/dev/helper_scripts/paraview_functions.py", line 3, in <module>
import paraview.simple as pvs
File "/home/cory/Paraview/lib/python3.9/site-packages/paraview/simple.py", line 41, in <module>
from paraview import servermanager
File "/home/cory/Paraview/lib/python3.9/site-packages/paraview/servermanager.py", line 60, in <module>
from paraview.modules.vtkRemotingApplication import *
ImportError: /lib/x86_64-linux-gnu/libp11-kit.so.0: undefined symbol: ffi_type_pointer, version LIBFFI_BASE_7.0
```
I am running Linux Mint 20.2 Cinnamon 64-bit.
https://gitlab.kitware.com/paraview/paraview/-/issues/21836
MPI issue while building Paraview on Mac
2023-03-26T22:08:36-04:00
Muhammad Saad Atique
MPI issue while building Paraview on Mac
I am trying to build Paraview on mac. I ran ninja command and got the following error.
![image](/uploads/a31d77a664d3e0f4775c43cd23950f3c/image.png)
![image](/uploads/5df7829ed5026ab8d90eb7706541b1b5/image.png)
I am trying to build Paraview on mac. I ran ninja command and got the following error.
![image](/uploads/a31d77a664d3e0f4775c43cd23950f3c/image.png)
![image](/uploads/5df7829ed5026ab8d90eb7706541b1b5/image.png)
https://gitlab.kitware.com/paraview/paraview/-/issues/22161
Artefact when rendering with pvbatch and MPI
2023-06-06T04:23:51-04:00
Eve Le Guillou
Artefact when rendering with pvbatch and MPI
Hi all,
I am using Paraview 5.11.0 and MPI 4.0.3.
I noticed a bug in the produced image when I execute the following pipeline:
Wavelet > MaskPoints(GenerateVertices = 1) > SaveScreenShot
Here is the full pipeline with the visuali...
Hi all,
I am using Paraview 5.11.0 and MPI 4.0.3.
I noticed a bug in the produced image when I execute the following pipeline:
Wavelet > MaskPoints(GenerateVertices = 1) > SaveScreenShot
Here is the full pipeline with the visualization details [test.py](/uploads/22433c852033f6932a7178e92ffe2db7/test.py)
Points are shown using the RenderPointsAsSphere option.
When executing the pipeline using the command:
mpirun -n 2 pvbatch test.py
I obtain the following image:
![test](/uploads/bcf02df929f8674d70073fe85180e578/test.jpeg)
Artefacts can be seen on the image. The more processes are used, the more artefacts there are.
The problem doesn't appear when the pipeline is executed using pvserver and the paraview client.
https://gitlab.kitware.com/paraview/paraview/-/issues/22179
Crashing on latest Windows Update
2023-06-15T10:12:20-04:00
lizliv
Crashing on latest Windows Update
The latest forced update on Windows 10 (version 22H2 os build 19045.3086) seems to have broken Paraview, it crashes on opening. I deleted and reinstalled 5.11.0 and 5.11.1 and neither of them are able to open. I tried on two different ma...
The latest forced update on Windows 10 (version 22H2 os build 19045.3086) seems to have broken Paraview, it crashes on opening. I deleted and reinstalled 5.11.0 and 5.11.1 and neither of them are able to open. I tried on two different machines. The RC1 version I have installed through WSL seems to work, not sure how.
https://gitlab.kitware.com/paraview/paraview/-/issues/22386
Color by Scalar broken on Line Width greater 1
2023-12-07T16:35:46-05:00
Johannes Gross
Color by Scalar broken on Line Width greater 1
OS: macOS 13.0
ParaView Version: 5.11.2
Qt Version: 5.15.2
Description
I am trying to show a mass flow in pipes in the appended file.
When setting to Wireframe and using massflow for the color scheme, the flows are displayed fairly cor...
OS: macOS 13.0
ParaView Version: 5.11.2
Qt Version: 5.15.2
Description
I am trying to show a mass flow in pipes in the appended file.
When setting to Wireframe and using massflow for the color scheme, the flows are displayed fairly correct (some pipes do not show the red color although they should) but once the Line Width is set to any number greater 1 the colors are all over the place. Line elements that have value 0 are shown in red, Pipe Elements with higher values are shown in blue. I hope this is not some rookie mistake on my end but the file seems fairly simple and straightforward, could not find any other explanation for the issue. Thank you!
[helloagain2.vtk](/uploads/15fb1563971cc7f65c6a21d91f84f52c/helloagain2.vtk)