ParaView issueshttps://gitlab.kitware.com/paraview/paraview/-/issues2020-05-04T22:46:05-04:00https://gitlab.kitware.com/paraview/paraview/-/issues/19497--geometry-only option is confusing2020-05-04T22:46:05-04:00Mathieu Westphal (Kitware)--geometry-only option is confusingHere is the current descritption of the --geometry-only option :
> For certain "full scene" file formats (gltf/glb and obj), reads only the geometry from the file and use default scene construction instead.
I think this is not great, ...Here is the current descritption of the --geometry-only option :
> For certain "full scene" file formats (gltf/glb and obj), reads only the geometry from the file and use default scene construction instead.
I think this is not great, we may want to force the usage of the "default scene" with --geometry-only even with importers that do not have associated readers.https://gitlab.kitware.com/paraview/paraview/-/issues/19495Tessellation problem with high-order 3d elements2020-01-15T09:16:09-05:00Florian MaurinTessellation problem with high-order 3d elementsThere are some issues with the tessellation of wedge elements.
When using the nonlinear subdivision rendering, the results are perfect (picture of the left).
When using the filter tessellation, there are some small holes in the surface...There are some issues with the tessellation of wedge elements.
When using the nonlinear subdivision rendering, the results are perfect (picture of the left).
When using the filter tessellation, there are some small holes in the surface (picture of the right).
I haven't got such issues yet with the other Lagrange element types.
I have attached the vtu file used to generate these views.
Paraview 5.7.0
Best regards,
Florian
![wedge_lagrange_elements](/uploads/753bc5a7dddd680927d77fd642972e55/wedge_lagrange_elements.png)[wedge_quarter_cylinder.vtu](/uploads/cf19e70823415efb1bc1a48b4c419f8f/wedge_quarter_cylinder.vtu)5.8 (Winter 2020)https://gitlab.kitware.com/paraview/paraview/-/issues/19494Compile failure building mpi4py using OpenMPI 42020-01-05T21:04:46-05:00W. Alan ScottCompile failure building mpi4py using OpenMPI 4Paraview is failing while building mpi4py for VTK's third party libraries using OpenMPI 4. Jeff Mauldin is a contact if more information is needed and for testing.
@ben.boeckel has started working on this here: https://gitlab.kitwar...Paraview is failing while building mpi4py for VTK's third party libraries using OpenMPI 4. Jeff Mauldin is a contact if more information is needed and for testing.
@ben.boeckel has started working on this here: https://gitlab.kitware.com/vtk/vtk/merge_requests/6246.5.8 (Winter 2020)https://gitlab.kitware.com/paraview/paraview/-/issues/19491Python Show() function can create representation different from the one creat...2020-01-14T19:13:58-05:00W. Alan ScottPython Show() function can create representation different from the one created while generating the traceTrace of select cells through is broken. There are possibly multiple issues.
* ParaView master (), builtin server, Linux.
* Tools/ Start trace.
* Open the Watney sparc-wall.exo dataset. All vars on (not needed), Apply.
* Select Cells ...Trace of select cells through is broken. There are possibly multiple issues.
* ParaView master (), builtin server, Linux.
* Tools/ Start trace.
* Open the Watney sparc-wall.exo dataset. All vars on (not needed), Apply.
* Select Cells Through. Select only one cell. Since this skin is only one cell thick, you will only get one cell.
* Extract Selection.
* File/ Save Data. Save as .csv file. Cell Data. All timesteps (not needed).
* Tools/ stop trace. Save this trace somewhere.
* Copy the _0.csv file somewhere else. We want it for comparison.
* Reset session.
* View/ Python Shell/ Run Script. Run our script.
1) We will get an error saying that ScalarOpacityUnitDistance is not a member of extractSelection1Display
2) We will get an error saying that ExtractedBlockIndex is not a member of extractSelection1Display
3) Upon commenting these out, the script will run. Extract Selection is empty, and there is noting in the .csv file.5.8 (Winter 2020)Cory Quammencory.quammen@kitware.comCory Quammencory.quammen@kitware.comhttps://gitlab.kitware.com/paraview/paraview/-/issues/19490Transient(?) OSPRay failure2020-09-28T07:38:17-04:00Ben BoeckelTransient(?) OSPRay failureShows up up `vall` sometimes.
```
vtkDebugLeaks has found no leaks.
pvpython: tpp.c:82: __pthread_tpp_change_priority: Assertion `new_prio == -1 || (new_prio >= fifo_min_prio && new_prio <= fifo_max_prio)' failed.
Loguru caught a signa...Shows up up `vall` sometimes.
```
vtkDebugLeaks has found no leaks.
pvpython: tpp.c:82: __pthread_tpp_change_priority: Assertion `new_prio == -1 || (new_prio >= fifo_min_prio && new_prio <= fifo_max_prio)' failed.
Loguru caught a signal: SIGABRT
Stack trace:
13 0x7efe22610437 /home/kitware/misc/root/ospray-1.8.4/lib64/libospray.so.0(+0x13437) [0x7efe22610437]
12 0x7efe297c9c07 __cxa_finalize + 247
11 0x7efe2261fd6f std::shared_ptr<ospray::api::Device>::~shared_ptr() + 79
10 0x7efe0a6df009 ospray::api::ISPCDevice::~ISPCDevice() + 9
9 0x7efe0a6dee6e ospray::api::ISPCDevice::~ISPCDevice() + 46
8 0x7efe08cdf35e rtcReleaseDevice + 30
7 0x7efe09e745be /home/kitware/misc/root/ospray-1.8.4/lib64/libembree3.so.3(+0x12295be) [0x7efe09e745be]
6 0x7efe244f38f0 /lib64/libpthread.so.0(+0xa8f0) [0x7efe244f38f0]
5 0x7efe244fcc54 /lib64/libpthread.so.0(+0x13c54) [0x7efe244fcc54]
4 0x7efe297bf566 /lib64/libc.so.6(+0x30566) [0x7efe297bf566]
3 0x7efe297b1769 /lib64/libc.so.6(+0x22769) [0x7efe297b1769]
2 0x7efe297b1895 abort + 295
1 0x7efe297c6e75 gsignal + 325
0 0x7efe297c6f00 /lib64/libc.so.6(+0x37f00) [0x7efe297c6f00]
( 1.522s) [main thread ] :0 FATL| Signal: SIGABRT
```
Cc: @utkarsh.ayachit5.9 (Fall 2020)David E. DeMarleDavid E. DeMarlehttps://gitlab.kitware.com/paraview/paraview/-/issues/19488Cannot build in debug configuration on Windows2021-08-24T21:30:38-04:00Keith BallardCannot build in debug configuration on WindowsParaView (5.7.0) fails to build with Python 3 on Windows in Debug configuration. It says it cannot find python37.lib for quite a few projects related to Python wrappers, but the projects all indicate that the proper python37_d.lib is be...ParaView (5.7.0) fails to build with Python 3 on Windows in Debug configuration. It says it cannot find python37.lib for quite a few projects related to Python wrappers, but the projects all indicate that the proper python37_d.lib is being linked. The full linker output looks like:
```
LINK : warning LNK4075: ignoring '/INCREMENTAL' due to '/LTCG' specification
Starting pass 1
Processed /DEFAULTLIB:python37.lib
Processed /DEFAULTLIB:msvcprtd
Processed /DEFAULTLIB:MSVCRTD
Processed /DEFAULTLIB:OLDNAMES
Searching libraries
<... omitted for brevity. TLDR version: it found all the dependent libs given by the link command (including python37_d.lib) ... >
Searching C:\Program Files (x86)\Windows Kits\10\lib\10.0.17763.0\um\x64\kernel32.lib:
Searching C:\Program Files (x86)\Windows Kits\10\lib\10.0.17763.0\um\x64\user32.lib:
Searching C:\Program Files (x86)\Windows Kits\10\lib\10.0.17763.0\um\x64\gdi32.lib:
Searching C:\Program Files (x86)\Windows Kits\10\lib\10.0.17763.0\um\x64\winspool.lib:
Searching C:\Program Files (x86)\Windows Kits\10\lib\10.0.17763.0\um\x64\shell32.lib:
Searching C:\Program Files (x86)\Windows Kits\10\lib\10.0.17763.0\um\x64\ole32.lib:
Searching C:\Program Files (x86)\Windows Kits\10\lib\10.0.17763.0\um\x64\oleaut32.lib:
Searching C:\Program Files (x86)\Windows Kits\10\lib\10.0.17763.0\um\x64\uuid.lib:
Searching C:\Program Files (x86)\Windows Kits\10\lib\10.0.17763.0\um\x64\comdlg32.lib:
Searching C:\Program Files (x86)\Windows Kits\10\lib\10.0.17763.0\um\x64\advapi32.lib:
LINK : fatal error LNK1104: cannot open file 'python37.lib'
```
The link command does not provide this flag. Some how /DEFAULTLIB:python37.lib snuck in here. I did a DUMPBIN command on the object files to see which object had the directive, and it turns out most of the objects had it:
```
Microsoft (R) COFF/PE Dumper Version 14.16.27034.0
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file G:\dev\ParaView-v5.7.0_Build\VTK\Wrapping\PythonCore\WrappingPythonCore.dir\Debug\PyVTKExtras.obj
File Type: COFF OBJECT
SECTION HEADER #1
.drectve name
0 physical address
0 virtual address
132 size of raw data
794 file pointer to raw data (00000794 to 000008C5)
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
100A00 flags
Info
Remove
1 byte align
Linker Directives
-----------------
/FAILIFMISMATCH:_CRT_STDIO_ISO_WIDE_SPECIFIERS=0
/DEFAULTLIB:python37.lib
/FAILIFMISMATCH:_MSC_VER=1900
/FAILIFMISMATCH:_ITERATOR_DEBUG_LEVEL=2
/FAILIFMISMATCH:RuntimeLibrary=MDd_DynamicDebug
/DEFAULTLIB:msvcprtd
/DEFAULTLIB:MSVCRTD
/DEFAULTLIB:OLDNAMES
/EXPORT:PyVTKAddFile_PyVTKExtras
Summary
132 .drectve
```
I could not find a ```#pramga``` call in the code that declared it. Any idea where the ```/DEFAULTLIB:python37.lib``` linker directive is coming from?Jean-Christophe Fillion-RobinJean-Christophe Fillion-Robinhttps://gitlab.kitware.com/paraview/paraview/-/issues/19487MPIEXEC PRe and POSTFLAGS ignored2020-12-16T16:36:24-05:00Jean M. FavreMPIEXEC PRe and POSTFLAGS ignoredI have set
`MPIEXEC_POSTFLAGS:STRING=--oversubscribe
MPIEXEC_PREFLAGS:STRING=--oversubscribe`
but they seem completely ignored in AutoMPI load.I have set
`MPIEXEC_POSTFLAGS:STRING=--oversubscribe
MPIEXEC_PREFLAGS:STRING=--oversubscribe`
but they seem completely ignored in AutoMPI load.Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/paraview/paraview/-/issues/19486Python fails with static ParaView2019-12-12T12:49:51-05:00W. Alan ScottPython fails with static ParaViewPython is now failing with static ParaView. I believe we are also combining all of the Python files into a zip file, but I couldn't find the magic directory that Utkarsh points to:
```python simple <module 'paraview.simple' from '/......Python is now failing with static ParaView. I believe we are also combining all of the Python files into a zip file, but I couldn't find the magic directory that Utkarsh points to:
```python simple <module 'paraview.simple' from '/.../ParaViewBin-static/lib/python3.6/site-packages/_paraview.zip/paraview/simple.py'> ```
This is from bug number #19451.
Bug numer #19451 is probably related to this bug.
Here is how to replicate:
* Build ParaView static. I left everything 3rd party non static.
* NOTE - Non static builds work correctly.
* Linux, master (v5.7.0-789-gb0ea587), remote server.
* View/ Python Shell.
* sphere=Sphere()
```
>>>
Python 3.7.4 (default, Nov 20 2019, 11:53:55)
[GCC 7.3.1 20180303 (Red Hat 7.3.1-5)] on linux
>>> from paraview.simple import *
>>> sphere=Sphere()
Traceback (most recent call last):
File "<console>", line 1, in <module>
NameError: name 'Sphere' is not defined
```5.8 (Winter 2020)Utkarsh AyachitUtkarsh Ayachithttps://gitlab.kitware.com/paraview/paraview/-/issues/19485External Plugin Builds in v5.72020-02-09T23:43:39-05:00Keith BallardExternal Plugin Builds in v5.7While building an external plugin against a pre-built ParaView 5.7, CMake complains that it cannot find paraview_add_plugin.
It seems ```${PARAVIEW_USE_FILE}``` is no set by the config CMake file for ParaView, as of https://gitlab.kitwa...While building an external plugin against a pre-built ParaView 5.7, CMake complains that it cannot find paraview_add_plugin.
It seems ```${PARAVIEW_USE_FILE}``` is no set by the config CMake file for ParaView, as of https://gitlab.kitware.com/paraview/paraview/merge_requests/2971. After reading through paraview-config.cmake.in, it is unclear what should be done in my CMake script to load the necessary CMake functions. I also could not find anything in the documentation.
I can make it work by adding ```include(${_ParaViewPlugin_cmake_dir}/ParaViewPlugin.cmake)``` to my plugin's CMakeLists, but this seems a bit hackish as it is "private" variable. Even when I do this, it brings up other errors since ```_paraview_build_plugin``` is not set. Additionally, there is lines like:
```cmake
# TODO: Support external plugins?
```
in ParaViewPlugin.cmake, leading me to believe external plugin builds are no longer supported? Am I missing something here?5.8 (Winter 2020)Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/paraview/paraview/-/issues/19483ParaView uses too much memory when compiling with make because of VTK-m2020-12-10T11:02:06-05:00Mathieu Westphal (Kitware)ParaView uses too much memory when compiling with make because of VTK-mWhen compiling ParaView, the maximum memory usage is 2Gb by parallel threads, when VTK-m compilation occurs.
This means that on a standard low-end desktop computer, 8 core, 8Gb of RAM, running `make -j 8` will definitely swap and probabl...When compiling ParaView, the maximum memory usage is 2Gb by parallel threads, when VTK-m compilation occurs.
This means that on a standard low-end desktop computer, 8 core, 8Gb of RAM, running `make -j 8` will definitely swap and probably never finish.
Ninja seems to be able to mitigate the issue by monitoring the memory usage I guess.
See the associated issue here : https://gitlab.kitware.com/vtk/vtk-m/issues/438
Until this is resolved, we may want to consider disabling VTK-m by default, unless there is a way to prevent VTK-m to be built in parallel even when the rest of ParaView is.
Any ideas @cory.quammen @utkarsh.ayachit @ben.boeckel ?Robert MaynardRobert Maynardhttps://gitlab.kitware.com/paraview/paraview/-/issues/19482property "python_modules" is not allowed2019-11-20T08:26:50-05:00Julien Schuellerproperty "python_modules" is not allowedCurrent master fails to build when PARAVIEW_ENABLE_PYTHON=ON with the following error:
```
-- Found Eigen3: /usr/include/eigen3 (found version "3.3.4")
CMake Error at VTK/CMake/vtkModuleWrapPython.cmake:1035 (set_property):
INTERFACE_...Current master fails to build when PARAVIEW_ENABLE_PYTHON=ON with the following error:
```
-- Found Eigen3: /usr/include/eigen3 (found version "3.3.4")
CMake Error at VTK/CMake/vtkModuleWrapPython.cmake:1035 (set_property):
INTERFACE_LIBRARY targets may only have whitelisted properties. The
property "python_modules" is not allowed.
Call Stack (most recent call first):
VTK/Web/Python/CMakeLists.txt:17 (vtk_module_add_python_module)
```
It can be reproduced with the following docker script:
```
FROM ubuntu:bionic
RUN apt-get -y update
RUN echo "Europe/Dublin" > /etc/timezone
RUN apt-get install tzdata
RUN dpkg-reconfigure -f noninteractive tzdata
RUN apt-get -y install cmake git sudo wget qttools5-dev lzma-dev libxt-dev libqt5x11extras5-dev qtxmlpatterns5-dev-tools libhdf5-dev python3-dev libnetcdf-dev libglew-dev libexpat-dev libfreetype6-dev libjpeg8-dev libqt5x11extras5-dev libtiff-dev libdouble-conversion-dev liblz4-dev libjsoncpp-dev libeigen3-dev libxml2-dev
ENV QT_SELECT=qt5
RUN cd /usr/local/src && git clone --depth 1 https://gitlab.kitware.com/paraview/paraview.git && cd paraview && git submodule init && git submodule update \
&& mkdir -p build && cd build && cmake \
-DBUILD_SHARED_LIBS=ON \
-DCMAKE_BUILD_TYPE=Release \
-DVTK_USE_64BIT_IDS=OFF \
-DVTK_NO_PYTHON_THREADS=OFF \
-DVTK_PYTHON_FULL_THREADSAFE=ON \
-DPARAVIEW_ENABLE_PYTHON=ON \
-DPYTHON_EXECUTABLE=/usr/bin/python3 \
-DPARAVIEW_ENABLE_EMBEDDED_DOCUMENTATION=OFF \
-DPARAVIEW_USE_EXTERNAL=ON \
-DVTK_MODULE_USE_EXTERNAL_VTK_gl2ps=OFF \
-DVTK_MODULE_USE_EXTERNAL_VTK_libharu=OFF \
-DVTK_MODULE_USE_EXTERNAL_VTK_utf8=OFF \
-DVTK_MODULE_USE_EXTERNAL_VTK_pugixml=OFF \
-DVTK_MODULE_USE_EXTERNAL_ParaView_protobuf=OFF \
-DVTK_MODULE_USE_EXTERNAL_ParaView_cgns=OFF \
-DVTK_BUILD_QT_DESIGNER_PLUGIN:BOOL=OFF \
-DPARAVIEW_USE_VTKM=OFF \
-DPARAVIEW_INSTALL_DEVELOPMENT_FILES:BOOL=ON \
..
```Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/paraview/paraview/-/issues/19481Doesn't work in GNOME with Wayland2020-08-20T13:24:13-04:00Orion PoplawskiDoesn't work in GNOME with WaylandCopy of https://bugzilla.redhat.com/show_bug.cgi?id=1769060
Description of problem:
Attempting to view data in GNOME's Wayland session shows nothing but a large black blob. This occurs with both an AMD GPU and Intel integrated grap...Copy of https://bugzilla.redhat.com/show_bug.cgi?id=1769060
Description of problem:
Attempting to view data in GNOME's Wayland session shows nothing but a large black blob. This occurs with both an AMD GPU and Intel integrated graphics.
Version-Release number of selected component (if applicable):
paraview-5.6.0-7.fc31
How reproducible:
Every time
Steps to Reproduce:
1. Start ParaView
2. Try and visualise a bit of data
Actual results:
See black area or nothing at all
Expected results:
The visualisation
Additional info:
From the message window:
```
rWindow.cxx, line 736
vtkGenericOpenGLRenderWindow (0x558730bf76f0): GLEW could not be initialized.
qt.qpa.wayland: Non-toplevel surfaces can't request window states
qt.qpa.wayland: Non-toplevel surfaces can't request window states
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
ERROR: In /builddir/build/BUILD/ParaView-v5.6.0/VTK/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx, line 736
vtkGenericOpenGLRenderWindow (0x5587345c6930): GLEW could not be initialized.
ERROR: In /builddir/build/BUILD/ParaView-v5.6.0/VTK/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx, line 736
vtkGenericOpenGLRenderWindow (0x5587345c6930): GLEW could not be initialized.
qt.qpa.wayland: Non-toplevel surfaces can't request window states
```5.8 (Winter 2020)Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/paraview/paraview/-/issues/19480The Information Tab for HyperTreeGrids are incorrect2020-07-27T18:59:52-04:00Boonthanome NouanesengsyThe Information Tab for HyperTreeGrids are incorrectWe have a dataset that is a multiblock dataset that has two blocks. The first block is the mesh, and can be loaded as either HTG or unstructured grid (UG). The second block has some tracer data.
The problem is that when loading as HTG, ...We have a dataset that is a multiblock dataset that has two blocks. The first block is the mesh, and can be loaded as either HTG or unstructured grid (UG). The second block has some tracer data.
The problem is that when loading as HTG, the Information tab will load variables and ranges for the second block. This is for when "Multi-block Dataset" is highlighted in the Data Hierarchy box. Ordinarily, when "Multi-block Dataset" is highlighted, the information for the first block in the dataset is shown. This is the case when the data is loaded as UG, the Information tab shows data about the first block.
At first I thought the ranges for HTG were just wrong, but if you click on "Hyper-tree Grid" below "Multi-block Dataset" in the Data Hierarchy box, then you see the correct values.
So in summary: When loading data as HTG, the data in the Information tab is not what you expect, and it's confusing. Is that the responsibility of the reader? Or something in the GUI?
Dataset I'm talking about: [todd2_small.tar.gz](/uploads/6003ad269de7e1d49d423e2f556fc7c1/todd2_small.tar.gz).
Below are screenshots. The first one shows what loading as HTG looks like, and the second one shows what it looks like when UG is loaded. Notice the different ranges for the variable tev.
![htg](/uploads/7ccc2a93fc91c08dc8201041132c431a/htg.png)
![ug](/uploads/697ba8228a76f20e8ba7e0f3ebae9deb/ug.png)
Old Description -- ignore stuff below this line
We have come across a problem where the Information Tab will not show correct ranges for variables for HyperTreeGrids. @patchett2002 @demarle From an email from Pat Fasel:
> The problem with HTG is that the geometry and data is stored by HyperTree. The reason for that is within a parallel HyperTreeGrid, complete HyperTrees must stay together. So the reader and writer deal with things in units.
>
> In the todd problem which is 12 x 2 x 2 there are 48 HyperTrees and so 48 DataArrays of "tev" and 48 ranges. So if you examine all 48 you will find the correct min and max as it appears in the UnstructuredGrid, but in different HyperTrees.5.9 (Fall 2020)Yohann Bearzi (Kitware)Yohann Bearzi (Kitware)https://gitlab.kitware.com/paraview/paraview/-/issues/19479Filter "Tessellate" not updated when "File->Reload Files"2020-01-14T20:23:03-05:00Florian MaurinFilter "Tessellate" not updated when "File->Reload Files"Let say that I have a file "geom.vtu" (it could be whatever geometry)
I open it with Paraview, and then I create a filter "Warp By Vector"
Now let say that outside Paraview, I am doing some changes to the file "geom.vtu".
When I am doing...Let say that I have a file "geom.vtu" (it could be whatever geometry)
I open it with Paraview, and then I create a filter "Warp By Vector"
Now let say that outside Paraview, I am doing some changes to the file "geom.vtu".
When I am doing "File->Reload Files (F5)", the results of my filter "Warp By Vector" are updated with the new geometry.
Now if I am doing the same with the filter "Tessellate", the geometry of the filter "Tessellate" is not updated.
To get it updated, I have to delete the filter and create a new one, which is not convenient since we are back to the default parameters of the filter.
It is not a major issue, but things would be more convenient once fixed.
Best
Florianhttps://gitlab.kitware.com/paraview/paraview/-/issues/19478Master has debug prints remote server.2021-11-08T21:02:44-05:00W. Alan ScottMaster has debug prints remote server.Master is putting out debug prints remote server. I think it was also crashing, but after deleting my configuratin files, and rebuilding, I no longer see the crash. Could be I was fooling myself, thinking there was a crash, but just ge...Master is putting out debug prints remote server. I think it was also crashing, but after deleting my configuratin files, and rebuilding, I no longer see the crash. Could be I was fooling myself, thinking there was a crash, but just get lots of warning verbiage. Here is how to replicate:
* Master (), Linux, remote server. I am using 16 ranks, but I bet it happens with 1 or 2.
* Edit/ Settings/ Render View/ Remote Render Threshold == 0. OK.
* Now, kill and restart ParaView. You will see the following warning (the full version was sent to Ken Martin, and Kitware):
* This error will occur any time you redraw the main window, such as moving the Output Messages window to the side.
* Also happens if you run Sources/ Wavelet/ Apply.
This is a showstopper for Watney development.
```
12.726s) [paraview ] vtkOutputWindow.cxx:86 WARN| Generic Warning: In /snip/VTK/Rendering/OpenGL2/vtkOpenGLState.cxx, line 229
Error in cache state for GL_DRAW_BUFFER got 1028 expected1026
( 12.755s) [paraview ] vtkOutputWindow.cxx:86 WARN| Generic Warning: In /snip/VTK/Rendering/OpenGL2/vtkOpenGLState.cxx, line 275
at stack loc
0x2aaab427f81f : ??? [(???) ???:-1]
0x2aaab427a922 : vtksys::SystemInformation::GetProgramStack(int, int) [(libvtksys-pv5.7.so.1) ???:-1]
0x2aaac454f3f4 : vtkOpenGLState::CheckState() [(libvtkRenderingOpenGL2-pv5.7.so.1) ???:-1]
0x2aaac455042a : vtkOpenGLState::vtkBindFramebuffer(unsigned int, vtkOpenGLFramebufferObject*) [(libvtkRenderingOpenGL2-pv5.7.so.1) ???:-1]
0x2aaac449da50 : vtkOpenGLFramebufferObject::Bind(unsigned int) [(libvtkRenderingOpenGL2-pv5.7.so.1) ???:-1]
0x2aaac449d9fd : vtkOpenGLFramebufferObject::Bind() [(libvtkRenderingOpenGL2-pv5.7.so.1) ???:-1]
0x2aaac44a1b6d : vtkOpenGLFramebufferObject::PopulateFramebuffer(int, int, bool, int, int, bool, int, int, bool) [(libvtkRenderingOpenGL2-pv5.7.so.1) ???:-1]
0x2aaac452f5cb : vtkOpenGLRenderWindow::CreateOffScreenFramebuffer(int, int) [(libvtkRenderingOpenGL2-pv5.7.so.1) ???:-1]
0x2aaac452cb9d : vtkOpenGLRenderWindow::Start() [(libvtkRenderingOpenGL2-pv5.7.so.1) ???:-1]
0x2aaac82cf03b : vtkRenderWindow::DoStereoRender() [(libvtkRenderingCore-pv5.7.so.1) ???:-1]
0x2aaac82cef32 : vtkRenderWindow::Render() [(libvtkRenderingCore-pv5.7.so.1) ???:-1]
0x2aaac45302c7 : vtkOpenGLRenderWindow::Render() [(libvtkRenderingOpenGL2-pv5.7.so.1) ???:-1]
0x2aaab769bf11 : vtkPVProcessWindow::PrepareForRendering() [(libvtkPVClientServerCoreRendering-pv5.7.so.1) ???:-1]
0x2aaab76c9b98 : ??? [(???) ???:-1]
0x2aaab76b0a7f : vtkPVRenderView::Render(bool, bool) [(libvtkPVClientServerCoreRendering-pv5.7.so.1) ???:-1]
0x2aaab76afbbd : vtkPVRenderView::StillRender() [(libvtkPVClientServerCoreRendering-pv5.7.so.1) ???:-1]
0x2aaaab32926c : ??? [(???) ???:-1]
0x2aaaad971199 : vtkClientServerInterpreter::CallCommandFunction(char const*, vtkObjectBase*, char const*, vtkClientServerStream const&, vtkClientServerStream&) [(libvtkClientServer-pv5.7.so.1) ???:-1]
0x2aaaad96f91f : vtkClientServerInterpreter::ProcessCommandInvoke(vtkClientServerStream const&, int) [(libvtkClientServer-pv5.7.so.1) ???:-1]
0x2aaaad96ef4f : vtkClientServerInterpreter::ProcessOneMessage(vtkClientServerStream const&, int) [(libvtkClientServer-pv5.7.so.1) ???:-1]
0x2aaaad96edfd : vtkClientServerInterpreter::ProcessStream(vtkClientServerStream const&) [(libvtkClientServer-pv5.7.so.1) ???:-1]
0x2aaaace2b332 : vtkPVSessionCore::ExecuteStreamInternal(vtkClientServerStream const&, bool) [(libvtkPVServerImplementationCore-pv5.7.so.1) ???:-1]
0x2aaaace2b138 : vtkPVSessionCore::ExecuteStream(unsigned int, vtkClientServerStream const&, bool) [(libvtkPVServerImplementationCore-pv5.7.so.1) ???:-1]
0x2aaaace27b2e : vtkPVSessionBase::ExecuteStream(unsigned int, vtkClientServerStream const&, bool) [(libvtkPVServerImplementationCore-pv5.7.so.1) ???:-1]
0x2aaaace37baa : vtkPVSessionServer::OnClientServerMessageRMI(void*, int) [(libvtkPVServerImplementationCore-pv5.7.so.1) ???:-1]
0x2aaaace36902 : ??? [(???) ???:-1]
0x2aaab1175186 : vtkMultiProcessController::ProcessRMI(int, void*, int, int) [(libvtkParallelCore-pv5.7.so.1) ???:-1]
0x2aaab1174d9b : vtkMultiProcessController::ProcessRMIs(int, int) [(libvtkParallelCore-pv5.7.so.1) ???:-1]
0x2aaaad1fcd7d : vtkTCPNetworkAccessManager::ProcessEventsInternal(unsigned long, bool) [(libvtkPVClientServerCoreCore-pv5.7.so.1) ???:-1]
0x2aaaad1fc90e : vtkTCPNetworkAccessManager::ProcessEvents(unsigned long) [(libvtkPVClientServerCoreCore-pv5.7.so.1) ???:-1]
0x401a0a : ??? [(???) ???:-1]
0x401acc : ??? [(???) ???:-1]
0x2aaaaacf1545 : __libc_start_main [(libc.so.6) ???:-1]
0x401609 : ??? [(???) ???:-1]
```5.10 (Fall 2021)Yohann Bearzi (Kitware)Yohann Bearzi (Kitware)https://gitlab.kitware.com/paraview/paraview/-/issues/19477Paraview 5.7 fails to build with openmpi on Fedora Rawhide2019-11-20T09:02:32-05:00Orion PoplawskiParaview 5.7 fails to build with openmpi on Fedora RawhideTrying to update the Fedora paraview package to 5.7. Getting the following:
```
[ 97%] Linking CXX executable ../bin/pvserver
cd /builddir/build/BUILD/ParaView-v5.7.0/s390x-redhat-linux-gnu-openmpi/CommandLineExecutables && /usr/bin/cma...Trying to update the Fedora paraview package to 5.7. Getting the following:
```
[ 97%] Linking CXX executable ../bin/pvserver
cd /builddir/build/BUILD/ParaView-v5.7.0/s390x-redhat-linux-gnu-openmpi/CommandLineExecutables && /usr/bin/cmake -E cmake_link_script CMakeFiles/pvserver.dir/link.txt --verbose=1
/usr/bin/c++ -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=zEC12 -mtune=z13 -fasynchronous-unwind-tables -fstack-clash-protection -O2 -g -DNDEBUG -Wl,-lc -Wl,-lc -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld CMakeFiles/pvserver.dir/pvserver.cxx.o -o ../bin/pvserver -Wl,-rpath,"\$ORIGIN/../lib64:/usr/lib64/openmpi/lib:" ../lib64/libvtkPVServerManagerApplication-pv5.7.so.5.7 ../lib64/libvtkUtilitiesPythonInitializer-pv5.7.so.5.7 ../lib64/libvtkPVServerManagerCore-pv5.7.so.5.7 ../lib64/libvtkPVServerImplementationCore-pv5.7.so.5.7 ../lib64/libvtkPVClientServerCoreCore-pv5.7.so.5.7 ../lib64/libvtkPVVTKExtensionsCore-pv5.7.so.5.7 ../lib64/libvtkPVCore-pv5.7.so.5.7 ../lib64/libvtkClientServer-pv5.7.so.5.7 ../lib64/libvtkPythonInterpreter-pv5.7.so.5.7 ../lib64/libvtkIOXMLParser-pv5.7.so.5.7 ../lib64/libvtkIOImage-pv5.7.so.5.7 ../lib64/libvtkPVVTKExtensionsSIL-pv5.7.so.5.7 ../lib64/libvtkFiltersParallel-pv5.7.so.5.7 ../lib64/libvtkFiltersExtraction-pv5.7.so.5.7 ../lib64/libvtkFiltersModeling-pv5.7.so.5.7 ../lib64/libvtkFiltersSources-pv5.7.so.5.7 ../lib64/libvtkFiltersGeneral-pv5.7.so.5.7 ../lib64/libvtkFiltersGeometry-pv5.7.so.5.7 ../lib64/libvtkFiltersCore-pv5.7.so.5.7 ../lib64/libvtkParallelCore-pv5.7.so.5.7 ../lib64/libvtkIOLegacy-pv5.7.so.5.7 ../lib64/libvtkIOCore-pv5.7.so.5.7 /usr/lib64/libprotobuf.so /usr/lib64/libjsoncpp.so ../lib64/libvtkCommonExecutionModel-pv5.7.so.5.7 ../lib64/libvtkCommonDataModel-pv5.7.so.5.7 ../lib64/libvtkCommonSystem-pv5.7.so.5.7 ../lib64/libvtkCommonMisc-pv5.7.so.5.7 ../lib64/libvtkCommonTransforms-pv5.7.so.5.7 ../lib64/libvtkCommonMath-pv5.7.so.5.7 ../lib64/libvtkCommonCore-pv5.7.so.5.7 -lpthread /usr/lib64/libpython3.8.so ../lib64/libvtksys-pv5.7.so.5.7 -ldl -Wl,-rpath-link,/builddir/build/BUILD/ParaView-v5.7.0/s390x-redhat-linux-gnu-openmpi/lib64:/usr/lib64/openmpi/lib
make[2]: Leaving directory '/builddir/build/BUILD/ParaView-v5.7.0/s390x-redhat-linux-gnu-openmpi'
/usr/bin/ld: /builddir/build/BUILD/ParaView-v5.7.0/s390x-redhat-linux-gnu-openmpi/lib64/libvtkIOXdmf2-pv5.7.so.1: undefined reference to `ompi_mpi_cxx_op_intercept'
/usr/bin/ld: /builddir/build/BUILD/ParaView-v5.7.0/s390x-redhat-linux-gnu-openmpi/lib64/libvtkIOXdmf2-pv5.7.so.1: undefined reference to `MPI::Win::Free()'
/usr/bin/ld: /builddir/build/BUILD/ParaView-v5.7.0/s390x-redhat-linux-gnu-openmpi/lib64/libvtkIOXdmf2-pv5.7.so.1: undefined reference to `MPI::Datatype::Free()'
/usr/bin/ld: /builddir/build/BUILD/ParaView-v5.7.0/s390x-redhat-linux-gnu-openmpi/lib64/libvtkIOXdmf2-pv5.7.so.1: undefined reference to `MPI::Comm::Comm()'
collect2: error: ld returned 1 exit status
make[2]: *** [CommandLineExecutables/CMakeFiles/pvserver.dir/build.make:120: bin/pvserver] Error 1
```
Full log: https://kojipkgs.fedoraproject.org//work/tasks/1379/39091379/build.log. See this on all arches.Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/paraview/paraview/-/issues/19474versioned docs are broken2020-02-03T12:09:39-05:00Utkarsh Ayachitversioned docs are brokenGo to https://kitware.github.io/paraview-docs/nightly/cxx/:
Issues:
* [ ] `nightly (development)`: docs seem ancient! haven't updated in a while. why? how do we avoid that from happening in the future?
* [ ] `latest release (5.7.*)`: d...Go to https://kitware.github.io/paraview-docs/nightly/cxx/:
Issues:
* [ ] `nightly (development)`: docs seem ancient! haven't updated in a while. why? how do we avoid that from happening in the future?
* [ ] `latest release (5.7.*)`: docs seem obsolete. point to 5.7.0-RC2, and not the actual release. why? how do we avoid that from happening in the future?
* [ ] `previous release (5.6.1)`: link broken
* [ ] `v5.6.0`: link broken
* [ ] `v5.5.2`: link works as expected5.8 (Winter 2020)https://gitlab.kitware.com/paraview/paraview/-/issues/19473Add dashboard for new python zip package2020-01-07T20:05:12-05:00W. Alan ScottAdd dashboard for new python zip packagePlease add a dashboard for the new python packaging in a zip file. This should be how we test static builds.
Related to #19451 and #19048Please add a dashboard for the new python packaging in a zip file. This should be how we test static builds.
Related to #19451 and #190485.9 (Fall 2020)Utkarsh AyachitUtkarsh Ayachithttps://gitlab.kitware.com/paraview/paraview/-/issues/19470Document how to migrate plugins for release 5.72020-02-09T23:42:20-05:00Jakub KlinkovskýDocument how to migrate plugins for release 5.7The release 5.7 brings many backwards incompatible changes to the plugin system, starting with missing `ParaViewConfig.cmake` and `UseParaView.cmake` files, which were used by plugins in older versions. Although there seems to be [docume...The release 5.7 brings many backwards incompatible changes to the plugin system, starting with missing `ParaViewConfig.cmake` and `UseParaView.cmake` files, which were used by plugins in older versions. Although there seems to be [documentation which is up-to-date](https://kitware.github.io/paraview-docs/latest/cxx/PluginHowto.html), there is no indication of the recent changes. Moreover, an older version of the page does not seem to be available, so users can't even try to figure out the differences themselves.
Please provide a proper migration guide.5.8 (Winter 2020)Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/paraview/paraview/-/issues/19468Shared library error when building external plugin2019-11-18T10:17:31-05:00Charles GueunetShared library error when building external pluginI am trying to build an external plugin using an installed ParaView master (00074fbc7de29c2ab2f1b90624e07d1af53484ee). This paraview is installed in my home folder (not in `/usr/local`). During the build of the plugin, I have the followi...I am trying to build an external plugin using an installed ParaView master (00074fbc7de29c2ab2f1b90624e07d1af53484ee). This paraview is installed in my home folder (not in `/usr/local`). During the build of the plugin, I have the following error:
```
/home/charles/Software/install/paraview/bin/vtkWrapHierarchy-pv5.7: error while loading shared libraries: libvtkWrappingTools-pv5.7.so.1: cannot open shared object file: No such file or directory
```
Adding the `.../install/paraview/lib/` folder in my `LD_LIBRARY_PATH` solve the issue.
I think the rpath of the `vtkWrapHierarchy` executable is broken when installing ParaView:
```
$ ldd install/paraview/bin/vtkWrapHierarchy-pv5.7
linux-vdso.so.1 (0x00007fff07071000)
libc.so.6 => /usr/lib/libc.so.6 (0x000014ba9bd5a000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x000014ba9bf63000)
libvtkWrappingTools-pv5.7.so.1 => not found
```
@mwestphal @ben.boeckel 5.8 (Winter 2020)Ben BoeckelBen Boeckel