I was able to narrow it down by switching off components that were originally also visualized.
Turns out the issue must be related to a lightweight vtk.series
file.
I have assembled a setup that faithfully reproduces the issue also on my GNU/Linux desktop computer when using the normal ParaView-5.12.0-RC1-MPI-Linux-Python3.10-x86_64
version from the download page.
https://datashare.tu-dresden.de/s/obnSfZKxfaJ37xd
The compressed archive contains a file README.md
with a few lines of instructions on how to run/load which ones of the included Paraview session scripts.
Here is the log file I produced with --log=paraview.log,TRACE.
(which is also contained in the archive):
Adding
renderView1 = CreateView('RenderView')
layout1 = CreateLayout(name='Layout #1')
AssignViewToLayout(view=renderView1, layout=layout1, hint=0)
after the ResetSession()
helps, but these lines were not needed with earlier versions of ParaView and the Python trace also does not provide them.
Paraview version 5.12RC1 quits with a segmentation fault after a couple of time steps when iterating over a vtk.series
file.
I have not had this issue with 5.11.
The output I get simply states
error: exception occurred: Segmentation fault
that's all.
A MWE is provided in my response below.
running the following through pvbatch
from paraview.simple import *
renderView1 = GetActiveViewOrCreate('RenderView')
layout1 = GetLayout()
print(layout1)
ResetSession()
renderView1 = GetActiveViewOrCreate('RenderView')
layout1 = GetLayout()
print(layout1)
prints
<paraview.servermanager.ViewLayout object at 0x7f841067ffd0>
None
I am expecting another Viewlayout reference instead of that None in the second line.
This renders ResetSession()
useless for me right now, and I have needed ResetSession()
in the past to mitigate memory leakage issues when iterating over time steps. So I think it is a feature worth having just in case.
Reset Session does not free any memory. Neither when invoking through the GUI (Edit → Reset Session) nor through python. Observed for ParaView 5.12 RC1.
When creating a programmable filter from two inputs with different extents I get the following, very annoying error message.
(5977.475s) [paraview ]vtkStreamingDemandDrive:878 ERR| vtkPVPostFilterExecutive (0x1b7cbb80): The update extent specified in the information for output port 0 on algorithm vtkPVPostFilter(0x7f6488011cf0) is 0 2304 0 127 0 202, which is outside the whole extent 0 0 0 127 0 202.
Within the programmable filter I do take care of the fact that the discretizations of the two inputs don't match and am well aware of the fact that the discretization of the output corresponds to that of the first input.
Here is a very basic example:
# trace generated using paraview version 5.11.1
#import paraview
#paraview.compatibility.major = 5
#paraview.compatibility.minor = 11
from paraview.simple import *
paraview.simple._DisableFirstRenderCameraReset()
renderView1 = GetActiveViewOrCreate('RenderView')
wavelet1 = Wavelet(registrationName='Wavelet1')
wavelet1.WholeExtent = [-10, 10, -10, 10, -10, 10]
wavelet1Display = Show(wavelet1, renderView1, 'UniformGridRepresentation')
wavelet2 = Wavelet(registrationName='Wavelet2')
wavelet2.WholeExtent = [-10, 10, -10, 10, 0, 0]
wavelet2Display = Show(wavelet2, renderView1, 'UniformGridRepresentation')
programmableFilter1 = ProgrammableFilter(registrationName='ProgrammableFilter1', Input=[wavelet1, wavelet2])
programmableFilter1Display = Show(programmableFilter1, renderView1, 'UniformGridRepresentation')
renderView1.Update()
Thanks @berkgeveci,
however, this resolves the issue only for the MWE above where there are two inputs. When configuring the ProgrammableFilter with three and more inputs the message appears again.
# trace generated using paraview version 5.11.1
#import paraview
#paraview.compatibility.major = 5
#paraview.compatibility.minor = 11
from paraview.simple import *
paraview.simple._DisableFirstRenderCameraReset()
renderView1 = GetActiveViewOrCreate('RenderView')
wavelet1 = Wavelet(registrationName='Wavelet1')
wavelet1.WholeExtent = [-10, 10, -10, 10, -10, 10]
wavelet1Display = Show(wavelet1, renderView1, 'UniformGridRepresentation')
wavelet2 = Wavelet(registrationName='Wavelet2')
wavelet2.WholeExtent = [-10, 10, -10, 10, -10, 10]
wavelet2Display = Show(wavelet2, renderView1, 'UniformGridRepresentation')
wavelet3 = Wavelet(registrationName='Wavelet3')
wavelet3.WholeExtent = [-10, 10, -10, 10, 0, 0]
wavelet3Display = Show(wavelet3, renderView1, 'UniformGridRepresentation')
programmableFilter1 = ProgrammableFilter(registrationName='ProgrammableFilter1', Input=[wavelet1, wavelet2, wavelet3])
programmableFilter1.RequestUpdateExtentScript = """# https://discourse.paraview.org/t/vtkpvpostfilterexecutive-0x1e3ecaa0-the-update-extent-specified-in-the-information-for-output-port-0-on-algorithm-vtkpvpostfilter-0x1f196a90/12714/2?u=bastian
SDDP = vtk.vtkStreamingDemandDrivenPipeline
inInfo = self.GetInputInformation(0,1)
extent = inInfo.Get(SDDP.WHOLE_EXTENT())
inInfo.Set(SDDP.UPDATE_EXTENT(), extent, 6)"""
programmableFilter1Display = Show(programmableFilter1, renderView1, 'UniformGridRepresentation')
renderView1.Update()
Produces
( 4.786s) [paraview ]vtkStreamingDemandDrive:874 ERR| vtkPVPostFilterExecutive (0x1b820210): The update extent specified in the information for output port 0 on algorithm vtkPVPostFilter (0x1af977d0) is -10 10 -10 10 -10 10, which is outside the whole extent -10 10 -10 10 0 0.
When creating a programmable filter from two inputs with different extents I get the following, very annoying error message.
(5977.475s) [paraview ]vtkStreamingDemandDrive:878 ERR| vtkPVPostFilterExecutive (0x1b7cbb80): The update extent specified in the information for output port 0 on algorithm vtkPVPostFilter(0x7f6488011cf0) is 0 2304 0 127 0 202, which is outside the whole extent 0 0 0 127 0 202.
Within the programmable filter I do take care of the fact that the discretizations of the two inputs don't match and am well aware of the fact that the discretization of the output corresponds to that of the first input.
Here is a very basic example:
# trace generated using paraview version 5.11.1
#import paraview
#paraview.compatibility.major = 5
#paraview.compatibility.minor = 11
from paraview.simple import *
paraview.simple._DisableFirstRenderCameraReset()
renderView1 = GetActiveViewOrCreate('RenderView')
wavelet1 = Wavelet(registrationName='Wavelet1')
wavelet1.WholeExtent = [-10, 10, -10, 10, -10, 10]
wavelet1Display = Show(wavelet1, renderView1, 'UniformGridRepresentation')
wavelet2 = Wavelet(registrationName='Wavelet2')
wavelet2.WholeExtent = [-10, 10, -10, 10, 0, 0]
wavelet2Display = Show(wavelet2, renderView1, 'UniformGridRepresentation')
programmableFilter1 = ProgrammableFilter(registrationName='ProgrammableFilter1', Input=[wavelet1, wavelet2])
programmableFilter1Display = Show(programmableFilter1, renderView1, 'UniformGridRepresentation')
renderView1.Update()
Any chance this will be fixed by September? Can I use a fixed version if I compile ParaView myself?
Well, this has been around for years and at one point a merge request suggested that the solution was in reach, but to date my visualizations look dull, so dull. It makes me sad every day I look at them.
Discussion: https://discourse.paraview.org/t/different-colors-using-ospray-pathtracer-with-pv-5-9/7282
Merge request: !8577
Please please please do process this request.
Pastel-colored renderings can be nice, too, but I am craving for vibrant colors!
https://discourse.paraview.org/t/different-colors-using-ospray-pathtracer-with-pv-5-9/7282/9
Need some motivation?
(Renderings by https://discourse.paraview.org/u/Lukas)
Here is a small example which will generate an arrow glyph.
pointSource1 = PointSource(registrationName='PointSource1')
glyph1 = Glyph(registrationName='Glyph1', Input=pointSource1, GlyphType='Arrow')
One can modify the glyph properties via GlyphType
, e.g.
glyph1.GlyphType.TipResolution = 32
However, these modifications are not caught by the trace.
No matter what option I choose in the Load State dialog, (be it Use File Name From State, Search files under specified directory, or Choose File Names), the trace will always only read:
LoadState('path/to/state.pvsm')
Whereas it should include options such as
# use data files under a custom directory
LoadState(".....pvsm",
data_directory="/...",
restrict_to_data_directory=True)
# explicitly override files
LoadState(".....pvsm",
filenames=[\
{
'name' : 'can.ex2',
'FileName' : '/..../disk_out_ref.ex2',
},
{
'name' : 'timeseries',
'FileName' : [ '/..../sample_0.vtp',
'/..../sample_1.vtp',
'/..../sample_2.vtp',
'/..../sample_3.vtp',
'/..../sample_4.vtp',
'/..../sample_5.vtp',
'/..../sample_6.vtp',
'/..../sample_7.vtp',
'/..../sample_8.vtp',
'/..../sample_9.vtp',
'/..../sample_10.vtp']
},
])
This used to work in earlier versions of ParaView.
This is the Paraview 5.10.0 MPI release version straight from the download page.
You're welcome.
Personally, I can't think of any situation where this mismatch between the colors on the legend and on the model isn't confusing, so I don't really understand why the default behavior is on.
Oh, surfaces of 3D objects are actually really confusing when not being shaded, i.e. with colors matching the colorbar exactly. You won't be able to tell their shape.
renderView1.UseLight = 0
and renderView1.UseLight = 1
as well as any modifications made to the light kit are also not traced:
https://discourse.paraview.org/t/turn-off-light-kit-through-python/8988
Edit: ah, just noticed that it was already mentioned by the OP.
You may want to look into the parameters Ambient and Diffuse:
https://discourse.paraview.org/t/color-legend-does-not-agree-with-color-displayed-in-data/1716/4
I would like to reduce our data footprint for transient CFD fielddata and therefore intend to write data lossily compressed data.
Since HDF5 does not support the lossy compression algorithms that are actually interesting I found the Adios2 BP4 data files promising. They support both ZFP and SZ compressions, among many others.
Now, the ADIOS2CoreImageReader
(and hopefully also the ADIOS2VTXReader
) actually supports ZFP-compressed data out of the box, which is great, but it fails for SZ-compressed data, stating that Adios2 was compiled without SZ.
Looking at projects/adios2.cmake
in paraview-superbuild I conclude that SZ-support is not yet implemented:
-DADIOS2_USE_SZ:STRING=OFF
-DADIOS2_USE_ZFP:STRING=${zfp_enabled}
Is it feasable to add support for SZ? Are there known caveats that have prevented you from doing it?
I guess one would have to:
projects/sz.cmake
and projects/sz.system.cmake
projects/adios2.cmake
making use of ${sz_enabled}
sz
to CMakeLists.txt
versions.cmake
maybe also:
set(ENABLE_sz ON CACHE BOOL "")
to .gitlab/ci/configure_common.cmake
.gitlab/gitlab-ci-olcf.yml
to include -DENABLE_sz:BOOL=ON
Based on how I currently compile SZ, zlib must also be enabled in order to enable SZ.
For usage in our CFD solver, I currently compile SZ like so:
cmake -DBUILD_FORTRAN=ON \
-DCMAKE_C_COMPILER=$CC \
-DCMAKE_CXX_COMPILER=$CXX \
-DCMAKE_Fortran_COMPILER=$FC \
-DZLIB_ROOT="${ZLIB_ROOT}" \
-DCMAKE_INSTALL_PREFIX:PATH=${SZ_ROOT} ${dir_src}
make
make install
and then Adios2
cmake -DCMAKE_C_COMPILER=$CC \
-DCMAKE_CXX_COMPILER=$CXX \
-DCMAKE_Fortran_COMPILER=$FC \
-DSZ_ROOT=$SZ_ROOT \
-DZFP_ROOT=$ZFP_ROOT \
-DHDF5_ROOT=$HDF5_ROOT \
-DCMAKE_INSTALL_PREFIX:PATH=${ADIOS2_ROOT} \
$dir_src
make -j 16
ctest
make install
I didn't check but the same may be true for view axes grid.
Another improvement for both, data axes grid and view axes grid, would be a way to control the widths of lines (including) tick lines, including the OSPRayUseScaleArray
attribute.
Here is a small demo. Simple box source with View Axes Grid enabled:
paraview --script=session2.py
Check Enable Ray Tracing and all is fine.
Here is a variant with custom tick positions being set:
paraview --script=session1.py
When checking Enable Ray Tracing my PV 5.9.1 crashes.
Stack trace:
48 0x407b2a /soft/ParaView-5.9.1-MPI-Linux-Python3.8-64bit/bin/paraview-real() [0x407b2a]
47 0x7f376c3c00b3 __libc_start_main + 243
46 0x40778a /soft/ParaView-5.9.1-MPI-Linux-Python3.8-64bit/bin/paraview-real() [0x40778a]
45 0x7f3769855120 QCoreApplication::exec() + 128
44 0x7f376984c62a QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 298
43 0x7f373650cdfe /soft/ParaView-5.9.1-MPI-Linux-Python3.8-64bit/plugins/platforms/../../lib/libQt5XcbQpa.so.5(+0x5edfe) [0x7f373650cdfe]
42 0x7f37698a5522 QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 1138
41 0x7f37698a7279 QTimerInfoList::activateTimers() + 985
40 0x7f376984ddd8 QCoreApplication::notifyInternal2(QObject*, QEvent*) + 280
39 0x7f376b80f260 QApplication::notify(QObject*, QEvent*) + 704
38 0x7f376b80818c QApplicationPrivate::notify_helper(QObject*, QEvent*) + 156
37 0x7f376987cccb QObject::event(QEvent*) + 123
36 0x7f3769888c58 QTimer::timerEvent(QTimerEvent*) + 40
35 0x7f3769888927 QTimer::timeout(QTimer::QPrivateSignal) + 39
34 0x7f376987c1ea QMetaObject::activate(QObject*, int, int, void**) + 1850
33 0x7f376a949ec5 /soft/ParaView-5.9.1-MPI-Linux-Python3.8-64bit/bin/../lib/libpqCore-pv5.9.so.1(+0x7bec5) [0x7f376a949ec5]
32 0x7f376aa1b601 pqView::forceRender() + 97
31 0x7f375f91e813 vtkSMViewProxy::StillRender() + 307
30 0x7f3768b1e2e5 vtkPVSessionBase::ExecuteStream(unsigned int, vtkClientServerStream const&, bool) + 53
29 0x7f3768b1f2bb vtkPVSessionCore::ExecuteStream(unsigned int, vtkClientServerStream const&, bool) + 59
28 0x7f3768b1f482 vtkPVSessionCore::ExecuteStreamInternal(vtkClientServerStream const&, bool) + 242
27 0x7f37679d0ddd vtkClientServerInterpreter::ProcessStream(vtkClientServerStream const&) + 29
26 0x7f37679d0b3e vtkClientServerInterpreter::ProcessOneMessage(vtkClientServerStream const&, int) + 1294
25 0x7f37679d040d vtkClientServerInterpreter::ProcessCommandInvoke(vtkClientServerStream const&, int) + 1229
24 0x7f37679cfda9 vtkClientServerInterpreter::CallCommandFunction(char const*, vtkObjectBase*, char const*, vtkClientServerStream const&, vtkClientServerStream&) + 345
23 0x7f37606d2bc8 vtkPVRenderViewCommand(vtkClientServerInterpreter*, vtkObjectBase*, char const*, vtkClientServerStream const&, vtkClientServerStream&, void*) + 8312
22 0x7f375f87cce1 vtkPVRenderView::StillRender() + 97
21 0x7f375f888b3a vtkPVRenderView::Render(bool, bool) + 2010
20 0x7f37669f3d72 vtkGenericOpenGLRenderWindow::Render() + 194
19 0x7f3766a834e1 vtkOpenGLRenderWindow::Render() + 81
18 0x7f3765ff8d8b vtkRenderWindow::Render() + 267
17 0x7f3765ff83f5 vtkRenderWindow::DoStereoRender() + 213
16 0x7f376600a61f vtkRendererCollection::Render() + 191
15 0x7f3766004515 vtkRenderer::Render() + 2533
14 0x7f3766a89c7f vtkOpenGLRenderer::DeviceRender() + 143
13 0x7f37669cae4f vtkCameraPass::Render(vtkRenderState const*) + 527
12 0x7f375e493b48 vtkOSPRayPass::Render(vtkRenderState const*) + 344
11 0x7f37669cae4f vtkCameraPass::Render(vtkRenderState const*) + 527
10 0x7f3766af9212 vtkSequencePass::Render(vtkRenderState const*) + 1522
9 0x7f375e493e88 vtkOSPRayPass::RenderInternal(vtkRenderState const*) + 568
8 0x7f375b874502 vtkViewNode::TraverseAllPasses() + 18
7 0x7f375b8746e6 vtkViewNode::Traverse(int) + 246
6 0x7f375b873f3f vtkRendererNode::Build(bool) + 127
5 0x7f3766002d4f vtkRenderer::GetActors() + 79
4 0x7f375f80a09b vtkGridAxes3DActor::GetActors(vtkPropCollection*) + 139
3 0x7f375f809f91 vtkGridAxes3DActor::UpdateGeometry(vtkViewport*) + 529
2 0x7f375f807ffe vtkGridAxes2DActor::UpdateGeometry(vtkViewport*, bool) + 46
1 0x7f375f806fb4 vtkGridAxes2DActor::UpdateTextActors(vtkViewport*) + 1300
0 0x7f376c3df210 /lib/x86_64-linux-gnu/libc.so.6(+0x46210) [0x7f376c3df210]
( 6.500s) [paraview ] :0 FATL| Signal: SIGSEGV
The same bug is produced by a Data Axes Grid.