ParaView issueshttps://gitlab.kitware.com/paraview/paraview/-/issues2023-09-25T10:10:08-04:00https://gitlab.kitware.com/paraview/paraview/-/issues/22307Build Dependencies for Ubuntu 22.04 LTS2023-09-25T10:10:08-04:00Jonathan HodgesBuild Dependencies for Ubuntu 22.04 LTSBuild instructions for Paraview are based on Ubuntu 18.04 LTS. qt5-default is no longer available in newer Ubuntus. In Ubuntu 22.04 LTS I needed to replace it with the following (new packages at the end):
sudo apt-get install git cmake ...Build instructions for Paraview are based on Ubuntu 18.04 LTS. qt5-default is no longer available in newer Ubuntus. In Ubuntu 22.04 LTS I needed to replace it with the following (new packages at the end):
sudo apt-get install git cmake build-essential libgl1-mesa-dev libxt-dev libqt5x11extras5-dev libqt5help5 qttools5-dev qtxmlpatterns5-dev-tools libqt5svg5-dev python3-dev python3-numpy libopenmpi-dev libtbb-dev ninja-build qtbase5-dev qtchooser qt5-qmake qtbase5-dev-toolshttps://gitlab.kitware.com/paraview/paraview/-/issues/22305Color maps for multiple representations in single pqRenderView in custom appl...2023-09-27T08:52:11-04:00Pietersielie PColor maps for multiple representations in single pqRenderView in custom application remain synchronised even when "UseSeparateColorMap" property is trueI have a custom Paraview client application that is used to display astronomical data (with the data living on a standard `pvserver` instance). As part of it, I display multiple 2D images in the same renderview (an instance of `pqRenderV...I have a custom Paraview client application that is used to display astronomical data (with the data living on a standard `pvserver` instance). As part of it, I display multiple 2D images in the same renderview (an instance of `pqRenderView*`). The images are loaded and controlled through a container class that owns the object and redirects commands to the proxies. The images are all instantiated and loaded separately, to make sure that arbitrary numbers of images can be loaded.
Here is a snippet from the container class header to define some of the variables referred to later on:
```
vtkSMSessionProxyManager* serverProxyManager;
pqObjectBuilder* builder;
pqPipelineSource* imageSource;
pqDataRepresentation* imageRep;
vtkSMProxy* imageProxy;
vtkSMTransferFunctionProxy* lutProxy;
pqRenderView* viewImage;
```
The renderview and objectBuilder are passed through from the class that initialises the server connection, creates the view, and governs the user interaction. It keeps a vector array of the container class that controls the images.
The images are created as follows:
```
QString filename;
imageSource = pqLoadDataReaction::loadData({ filename });
imageRep = builder->createDataRepresentation(this->imageSource->getOutputPort(0), viewImage);
imageProxy = imageRep->getProxy();
vtkSMPropertyHelper(imageProxy, "Representation").Set("Slice");
auto separateProperty = vtkSMPVRepresentationProxy::SafeDownCast(imageProxy)->GetProperty("UseSeparateColorMap");
vtkSMPropertyHelper(separateProperty).Set(1);
vtkSMPVRepresentationProxy::SetScalarColoring(imageProxy, "FITSImage", vtkDataObject::POINT);
imageProxy->UpdateVTKObjects();
```
The colour map for each image is initialised by the following:
```
vtkNew<vtkSMTransferFunctionManager> mgr;
lutProxy = vtkSMTransferFunctionProxy::SafeDownCast(mgr->GetColorTransferFunction("FITSImage", imageProxy->GetSessionProxyManager()));
```
When the user changes the colour map, this is what I use to change the colour map:
```
if (vtkSMProperty *lutProperty = imageProxy->GetProperty("LookupTable")) {
auto presets = vtkSMTransferFunctionPresets::GetInstance();
lutProxy->ApplyPreset(presets->GetFirstPresetWithName(name.toStdString().c_str()));
vtkSMPropertyHelper(lutProperty).Set(lutProxy);
lutProxy->UpdateVTKObjects();
vtkSMPVRepresentationProxy::RescaleTransferFunctionToDataRange(imageProxy, false, false);
vtkSMPVRepresentationProxy::SetScalarBarVisibility(imageProxy, viewImage->getProxy(), true);
imageProxy->UpdateVTKObjects();
this->colourMap = name;
return 1;
}
```
If the user chooses to select log scale, that is changed by this snippet:
```
if (auto logProperty = lutProxy->GetProperty("UseLogScale"))
{
double range[2];
vtkSMTransferFunctionProxy::GetRange(lutProxy, range);
vtkSMCoreUtilities::AdjustRangeForLog(range);
this->logScale = true;
vtkSMTransferFunctionProxy::RescaleTransferFunction(lutProxy, range);
vtkSMPropertyHelper(logProperty).Set(1);
changeColorMap(this->getColourMap());
lutProxy->UpdateVTKObjects();
imageProxy->UpdateVTKObjects();
return 1;
}
```
For some reason, if I just change the log scaling property, the actual colour map resets to the default, which is why I change the colour map again after setting the scaling property.
Each image is initialised separately and added to the pqRenderView. However, despite setting the “UseSeparateColorMap” property to true on initialising the image, all the images in the renderview has their colour maps synchronised. If any of the images have their colour maps changed, all the others will follow suit.
I have tested the value of the "UseSeparateColourMap" property at various points in my program after first initialisation using the below code snippet, and at every point after initialisation it returns true.
```
int sep;
vtkSMPropertyHelper(vtkSMPVRepresentationProxy::SafeDownCast(imageProxy)->GetProperty("UseSeparateColorMap")).Get(&sep);
if (sep == 1)
std::cerr << "Setting colour map with \"UseSeparateColourMap\" set to true!" << std::endl;
```
This issue was initially reported on the [Paraview discourse](https://discourse.paraview.org/t/separate-colour-maps-for-multiple-representations-in-single-render-view-in-custom-application/12882) before being referred here.https://gitlab.kitware.com/paraview/paraview/-/issues/22304Release ParaView 5.11.22023-10-19T01:13:07-04:00Ryan Krattigerryan.krattiger@kitware.comRelease ParaView 5.11.2<!--
This template is for tracking a release of ParaView. Please replace the
following strings with the associated values:
- `5.11.2` - replace with base version, e.g., 5.7.0
- `` - for release candidates, replace with "-RC?". For f...<!--
This template is for tracking a release of ParaView. Please replace the
following strings with the associated values:
- `5.11.2` - replace with base version, e.g., 5.7.0
- `` - for release candidates, replace with "-RC?". For final, replace with "".
- `5` - replace with major version number
- `11` - replace with minor version number
- `2` - replace with patch version number
- `release`: The branch to create the release on (for `x.y.0-RC1`,
`master`, otherwise `release`)
- `8442ccd42b50effff97375d176f89e317856a588`: The ParaView commit where the release should be started
Please remove this comment.
-->
# Preparatory steps
- Update ParaView guides
- Catalyst Guide
- [x] Rename to ParaViewCatalystGuide-5.11.2.pdf
- [x] Upload to www.paraview.org/files/v5.11
- Getting Started Guide
- [x] Rename to ParaViewGettingStarted-5.11.2.pdf
- [x] Upload to www.paraview.org/files/v5.11
- macOS signing machine
- [ ] Check that the macOS signing machine is reachable. If not, request it to be switched on.
# Update ParaView
- Update the local copy of `release`.
- If `2` is `0-RC1`, update `master`
- Otherwise, update `release`
```
git fetch origin
git checkout release
git merge --ff-only origin/release # if this fails, there are local commits that need to be removed
git submodule update --recursive --init
```
- If `release` is not `master`, ensure merge requests which should be
in the release have been merged. The [`backport-mrs.py`][backport-mrs]
script can be used to find and ensure that merge requests assigned to the
associated milestone are available on the `release` branch.
- Integrate changes.
- Make a commit for each of these `release`-only changes on a single topic
(suggested branch name: `update-to-v5.11.2`):
- [x] Assemble release notes into `Documentation/release/ParaView-5.11.2.md`.
- [x] Update `version.txt` and tag the commit (tag this commit below)
```
git checkout -b update-to-v5.11.2 8442ccd42b50effff97375d176f89e317856a588
echo 5.11.2 > version.txt
git commit -m 'Update version number to 5.11.2' version.txt
```
- [x] Update VTK's `paraview/release` branch. The
[`release-mr`][release-mr] script should be used to do this. Pass
`-c .kitware-release-paraview.json` to use the appropriate
configuration file.
- [ ] Merge the VTK `paraview/release` update MR
- [ ] Update kwrobot with the new `paraview/release` branch rules (@ben.boeckel)
- [x] `.gitmodules` to track the `paraview/release` branch of VTK
- [x] Update `.gitlab/ci/cdash-groups.json` to track the `release` CDash
groups
- Create a merge request targeting `release`
- [x] Obtain a GitLab API token for the `kwrobot.release.paraview` user
(ask @ben.boeckel if you do not have one)
- [x] Add the `kwrobot.release.paraview` user to your fork with at least
`Developer` privileges (so it can open MRs)
- [x] Use [the `release-mr`][release-mr] script to open the create the
Merge Request (see script for usage)
- [x] Pull the script for each release; it may have been updated since it
was last used
- [x] `release-mr.py -t TOKEN_STRING -c .kitware-release.json -m 8442ccd42b50effff97375d176f89e317856a588`
- [x] The script outputs the information it will be using to create the
merge request. Please verify that it is all correct before creating
the merge request. See usage at the top of the script to provide
information that is either missing or incorrect (e.g., if its data
extraction heuristics fail).
- [x] Get positive review
- [x] `Do: merge`
- [x] Create tag: `git tag -a -m '5.11.2' v5.11.2 commit-that-updated-version.txt`
- Create tarballs
- [x] ParaView (`Utilities/Maintenance/create_tarballs.bash --txz --tgz --zip -v v5.11.2`)
- Upload tarballs to `paraview.org`
- [x] Setup your `~/.ssh/config` and add the web host (@vbolea).
- [x] `rsync -rptv $tarballs web:ParaView_Release/v5.11/`
- Software process updates (these can all be done independently)
- [ ] Update kwrobot with the new `release` branch rules (@ben.boeckel)
- [ ] Run [this script][cdash-update-groups] to update the CDash groups
- This must be done after a nightly run to ensure all builds are in the
`release` group
- See the script itself for usage documentation
- [ ] Add (or update if `release` is `release`) version selection entry
in paraview-superbuild
[backport-mrs]: https://gitlab.kitware.com/utils/release-utils/-/blob/master/backport-mrs.py
[release-mr]: https://gitlab.kitware.com/utils/release-utils/-/blob/master/release-mr.py
[cdash-update-groups]: https://gitlab.kitware.com/utils/cdash-utils/-/blob/master/cdash-update-groups.py
# Update ParaView-Superbuild
- [x] Update release branch for **paraview-superbuild**
```
git fetch origin
git checkout release
git merge --ff-only origin/release
git submodule update --recursive --init
```
- [x] Create new branch `git checkout -b update-to-v5.11.2 release`
- Integrate changes.
- Update versions
- [x] Guide selections in `versions.cmake` and ensure that the paraview
http URL source is the _DEFAULT_ source.
- [x] `paraview_SOURCE_SELECTION` version in `README.md`
- [x] `PARAVIEW_VERSION_DEFAULT` in CMakeLists.txt
- [x] Docker: update default tag strings (in `Scripts/docker/ubuntu/development/Dockerfile`)
- [x] ARG PARAVIEW_TAG=v5.11.2
- [x] ARG SUPERBUILD_TAG=v5.11.2
- [x] ARG PARAVIEW_VERSION_STRING=paraview-5.11
- [x] Commit changes
- [x] `git add README.md versions.cmake CMakeLists.txt Scripts/docker/ubuntu/development/Dockerfile`
- [x] `git commit -m "Update the default version to 5.11.2"`
- Make a commit for each of these `release`-only changes
- [x] Update `.gitlab/ci/cdash-groups.json` to track the `release` CDash
groups (if `release` is `master`)
- Create a commit which will be tagged:
- [x] `git commit --allow-empty -m "paraview: add release 5.11.2"`
- [x] Create tag: `git tag -a -m 'ParaView superbuild 5.11.2' v5.11.2 HEAD`
<!-- if not RC and patch == 0 -->
- [ ] Create a commit that changes the paraview _DEFAULT_ source to the git
url source in the `versions.cmake` file.
<!-- endif -->
- Force `5.11.2` in CMakeLists.txt
- [ ] Append to the top of CMakeLists.txt (After project...) The following
```
# Force source selection setting here.
set(paraview_SOURCE_SELECTION "5.11.2" CACHE STRING "Force version to 5.11.2" FORCE)
set(paraview_FROM_SOURCE_DIR OFF CACHE BOOL "Force source dir off" FORCE)
```
- [ ] Create fixup commit with the above changes `git commit -a --fixup=@`. The fixup commit will prevent merging of the temporary code above; it will be removed in a future step.
- [ ] Create a merge request targeting `release`
- [ ] Obtain a GitLab API token for the `kwrobot.release.paraview` user
(ask @ben.boeckel if you do not have one)
- [ ] Add the `kwrobot.release.paraview` user to your fork with at least
`Developer` privileges (so it can open MRs)
- [ ] Use [the `release-mr`][release-mr] script to open the create the
Merge Request (see script for usage)
- [ ] Pull the script for each release; it may have been updated since it
was last used
- [ ] `release-mr.py -t TOKEN_STRING -c .kitware-release.json -m 8442ccd42b50effff97375d176f89e317856a588`
<!-- if not RC and patch == 0-->
- [ ] Make sure that the backporting directive in the merge-request
description skips the last commit such as: `Backport: master:HEAD~`
<!-- endif -->
- [x] Build binaries
- [x] Build binaries (start all pipelines)
- [x] Download the binaries that have been generated from the Pipeline
build products. They will be deleted within 24 hours.
- [x] Remove fixup commit: `git reset --hard @^`
- [x] Get positive review
- [x] Force push `git push -f gitlab`
- [x] `Do: merge`
- Software process updates (these can all be done independently)
- [ ] Update kwrobot with the new `release` branch rules (@ben.boeckel)
- [ ] Run [this script][cdash-update-groups] to update the CDash groups
- This must be done after a nightly run to ensure all builds are in the
`release` group
- See the script itself for usage documentation
- [ ] Add (or update if `release` is `release`) version selection entry
in paraview-superbuild
# Sign Windows binaries
- [x] Request Windows binary signings (only .exe archives) on the Package
Signing repo. Example request [here][win-sign-example].
# Sign macOS binaries
- [x] Upload to signing server, run script, download resulting .pkg and .dmg files
- [x] Install from .pkg and verify that it is signed with `codesign -dvvv /Applications/ParaView-5.11.2.app/`
- [x] Install from .dmg and verify that it is signed with `codesign -dvvv /Applications/ParaView-5.11.2.app/`
# Validating binaries
For each binary, open the Python shell and run the following:
```python
import numpy
s = Show(Sphere())
ColorBy(s, ('POINTS', 'Normals', 'X'))
Show(Text(Text="$A^2$"))
```
Check that
- Getting started guide opens
- Help lists Readers, Writers, Filters, and Sources properly
- Examples load and match thumbnails in dialog
- Python. Open the Python shell and run
- Plugins are present and load properly
- OSPRay raycasting and pathtracing runs ("Enable Ray Tracing" property in View panel)
- OptiX pathtracing runs (not macOS)
- IndeX runs (load pvNVIDIAIndeX plugin, add a Wavelet dataset, change representaiton to NVIDIA IndeX)
Binary checklist
- [x] macOS arm64
- [x] macOS x86\_64
- [x] Linux
- [x] Linux osmesa
- [x] Windows MPI (.exe)
- [x] Windows MPI (.zip)
- [x] Windows no-MPI (.exe)
- [x] Windows no-MPI (.zip)
# Upload binaries
- [x] Upload binaries to `paraview.org` (`rsync -rptv $binaries paraview.release:ParaView_Release/v5.11/`)
- [x] Ask @jonthan.volks (Kitware comm team) to regenerate `https://www.paraview.org/files/listing.txt` and `md5sum.txt` on the website from within the directory corresponding to www.paraview.org/files/
```
buildListing.sh
updateMD5sum.sh v5.11
```
- [ ] Test download links on https://www.paraview.org/download
# Push tags
- [x] In the `paraview` repository, run `git push origin v5.11.2`.
- [x] In the `paraview-superbuild` repository, run `git push origin v5.11.2`.
# Spack
- [x] Update Spack package: https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/paraview/package.py
<!--
If making a non-RC release:
# Update documentation
- [ ] Submit a Merge Request for release that updates the version to 5.11.2 in https://gitlab.kitware.com/paraview/paraview-docs/-/blob/master/doc/source/conf.py` for `paraview-docs`
- [ ] Upload versioned documentation to `https://github.com/kitware/paraview-docs` (see `https://github.com/Kitware/paraview-docs/blob/master/README.md`)
- [ ] Tag the HEAD of release in [ParaView docs](https://gitlab.kitware.com/paraview/paraview-docs/-/tags) with v5.11.2.
- [ ] Activate the tag on [readthedocs](https://readthedocs.org/projects/paraview/versions/) and build it [here](https://readthedocs.org/projects/paraview/)
- [ ] Go to readthedocs.org and activate
- [ ] Write and publish blog post with release notes.
- [ ] Update release notes
(https://www.paraview.org/Wiki/ParaView_Release_Notes)
-->
# Post-release
- [ ] Post an announcement in the Announcements category on
[discourse.paraview.org](https://discourse.paraview.org/).
- [ ] Request DoD vulnerability scan
- [x] Request an XRInterface plugin validation using [TESTING.md](https://gitlab.kitware.com/paraview/paraview/-/blob/master/Plugins/XRInterface/TESTING.md) protocol from KEU
- [x] Request from comm@kitware.com an update of version number in "Download Latest Release" text on www.paraview.org
- [x] Move unclosed issues in GitLab to the next release milestone in GitLab
/cc @ben.boeckel
/cc @cory.quammen
/cc @charles.gueunet
/cc @mwestphal
/cc @vbolea
[win-sign-example]: https://kwgitlab.kitware.com/software-process/package-signing/-/issues/12Ryan Krattigerryan.krattiger@kitware.comRyan Krattigerryan.krattiger@kitware.com2023-09-23https://gitlab.kitware.com/paraview/paraview/-/issues/22302XRInterface pipeline interface corruption (Monado OpenXR)2023-09-19T01:33:21-04:00Tyson WhiteheadXRInterface pipeline interface corruption (Monado OpenXR)### Issue
The XCInterface plugin works okay until I click on any of the pipeline objects. Then the interface window gets shrunk down to part of the panel with the extra space filled with garbage.
It doesn't freeze or anything, and if y...### Issue
The XCInterface plugin works okay until I click on any of the pipeline objects. Then the interface window gets shrunk down to part of the panel with the extra space filled with garbage.
It doesn't freeze or anything, and if you inteface with the areas on the wider window where the buttons and such would be if they hadn't been shrunk down, it still works and updates the shrunk down bit.
Here is a screenshot of the shrunk interface
![paraview](/uploads/2d77dd0ad7889dd7285e6375ad27c8ac/paraview.png)
### Client Information
```
Version: 5.11.0
VTK Version: 9.2.20220823
Qt Version: 5.15.10
vtkIdType size: 64bits
Embedded Python: On
Python Library Path: /nix/store/xs0nw11xzxm875vma7cn31haiqvhrbg7-python3-3.10.12-env/lib/python3.10
Python Library Version: 3.10.12 (main, Jun 6 2023, 22:43:10) [GCC 12.2.0]
Python Numpy Support: On
Python Numpy Path: /nix/store/xs0nw11xzxm875vma7cn31haiqvhrbg7-python3-3.10.12-env/lib/python3.10/site-packages/numpy
Python Numpy Version: 1.24.2
Python Matplotlib Support: On
Python Matplotlib Path: /nix/store/xs0nw11xzxm875vma7cn31haiqvhrbg7-python3-3.10.12-env/lib/python3.10/site-packages/matplotlib
Python Matplotlib Version: 3.7.0
Python Testing: Off
MPI Enabled: On
Disable Registry: Off
Test Directory:
Data Directory:
SMP Backend: TBB
SMP Max Number of Threads: 4
OpenGL Vendor: AMD
OpenGL Version: 4.6 (Core Profile) Mesa 23.0.3
OpenGL Renderer: AMD Radeon RX 6600 XT (navi23, LLVM 15.0.7, DRM 3.52, 6.4.12)
Accelerated filters overrides available: No
```
### Connection Information
```
Remote Connection: No
```
### OpenXR Information
I don't really see how to query my OpenXR setup (there doesn't seem to be any tool like `openxr-info`). But here is the output from the `openxr_runtime_list` program that is included with the openxr loader package
```
LOG in xrCreateInstance: Instance created
createInfo->applicationInfo.applicationName: List
createInfo->applicationInfo.applicationVersion: 1
createInfo->applicationInfo.engineName: List Engine
createInfo->applicationInfo.engineVersion: 1
appinfo.detected.engine.name: (null)
appinfo.detected.engine.version: 0.0.0
quirks.disable_vulkan_format_depth_stencil: false
LOG in xrCreateInstance: Selected devices
Head: 'Valve Index (libsurvive)'
Left: 'Valve Index Left Controller (libsurvive)'
Right: 'Valve Index Right Controller (libsurvive)'
Hand-Tracking Left: 'Valve Index Left Controller (libsurvive)'
Hand-Tracking Right: 'Valve Index Right Controller (libsurvive)'
Evaluating system
name: 'Monado: Valve Index (libsurvive)'
vendorId: 0x2a
systemId: 0x1
systemName: Monado: Valve Index (libsurvive)
List instance extensions
XR_KHR_binding_modification 1
XR_KHR_composition_layer_cube 8
XR_KHR_composition_layer_cylinder 4
XR_KHR_composition_layer_depth 6
XR_KHR_composition_layer_equirect 3
XR_KHR_composition_layer_equirect2 1
XR_KHR_convert_timespec_time 1
XR_KHR_opengl_enable 10
XR_KHR_opengl_es_enable 8
XR_KHR_swapchain_usage_input_attachment_bit 3
XR_KHR_vulkan_enable 8
XR_KHR_vulkan_enable2 2
XR_EXT_dpad_binding 1
XR_EXT_hand_tracking 4
XR_FB_display_refresh_rate 1
XR_MND_headless 2
XR_MND_swapchain_usage_input_attachment_bit 2
XR_EXTX_overlay 5
XR_MNDX_egl_enable 1
XR_MNDX_force_feedback_curl 1
XR_EXT_debug_utils 4
List API layer properties
```
Here are the various version numbers for OpenXR related components
```
openxr-loader: 1.0.27
vulkan-loader: 1.3.249
amdvlk: 2023.Q2.1
libsurvive: 1.01
openhmd: 0.3.0
monado: unstable-2023-01-14
```https://gitlab.kitware.com/paraview/paraview/-/issues/22301Colormaps: consider adding color deficient-friendly colormaps from Fabio Crameri2023-10-03T20:24:42-04:00Cory Quammencory.quammen@kitware.comColormaps: consider adding color deficient-friendly colormaps from Fabio CrameriThese colormaps are available here: https://www.fabiocrameri.ch/colourmaps/
They include ParaView colormap files.These colormaps are available here: https://www.fabiocrameri.ch/colourmaps/
They include ParaView colormap files.https://gitlab.kitware.com/paraview/paraview/-/issues/22300Clip filter tetrahedralizes the whole mesh whenever a complex cell is present2023-09-19T15:37:22-04:00Tiffany ChhimClip filter tetrahedralizes the whole mesh whenever a complex cell is presentWhen **at least one complex cell** such as a polygon, polyhedron, high-order cell, etc. is present in a mesh, the Clip filter will call `vtkClipDataSet` internally.
The latter **tetrahedralizes the entire clipped dataset**, including r...When **at least one complex cell** such as a polygon, polyhedron, high-order cell, etc. is present in a mesh, the Clip filter will call `vtkClipDataSet` internally.
The latter **tetrahedralizes the entire clipped dataset**, including regular cells such as hexahedra or wedges, which should be left intact or simply clipped.
**Before ParaView 5.11.0**, only complex cells were tetrahedralized instead of the entire dataset.
This change seems to have been introduced in vtk/vtk!9310.Spiros TsalikisSpiros Tsalikishttps://gitlab.kitware.com/paraview/paraview/-/issues/22298"Crystal Eyes" stereo mode can't be selected via the GUI2023-10-10T11:05:05-04:00Thomas Galland"Crystal Eyes" stereo mode can't be selected via the GUIWhen launching ParaView with `--stereo` without the `--stereo-type="Crystal Eyes"` option, selecting `Crystal Eyes` afterwards in the GUI does nothing.
Steps to reproduce:
- Launch ParaView with `--stereo` launch option
- In the `Stereo...When launching ParaView with `--stereo` without the `--stereo-type="Crystal Eyes"` option, selecting `Crystal Eyes` afterwards in the GUI does nothing.
Steps to reproduce:
- Launch ParaView with `--stereo` launch option
- In the `Stereo` options in the `View` section of the `Properties` panel, set `Stereo Type` to `Crystal Eyes`
- Nothing happens.
When launching ParaView with `--stereo` with the `--stereo-type="Crystal Eyes"` option, selecting any other stereo mode afterwards in the GUI does apply only on the left eye (the right eye image freezes).
Steps to reproduce:
- Launch ParaView with `--stereo --stereo-type="Crystal Eyes"` launch options
- In the `Stereo` options in the `View` section of the `Properties` panel, set `Stereo Type` to `None`
- Right eye image freezes.
Tested in builtin mode.
This seems to be somehow a more generic issue of the 3rd one reported here: https://gitlab.kitware.com/paraview/paraview/-/issues/19484https://gitlab.kitware.com/paraview/paraview/-/issues/22296ParaView can hang in a distributed context when there is no data on at least ...2023-09-13T04:03:41-04:00Julien FaustyParaView can hang in a distributed context when there is no data on at least one of the processes## Steps to reproduce
* start a distributed server on 2 procs: `mpirun -np 2 pvserver`
* connect a paraview client to the server
* open `disk_out_ref.ex2` from the test data
* run `GhostCellsGenerator`
* ParaView should hang on the ghos...## Steps to reproduce
* start a distributed server on 2 procs: `mpirun -np 2 pvserver`
* connect a paraview client to the server
* open `disk_out_ref.ex2` from the test data
* run `GhostCellsGenerator`
* ParaView should hang on the ghost cell generation
## Probable cause
I believe that the executive for each algorithm takes the decision to execute without communicating with executives on other processes. This means that an executive may decline to execute a filter that necessitates distributed communication on a process where no data exists. If the filter does not take this into account, then on the first global communication, the execution will hang on all processes executing the filter waiting for the processes that decided to not execute the filter.
It is either:
* the responsibility of the executive to ensure that a filter gets executed on all ranks if executed on any rank,
* the responsibility of all filters to take into account that all processes might not enter into their request data,
* or, the responsibility of the controller to create sub communicators for each algorithmic execution that are coherent
As of the time of writing of this issue, this responsibility is not clearly stated or I have not found where in the documentation it is.https://gitlab.kitware.com/paraview/paraview/-/issues/22295`2D Transfer Function checkbox` volume rendering not working with .vdb file (...2023-09-13T03:45:37-04:00fashing`2D Transfer Function checkbox` volume rendering not working with .vdb file (partial arrays partitioned dataset)As stated in [discourse](https://discourse.paraview.org/t/is-it-possible-to-choose-multiple-girds-in-the-coloring-select/12831),
I ran into these errors while enabling the `2D Transfer Function checkbox` for volume rendering.
![image](/...As stated in [discourse](https://discourse.paraview.org/t/is-it-possible-to-choose-multiple-girds-in-the-coloring-select/12831),
I ran into these errors while enabling the `2D Transfer Function checkbox` for volume rendering.
![image](/uploads/880599da531d76843547fd5181280628/image.png)
I tried several testcases [here](https://www.openvdb.org/download/) and got the same result.https://gitlab.kitware.com/paraview/paraview/-/issues/22294Spreadsheet view crashes remote server2024-03-25T14:07:36-04:00W. Alan ScottSpreadsheet view crashes remote serverSpreadsheet view is crashing remote server after slice. Here is how to replicate.
* Master (v5.11.1-1679-g a2b48e7dbb), Linux, remote server (16 ranks)
* Open g1s1. Apply.
* Slice. Apply.
* Split Horizontal. Spreadsheet.
Crash
@co...Spreadsheet view is crashing remote server after slice. Here is how to replicate.
* Master (v5.11.1-1679-g a2b48e7dbb), Linux, remote server (16 ranks)
* Open g1s1. Apply.
* Slice. Apply.
* Split Horizontal. Spreadsheet.
Crash
@cory.quammen @spiros.tsalikis
If you guys can find this for 5.12.0, great. OK to slip to 5.12.1. Must be fixed for 5.12.1.5.12.1 (Spring 2024)Spiros TsalikisSpiros Tsalikishttps://gitlab.kitware.com/paraview/paraview/-/issues/22293Generating a geometry from a table wil trigger whole pipeline a second time w...2023-09-28T03:14:10-04:00Mathieu Westphal (Kitware)Generating a geometry from a table wil trigger whole pipeline a second time when working with a distributed server because of ghost cellsGenerating a geometry from a table wil trigger whole pipeline a second time when working with a distributed server because of ghost cells.
It is caused by the fact the the geometry representation (through vtkSIProxy code) is requesting ...Generating a geometry from a table wil trigger whole pipeline a second time when working with a distributed server because of ghost cells.
It is caused by the fact the the geometry representation (through vtkSIProxy code) is requesting ghost cells that the table source cannot provide.
Steps to reproduce:
- run distributed pvserver
- run paraview, connect to distributed pvserver
- Tools -> TimerLog
- open [a.csv](/uploads/604f1556e9ab9773f62b5abbfda84ca5/a.csv), Apply
- Refresh TimerLog, see the the `Execute a.csv` line.
- TableToPoints, apply
- Refresh TimerLog, see the the `Execute a.csv` line a second time in server 0, this is a bugMathieu Westphal (Kitware)Mathieu Westphal (Kitware)https://gitlab.kitware.com/paraview/paraview/-/issues/22292Changing SMP_IMPLEMENTATION_TYPE triggers a complete rebuild of ParaView2023-09-08T12:05:16-04:00Mathieu Westphal (Kitware)Changing SMP_IMPLEMENTATION_TYPE triggers a complete rebuild of ParaViewChanging SMP_IMPLEMENTATION_TYPE triggers a complete rebuild of ParaView
```
cmake -GNinja -DVTK_SMP_ENABLE_SEQUENTIAL=ON -DVTK_SMP_ENABLE_STDTHREAD=ON -DVTK_SMP_IMPLEMENTATION_TYPE=STDThread ../src
ninja
cmake -DVTK_SMP_IMPLEMENTATION_...Changing SMP_IMPLEMENTATION_TYPE triggers a complete rebuild of ParaView
```
cmake -GNinja -DVTK_SMP_ENABLE_SEQUENTIAL=ON -DVTK_SMP_ENABLE_STDTHREAD=ON -DVTK_SMP_IMPLEMENTATION_TYPE=STDThread ../src
ninja
cmake -DVTK_SMP_IMPLEMENTATION_TYPE=Sequential ./
ninja -> >15000 targets, this is a bug
```
VTK does not have this issue, it triggers a few hundreds targets instead.https://gitlab.kitware.com/paraview/paraview/-/issues/22291IOSS writer doesn't write time data.2023-09-14T15:55:33-04:00W. Alan ScottIOSS writer doesn't write time data.The IOSS writer is no longer writing time data. Here is how to replicate.
* Master (v5.11.1-1679-g a2b48e7dbb), builtin server, Linux.
* Read can.exo. Apply.
* File/ Write Data/ IOSS writer. canOutput.exo. Apply.
* Read in canOutput...The IOSS writer is no longer writing time data. Here is how to replicate.
* Master (v5.11.1-1679-g a2b48e7dbb), builtin server, Linux.
* Read can.exo. Apply.
* File/ Write Data/ IOSS writer. canOutput.exo. Apply.
* Read in canOutput.exo. Apply.
* Play.
The new dataset does not offset correctly. This is a bug.5.12 (Winter 2023)Spiros TsalikisSpiros Tsalikishttps://gitlab.kitware.com/paraview/paraview/-/issues/22290ioss writer incorrectly switches to the exodus writer2023-09-07T17:07:27-04:00W. Alan Scottioss writer incorrectly switches to the exodus writer If you try to write a legal exodus file using the IOSS writer, but the extension isn't .exo, the writer magically switches to the Exodus writer without notice. This is incorrect - the IOSS writer should just print out a warning and clo... If you try to write a legal exodus file using the IOSS writer, but the extension isn't .exo, the writer magically switches to the Exodus writer without notice. This is incorrect - the IOSS writer should just print out a warning and close.
* Master from July 2023, Linux, builtin server.
* Open can.exo. Apply.
* File/ Save Data. Save as canRS.e. A new dialog will open up. At the top of the dialog will state that we are using the Exodus writer.
This is a bug.5.13 (Summer 2024)Spiros TsalikisSpiros Tsalikishttps://gitlab.kitware.com/paraview/paraview/-/issues/22289Plugin for projecting Latitude Longitude grids into other forms: Robinson, Me...2023-12-16T08:25:58-05:00John PatchettPlugin for projecting Latitude Longitude grids into other forms: Robinson, Mercator, Stereographic, Lambert Conformal Conic@berkgeveci We, @linneapalmstrom , LANL, RAPIDS2, would like to see a new plugin, Latitude Longitude reproject that leverages the new default superbuild inclusion of vtkGeovisCore. Our uses have requested Robinson, Mercator, Stereograp...@berkgeveci We, @linneapalmstrom , LANL, RAPIDS2, would like to see a new plugin, Latitude Longitude reproject that leverages the new default superbuild inclusion of vtkGeovisCore. Our uses have requested Robinson, Mercator, Stereographic, Lambert Conformal Conic projections. In addition they requested a cartesian projection on a sphere (which we will add a separate issue for).John PatchettJohn Patchetthttps://gitlab.kitware.com/paraview/paraview/-/issues/22288add_pv_test testing function undefined but still used2023-09-08T03:18:01-04:00Louis Gombertadd_pv_test testing function undefined but still usedThe CMake function/macro `add_pv_test` does not seem to be defined anymore even though it is used 4 times throughout the file [Clients/Testing/XML/CMakeLists.txt](https://gitlab.kitware.com/paraview/paraview/-/blob/master/Clients/ParaVie...The CMake function/macro `add_pv_test` does not seem to be defined anymore even though it is used 4 times throughout the file [Clients/Testing/XML/CMakeLists.txt](https://gitlab.kitware.com/paraview/paraview/-/blob/master/Clients/ParaView/Testing/XML/CMakeLists.txt), which could indicate dead tests and unused CMake code paths.
It is probably a leftover from this cleanup commit https://gitlab.kitware.com/paraview/paraview/-/commit/2c00d068f8d523e494d2173399980f8ce647e1a3
cc @mwestphal @ben.boeckelhttps://gitlab.kitware.com/paraview/paraview/-/issues/22287information/FileProperties section does not display correct filename correspo...2023-09-07T03:28:29-04:00이상준 / 학생 / 에너지시스템공학부information/FileProperties section does not display correct filename corresponding to the one being rendered.In the <Information> Panel, the Name section under <File Properties> should have displayed the file that is currently being rendered. However, the most new release 5.11.1 only shows the very first file of the series.
At least up to Para...In the <Information> Panel, the Name section under <File Properties> should have displayed the file that is currently being rendered. However, the most new release 5.11.1 only shows the very first file of the series.
At least up to ParaView 5.6.2, it was showing the correct file.
Related forum post is https://discourse.paraview.org/t/file-name-does-not-appear-in-information-fileproperties-section-y/12821https://gitlab.kitware.com/paraview/paraview/-/issues/22286TemporalParticlesToPathlines is broken in nightly build2023-12-01T10:50:45-05:00Jean M. FavreTemporalParticlesToPathlines is broken in nightly buildThe TemporalParticlesToPathlines produces lots of erroneous lines because of what seems like an indexing error. The attached Python script works very well with the nightly build ParaView-master-5.11.1-1587-geefb004e84-MPI-Linux-Python3.9...The TemporalParticlesToPathlines produces lots of erroneous lines because of what seems like an indexing error. The attached Python script works very well with the nightly build ParaView-master-5.11.1-1587-geefb004e84-MPI-Linux-Python3.9-x86_64 (see Good_TemporalParticlesToPathlines.png), but is totally broken with the next nightly, i.e. ParaView-master-5.11.1-1595-g499dc238e8-MPI-Linux-Python3.9-x86_64 (see Bad_TemporalParticlesToPathlines.png)
![Bad_TemporalParticlesToPathlines](/uploads/9ec80ba0bce924a8d504d07773c82ee8/Bad_TemporalParticlesToPathlines.png)
![Good_TemporalParticlesToPathlines](/uploads/b67025f25e0473f34803c21ef688a560/Good_TemporalParticlesToPathlines.png)
[pvTemporalParticlesToPathlines.py.gz](/uploads/f5f718fb89715775c98c8a5b4112e316/pvTemporalParticlesToPathlines.py.gz)Yohann Bearzi (Kitware)Yohann Bearzi (Kitware)https://gitlab.kitware.com/paraview/paraview/-/issues/22285ProcessIds cannot be shown in ParaView when using local rendering2023-09-06T04:58:24-04:00Mathieu Westphal (Kitware)ProcessIds cannot be shown in ParaView when using local renderingProcessIds are a recently introduced attributes data, similar to GlobalIds. The filter `GenerateProcessIds` can generate such ideas,
however, they are not copied to the client when using client/server with local rendering.
Step to repro...ProcessIds are a recently introduced attributes data, similar to GlobalIds. The filter `GenerateProcessIds` can generate such ideas,
however, they are not copied to the client when using client/server with local rendering.
Step to reproduce:
- run pvserver, run paraview
- Connect to pvserver
- Make sure remote rendering threshold is higher than 20Mb
- Sphere, Apply
- GenerateProcessIds, Apply
- Try to color with ProcessIds, no data is visible and solid color is used, this is a bug
- A simple work around is to use calculator to copy the array in a non ProcessIds arrays
This is probably caused by the copy of the surfacic data from the server to the client which probably ignore the ProcessIds
Note: The following tests are impacted by this bug and should be modified whenever this bug is fixed:
- DistributePoints
- GenerateProcessIds
- GhostCellsGeneratorSynchronizehttps://gitlab.kitware.com/paraview/paraview/-/issues/22284Issue while reading data from lagrangian particles generated by OpenFOAM usin...2023-09-05T11:42:41-04:00franco otaolaIssue while reading data from lagrangian particles generated by OpenFOAM using the OpenFOAM readerHello,
when opening a simulation with lagrangian particles done in OpenFOAM, there is an issue with the time stamps of the particles which blocks the possibility of using for example the temporal particles pathlines filter to create the ...Hello,
when opening a simulation with lagrangian particles done in OpenFOAM, there is an issue with the time stamps of the particles which blocks the possibility of using for example the temporal particles pathlines filter to create the path that the particles followed during the simulation, even though the data 'is there'. Here is the discussion of about the issue: https://discourse.paraview.org/t/lagrangianparticletracker-example-file/571 , the error that I am getting (using paraview 5.11.1 with OpenFOAM 2306) is the following:
```
ERROR: In vtkTemporalPathLineFilter.cxx, line 343
vtkTemporalPathLineFilter (000001E683425760): The input dataset did not have a valid DATA_TIME_STEPS information key
ERROR: In vtkExecutive.cxx, line 741
vtkPVCompositeDataPipeline (000001E692199690): Algorithm vtkTemporalPathLineFilter (000001E683425760) returned failure for request: vtkInformation (000001E690439420)
Debug: Off
Modified Time: 2518182
Reference Count: 1
Registered Events: (none)
Request: REQUEST_DATA
FROM_OUTPUT_PORT: 0
FORWARD_DIRECTION: 0
ALGORITHM_AFTER_FORWARD: 1
```
here the files of the case with some data can be downloaded, the data was to large to upload directly to the gitlab [link](https://filesender.utc.fr/filesender/?s=download&token=30fc3d13-37cb-47d4-aab3-d82b8632b53e)
best regards