ParaView issueshttps://gitlab.kitware.com/paraview/paraview/-/issues2020-07-27T18:59:52-04:00https://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/19195GL vs OpenGL can lead to llvm version mismatch runtime errors2020-07-24T12:29:41-04:00David E. DeMarleGL vs OpenGL can lead to llvm version mismatch runtime errorsParaview 5.7.rc1 built on stampede2@TACC via the superbuild(SB) with SB built mesa fails on startup.
At configure time CMake finds both the mesa we built at OPENGL_GL_LIBRARY in ${SB}/install/libGL.so and the system provided OPENGL_OPEN...Paraview 5.7.rc1 built on stampede2@TACC via the superbuild(SB) with SB built mesa fails on startup.
At configure time CMake finds both the mesa we built at OPENGL_GL_LIBRARY in ${SB}/install/libGL.so and the system provided OPENGL_OPENGL_LIBRARY in /usr/lib64/libOpenGL.so
When we run paraview fails to start and we get llvm option 'help-list' registered more than once. So far none of the cmake flags I've tried have succeeded in forcing cmake to ignore the system GL and use only the LEGACY GL that we make.5.9 (Fall 2020)Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/paraview/paraview/-/issues/20103Adding color by value to XY element from table leads to crash2020-07-24T07:17:15-04:00carolinhAdding color by value to XY element from table leads to crashHello. Here is my pipeline:
- loading csv table
- adding filter "TableToPoints"
- adding filter "Glyph" (see figure 1)
... when I am now changing the color of the glyph from 'solid' to a value (in my case e.g. 'noise'), ParaView crashes...Hello. Here is my pipeline:
- loading csv table
- adding filter "TableToPoints"
- adding filter "Glyph" (see figure 1)
... when I am now changing the color of the glyph from 'solid' to a value (in my case e.g. 'noise'), ParaView crashes (see figure 2)
How can I avoid that?
![Folie1](/uploads/f13ec7ed10265b19043ab98edd4a4223/Folie1.PNG)
![Folie2](/uploads/6005c788fe13d228260513a719f49034/Folie2.PNG)https://gitlab.kitware.com/paraview/paraview/-/issues/20107Selection Query Not Working2020-07-24T03:55:34-04:00RamziSelection Query Not WorkingI have an XMF file that I'm currently processing. I've been using the selection query tool for the past weeks. After going back to ParaView, I'm unable to use this tool. Every time I attempt to run a query, the program crashes and I get ...I have an XMF file that I'm currently processing. I've been using the selection query tool for the past weeks. After going back to ParaView, I'm unable to use this tool. Every time I attempt to run a query, the program crashes and I get the dreaded Mac OS unresponsive spinning wheel. I've trying deleting the software and downloading it again, but nothing changed. Any help is greatly appreciated!https://gitlab.kitware.com/paraview/paraview/-/issues/20088Update protobuf to 3.122020-07-21T13:46:39-04:00Yasushi SaitoUpdate protobuf to 3.12Currently Paraview uses protobuf 3.11.2. But the latest protobuf version 3.12.* is binary-incompatible with 3.11. This creates a problem (paraview crashes on start) when we dynamically link a plugin that uses protobuf 3.12.
We currentl...Currently Paraview uses protobuf 3.11.2. But the latest protobuf version 3.12.* is binary-incompatible with 3.11. This creates a problem (paraview crashes on start) when we dynamically link a plugin that uses protobuf 3.12.
We currently work around this problem by downgrading protobuf to 3.11.2 on our side, but it's better if Paraview can follow the newest protobuf.
If someone can tell me a way to do that, I'm happy to create a pull request. It looks like ThirdParty/protobuf is where we import protobuf, but it's not clear how we update the protobuf version.https://gitlab.kitware.com/paraview/paraview/-/issues/19432macOS Catalina: ParaView-5.7.0-MPI-OSX10.12-Python2.7-64bit.pkg” can’t be ope...2020-07-20T17:00:40-04:00Cory Quammencory.quammen@kitware.commacOS Catalina: ParaView-5.7.0-MPI-OSX10.12-Python2.7-64bit.pkg” can’t be opened because Apple cannot check it for malicious software.Installer bug report from Johnny Seales on Discourse: https://discourse.paraview.org/t/package-installer-failed-on-macos-catalina/2891Installer bug report from Johnny Seales on Discourse: https://discourse.paraview.org/t/package-installer-failed-on-macos-catalina/28915.8.1Cory Quammencory.quammen@kitware.comCory Quammencory.quammen@kitware.comhttps://gitlab.kitware.com/paraview/paraview/-/issues/18794volume rendering performance is bad on huge data2020-07-20T12:40:16-04:00W. Alan Scottvolume rendering performance is bad on huge dataVolume rendering performance is really bad, when run on huge data, in parallel. This needs to be looked at and if possible, adressed.
Here is how to replicate, using a source.
* ParaView 5.6.0, Linux, remote server 4 nodes (64 ranks...Volume rendering performance is really bad, when run on huge data, in parallel. This needs to be looked at and if possible, adressed.
Here is how to replicate, using a source.
* ParaView 5.6.0, Linux, remote server 4 nodes (64 ranks). Total memory is about 256 GBytes total.
* Sources/ Unstructured Cell Types. Tet. I was able to set the size as 200x200x200. Apply.
* Color by Polynomial. Volume Render.
* Clear the Timer log.
* Increase the size of the mesh by 1, for instance to 200x200x201. Apply.
* Rotate the image.
Possible bug. I kept having the screen go blank. Rotating the image again fixed this. Don't know who's bug this is (RGS or ParaView).
* Check the timer log.
Issue 1: We are spending LOTS of time in volume rendering, and I believe that more nodes won't scale. This serial behavior is killing us. Please fix it.
Issue 2: Even though the client says 60 seconds has elapsed, the server side says 20'ish seconds, and only 5 or 10 are accounted for. Timer log needs to be updated to account for this time.5.9 (Fall 2020)Utkarsh AyachitUtkarsh Ayachithttps://gitlab.kitware.com/paraview/paraview/-/issues/20085Release ParaView 5.8.1-RC22020-07-20T09:43:43-04:00Cory Quammencory.quammen@kitware.comRelease ParaView 5.8.1-RC2
# Update ParaView
- [x] Update `release` branch for **paraview**
```
git fetch origin
git checkout release
git merge --ff-only origin/release
git submodule update --recursive --init
```
- [x] Update `version.txt` and tag the commit...
# Update ParaView
- [x] Update `release` branch for **paraview**
```
git fetch origin
git checkout release
git merge --ff-only origin/release
git submodule update --recursive --init
```
- [x] Update `version.txt` and tag the commit
```
git checkout -b update-to-v5.8.1-RC2
echo 5.8.1-RC2 > version.txt
git commit -m 'Update version number to 5.8.1-RC2' version.txt
git tag -a -m 'ParaView 5.8.1-RC2' v5.8.1-RC2 HEAD
```
- Integrate changes to `master` branch
- [x] Create a merge request targeting `master` (do *not* add `Backport: release`)
- [x] `Do: merge`
- Integrate changes to `release` branch
- [x] `git push origin update-to-v5.8.1-RC2:release v5.8.1-RC2`
- Create tarballs
- [x] ParaView (`Utilities/Maintenance/create_tarballs.bash --txz --tgz --zip -v v5.8.1-RC2`)
- Upload tarballs to `paraview.org`
- [x] `rsync -rptv $tarballs paraview.release:ParaView_Release/v5.8/`
# Update ParaView-Superbuild
- [x] Update `release` branch for **paraview/paraview-superbuild**
```
git fetch origin
git checkout release
git merge --ff-only origin/release
git submodule update
git checkout -b update-to-v5.8.1-RC2
```
- Update `CMakeLists.txt`
- [x] Set ParaView source selections in `CMakeLists.txt` and force explicit
version in `CMakeLists.txt`:
```
# Force source selection setting here.
set(paraview_SOURCE_SELECTION "5.8.1-RC2" CACHE STRING "Force version to 5.8.1-RC2" FORCE)
set(paraview_FROM_SOURCE_DIR OFF CACHE BOOL "Force source dir off" FORCE)
```
- Update versions
- [x] Guide selections in `versions.cmake`
- [x] Docker: update default tag strings (in `Scripts/docker/ubuntu/Dockerfile`)
- [x] ARG PARAVIEW_TAG=v5.8.1-RC2
- [x] ARG SUPERBUILD_TAG=v5.8.1-RC2
- [x] Commit changes and push to GitLab
```
git add versions.cmake CMakeLists.txt Scripts/docker/ubuntu/Dockerfile
git commit -m "Update the default version to 5.8.1-RC2"
git gitlab-push
```
- Integrate changes to `master` branch
- [x] Create a merge request targeting `master`, title beginning with WIP (do *not* add `Backport: release` to description)
- [x] Build binaries (`Do: test`)
- [x] Download the binaries that have been generated in the dashboard results. They will be deleted within 24 hours.
- [x] Remove explicit version forcing added in CMakeLists.txt, amend the commit, and force push
```
git add CMakeLists.txt
git commit --amend --no-edit
git gitlab-push -f
```
- Finalize merge request
- [x] Remove WIP from merge request title
- [x] Get positive review
- [x] `Do: merge`
- [x] `git tag -a -m 'ParaView superbuild 5.8.1-RC2' v5.8.1-RC2 HEAD`
- Integrate changes to `release` branch
- [x] `git push origin update-to-v5.8.1-RC2:release v5.8.1-RC2`
# 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.8.1-RC2.app/`
- [x] Install from .dmg and verify that it is signed with `codesign -dvvv /Applications/ParaView-5.8.1-RC2.app/`
# Validating binaries
- For each binary, check
- [x] Getting started guide opens
- [x] Examples load and match thumbnails in dialog
- [x] Python
- [x] Open Python Shell and run
```python
import numpy
s = Sphere()
sd = Show(s)
ColorBy(sd, ('POINTS', 'Normals', 'X'))
Show(Text(Text="$A^2$"))
```
-
- [x] Plugins are present and load properly
- [x] OSPRay raycasting and pathtracing runs
- [x] OptiX pathtracing runs
- [x] IndeX runs
- [x] AutoMPI
- Binary checklist
- [x] macOS
- [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.8/`)
- [x] Ask @utkarsh.ayachit to regenerate `https://www.paraview.org/files/listing.txt` and `md5sum.txt` on the website
```
buildListing.sh
updateMD5sum.sh v5.8
```
- [x] Test download links on https://www.paraview.org/download
# Post-release
- [ ] Post an announcement in the Announcements category on
[discourse.paraview.org](https://discourse.paraview.org/).
/cc @ben.boeckel
/cc @cory.quammen
/cc @utkarsh.ayachit5.8.1Cory Quammencory.quammen@kitware.comCory Quammencory.quammen@kitware.comhttps://gitlab.kitware.com/paraview/paraview/-/issues/20089Pygments should be included in ParaView binary release2020-07-20T08:28:37-04:00Mathieu Westphal (Kitware)Pygments should be included in ParaView binary releaseThe last binary release of ParaView containing python-pygments seems to be ParaView 5.6.1, so I supose since this issue has been marked as done :
https://gitlab.kitware.com/paraview/paraview/-/issues/16820
It would be nice to provide p...The last binary release of ParaView containing python-pygments seems to be ParaView 5.6.1, so I supose since this issue has been marked as done :
https://gitlab.kitware.com/paraview/paraview/-/issues/16820
It would be nice to provide pygments and python syntax higlighting in the release.
@utkarsh.ayachit @aron.helser @ben.boeckelhttps://gitlab.kitware.com/paraview/paraview/-/issues/20087Change background color not working properly2020-07-20T03:48:36-04:00Kieran RingelChange background color not working properly![Screen_Shot_2020-07-17_at_1.05.17_PM](/uploads/93f4faaa5b63f0af76a02ecd53f14ea3/Screen_Shot_2020-07-17_at_1.05.17_PM.png)
When I go to change the background color using the load color pallet button, the resulting background color does...![Screen_Shot_2020-07-17_at_1.05.17_PM](/uploads/93f4faaa5b63f0af76a02ecd53f14ea3/Screen_Shot_2020-07-17_at_1.05.17_PM.png)
When I go to change the background color using the load color pallet button, the resulting background color does not match what I input. I attached a screen shot as an example. It allowed me to use a gradient background, but instead of using the colors that I selected it defaulted to a blue color.https://gitlab.kitware.com/paraview/paraview/-/issues/20084Paraview 5.8.0 crashes with strange UI problem on Windows 102020-07-17T10:28:44-04:00Wenyin WeiParaview 5.8.0 crashes with strange UI problem on Windows 10It seems that Win10 doesn't work well with Paraview 5.8.0. Things look well when I open the example data. However, once I click the icon in the pipe tree viewer or some other places, the application window crashes and all parts of the ap...It seems that Win10 doesn't work well with Paraview 5.8.0. Things look well when I open the example data. However, once I click the icon in the pipe tree viewer or some other places, the application window crashes and all parts of the app cover each other with a strange zoom ratio. The problem exists for both MPI and non-MPI version. I installed them with the latest 5.8.0 installer *.exe from the web.
![image](/uploads/8c09fe904c42d864b0bb981c6c02385a/image.png)
The problem disappeared when I installed 5.8.0 on Ubuntu 18.04. To let Paraview work on Windows, I have to downgrade to 5.6.2, that version works well.https://gitlab.kitware.com/paraview/paraview/-/issues/19937AggregateDataSet filter runs into MPI size constraint2020-07-14T11:25:49-04:00Boonthanome NouanesengsyAggregateDataSet filter runs into MPI size constraintThere have been occasions where an mpi error is encountered where mpi is trying to send a message that is too large. The error looks like "This operation not yet supported for more than <x> bytes".
This error was last encountered with t...There have been occasions where an mpi error is encountered where mpi is trying to send a message that is too large. The error looks like "This operation not yet supported for more than <x> bytes".
This error was last encountered with the AggregateDataSet filter, in which Bob Kares was going from 30K procs to 200 procs. I've also encountered this error in the past, too. Bob has got it working now, but I'm not sure what he is doing differently.
@patchett2002 @cory.quammen @utkarsh.ayachit5.8.1Utkarsh AyachitUtkarsh Ayachithttps://gitlab.kitware.com/paraview/paraview/-/issues/20038Build failure with external HDF5 (v1.12) and PV 5.8 build2020-07-09T16:17:34-04:00Alexander NeumannBuild failure with external HDF5 (v1.12) and PV 5.8 buildObserved error in VCPKG CI:
```
D:\buildtrees\paraview\src\4fb6e6800f-2efd43d7fc\Utilities\VisItBridge\databases\readers\M3DC1\avtM3DC1FileFormat.C(2057): error C2660: 'H5Oget_info_by_name3': function does not take 4 arguments
D:\instal...Observed error in VCPKG CI:
```
D:\buildtrees\paraview\src\4fb6e6800f-2efd43d7fc\Utilities\VisItBridge\databases\readers\M3DC1\avtM3DC1FileFormat.C(2057): error C2660: 'H5Oget_info_by_name3': function does not take 4 arguments
D:\installed\x64-windows-static\include\H5Opublic.h(188): note: see declaration of 'H5Oget_info_by_name3'
D:\buildtrees\paraview\src\4fb6e6800f-2efd43d7fc\Utilities\VisItBridge\databases\readers\M3DC1\avtM3DC1FileFormat.C(2116): error C2660: 'H5Oget_info3': function does not take 2 arguments
D:\installed\x64-windows-static\include\H5Opublic.h(187): note: see declaration of 'H5Oget_info3'
```
Either Paraview needs to set the required HDF5 preprocessor definitions to select the proper HDF5 api or VisItBridge needs updating for the new API.https://gitlab.kitware.com/paraview/paraview/-/issues/19974error reading cgns time data2020-07-09T13:15:45-04:00W. Alan Scotterror reading cgns time dataWe have an error reading variable data from different time steps in a cgns file. I will send file to Utkarsh and Cory. This works correctly in 5.7.0, but not correctly with 5.8.0 or master.
* ParaView 5.8.0, Linux, remote server.
* Loa...We have an error reading variable data from different time steps in a cgns file. I will send file to Utkarsh and Cory. This works correctly in 5.7.0, but not correctly with 5.8.0 or master.
* ParaView 5.8.0, Linux, remote server.
* Load vol-hofd-stg.cgns.4.*. Turn on all variables. Apply.
* Surface.
* Paint by primitives_1.
* Last time step.
* Rescale to data range.
Notice that the min and max don't change. They do with ParaView 5.7.0. This is a bug.
Note, there is an error in the file. It appears that the last two timesteps have the same time. Don't know if this is important...5.9 (Fall 2020)https://gitlab.kitware.com/paraview/paraview/-/issues/20070Protobuf unsuitable version in Paraview Superbuild2020-07-09T11:07:09-04:00Eduardo BerrocalProtobuf unsuitable version in Paraview SuperbuildIt seems that the version of protobuf used by current Paraview should at least be 3.4. However, Paraview superbuild is stuck at 2.7, and compilation fails:
```
-- Could NOT find Protobuf: Found unsuitable version "2.7.0", but required i...It seems that the version of protobuf used by current Paraview should at least be 3.4. However, Paraview superbuild is stuck at 2.7, and compilation fails:
```
-- Could NOT find Protobuf: Found unsuitable version "2.7.0", but required is at least "3.4" (found /.../install/lib64/libprotobuf.so;-lpthread)
CMake Error at VTK/CMake/vtkModule.cmake:4112 (message):
Could not find the Protobuf external dependency.
Call Stack (most recent call first):
VTK/CMake/vtkModule.cmake:4635 (vtk_module_find_package)
VTK/CMake/vtkModule.cmake:4509 (vtk_module_third_party_external)
```Cory Quammencory.quammen@kitware.comCory Quammencory.quammen@kitware.comhttps://gitlab.kitware.com/paraview/paraview/-/issues/20024Preview mode does not rescale text correctly2020-07-09T10:38:16-04:00Ethan StamPreview mode does not rescale text correctly@patchett2002 @utkarsh.ayachit @cory.quammen
Text scaling is mishandled in Preview mode. In this example, the Colormap text is cut off by the window size:
Using 5.8.0 and the disk_out_ref example dataset
Normal RenderView:
![Screen_S...@patchett2002 @utkarsh.ayachit @cory.quammen
Text scaling is mishandled in Preview mode. In this example, the Colormap text is cut off by the window size:
Using 5.8.0 and the disk_out_ref example dataset
Normal RenderView:
![Screen_Shot_2020-06-23_at_9.42.53_AM](/uploads/1535f63c171cd6d7b7505c184b742c90/Screen_Shot_2020-06-23_at_9.42.53_AM.png)
Preview Mode (1920x1080):
![Screen_Shot_2020-06-23_at_9.37.03_AM](/uploads/92e16749303a1fc016a6c2f12ea3a642/Screen_Shot_2020-06-23_at_9.37.03_AM.png)5.8.1https://gitlab.kitware.com/paraview/paraview/-/issues/20069Color bar and rendered image don't match2020-07-08T14:57:54-04:00Ethan StamColor bar and rendered image don't matchThis was found on MacOS 10.13.6 with ParaView 5.4.0 and ParaView 5.8.0
@utkarsh.ayachit @cory.quammen @danlipsa
@patchett2002 please prioritize this
To reproduce:
1. Load wavelet source
2. Apply default slice filter
- Change color ...This was found on MacOS 10.13.6 with ParaView 5.4.0 and ParaView 5.8.0
@utkarsh.ayachit @cory.quammen @danlipsa
@patchett2002 please prioritize this
To reproduce:
1. Load wavelet source
2. Apply default slice filter
- Change color map to this custom colormap: https://sciviscolor.org/wp-content/uploads/sites/14/2017/09/FloatPNG_PV44.xml
3. Rescale colormap to data range (should be 84.144 to 276.683)
4. Apply contour filter at RTData=260
I noticed the color bar looks much brighter than the wavelet, so I checked the pixel color values for the color bar and what I would expect to be a similar color in the rendered wavelet slice. I used digital color meter on MacOS to get these values. The reasoning for the slice is to ensure the color bar matches what you're seeing, not what's below the surface.
The white line is the contour at RTData=260.
Color bar at RTData=260 (rgb is 228, 236, 0):
![Screen_Shot_2020-07-08_at_11.58.47_AM](/uploads/b658816b4c9f4a02b976b3ae96d1d912/Screen_Shot_2020-07-08_at_11.58.47_AM.png)
Color on rendered wavelet slice close to the contour at RTData=260 (rgb is 170, 172, 0):
![Screen_Shot_2020-07-08_at_11.59.17_AM](/uploads/e193474c3ecc49382d54611f5e75e9b6/Screen_Shot_2020-07-08_at_11.59.17_AM.png)
In these pictures, I am zoomed in to the portion of the wavelet that I would expect to have brighter/more saturated colors, but the colors do not seem to match. In fact, there isn't any portion of the wavelet that looks like it's the right color according to the color bar.
The colors are still off in an uncompressed "Save Screenshot":
![waveletZoomedIn](/uploads/fcab482a35456beafe8d70171f64abea/waveletZoomedIn.png)
I believe this is the cause of the ColorMoves issue [here](https://github.com/ascr-ecx/colormoves/issues/17)https://gitlab.kitware.com/paraview/paraview/-/issues/18143Output messages: Failed to compute left/right minimum bearings for "Courier"2020-07-07T10:22:20-04:00Ghost UserOutput messages: Failed to compute left/right minimum bearings for "Courier"I am using the [arch linux package](https://www.archlinux.org/packages/community/x86_64/paraview/) version 5.5.0-1.
When I open paraview, I get the following errors in the Output Messages window:
`Failed to compute left/right minimum b...I am using the [arch linux package](https://www.archlinux.org/packages/community/x86_64/paraview/) version 5.5.0-1.
When I open paraview, I get the following errors in the Output Messages window:
`Failed to compute left/right minimum bearings for "Courier"`
It pops up every time I load a file or apply a filter. How can I suppress this message?https://gitlab.kitware.com/paraview/paraview/-/issues/20017backport patches for paraview 5.8.12020-07-02T11:43:56-04:00Julien Schuellerbackport patches for paraview 5.8.1hello,
I noticed 5.8.1-RC1 is out, but these patches are still needed to fix compilation with latest dependencies (eg archlinux) OR cross-compiling (eg mingw):
- https://gitlab.kitware.com/vtk/vtk/merge_requests/6811 (hdf5 1.10.x API...hello,
I noticed 5.8.1-RC1 is out, but these patches are still needed to fix compilation with latest dependencies (eg archlinux) OR cross-compiling (eg mingw):
- https://gitlab.kitware.com/vtk/vtk/merge_requests/6811 (hdf5 1.10.x API fix)
- https://gitlab.kitware.com/paraview/paraview/-/commit/3d48a287141eb911b4888440e09c262743b4db3c (cgns 4.1 fix)
- https://gitlab.kitware.com/vtk/vtk/merge_requests/6406 (ogg/theora cmake fix)
- https://gitlab.kitware.com/vtk/vtk/merge_requests/6301 (vtk wide string path fix)
Could these be backported to the relevant branches so that no patching is necessary on final release ?https://gitlab.kitware.com/paraview/paraview/-/issues/20051Edges visible on backface depending on the aspect ratio of the geometry2020-07-01T16:42:06-04:00Florian MaurinEdges visible on backface depending on the aspect ratio of the geometryDepending on the aspect ratio of the geometry, the edges on the backface of the geometry can be visible whereas the opacity is 1. But I don't think it is a problem of opacity, more a problem of edges vs aspect ratio.
This issue is simila...Depending on the aspect ratio of the geometry, the edges on the backface of the geometry can be visible whereas the opacity is 1. But I don't think it is a problem of opacity, more a problem of edges vs aspect ratio.
This issue is similar to https://gitlab.kitware.com/paraview/paraview/-/issues/19723, but I am running on Paraview 5.8.1 RC1 and I have already observed the benefits of this fix for the representation in general (but not the issue reported here!).
To reproduce:
* Source -> unstructured cell type -> apply
* Change the representation to surface with edges
* Select hex with a grid of 1 x 10 x 1000, apply. See the spurious edges on the blackface of the first picture
* Select hex with a grid of 1 x 10 x 10, apply. Everything looks ok, see the second picture.
![grid1x10x1000](/uploads/7da379c5ea03e134cb38ee327b78012f/grid1x10x1000.png)
![grid1x10x10](/uploads/689d4f28403164a2f0adba111e731177/grid1x10x10.png)