ParaView issueshttps://gitlab.kitware.com/paraview/paraview/-/issues2020-12-14T08:20:09-05:00https://gitlab.kitware.com/paraview/paraview/-/issues/20052TimeValue field data is wrong for vtkNonOverlappingAMR files written in Catalyst2020-12-14T08:20:09-05:00Boonthanome NouanesengsyTimeValue field data is wrong for vtkNonOverlappingAMR files written in CatalystThe Pagosa adaptor uses Catalyst to write vtkNonOverlappingAMR files as .vth files. TimeValue is a standard field data added by Catalyst and XML writers to store time information.
We are trying to store simulation time in TimeValue in ...The Pagosa adaptor uses Catalyst to write vtkNonOverlappingAMR files as .vth files. TimeValue is a standard field data added by Catalyst and XML writers to store time information.
We are trying to store simulation time in TimeValue in vth files. The problem is that TimeValue is correct for the first timestep, but stays the same value for each timestep afterwards. I have attached an example dataset. In the example dataset, if you open the .vth files in a text editor and see the TimeValue entry, you can check the min and max range and see that TimeValue is always the same.
Example dataset: [GridCellData.tar.gz](/uploads/9c1206d08b9a45dc495184337570139f/GridCellData.tar.gz)
```
GridCellData_1.vth, TimeValue=1.002
GridCellData_2.vth, TimeValue=1.002
GridCellData_3.vth, TimeValue=1.002
etc...
```
There are two places where TimeValue is being added: 1) in the Catalyst code (vtkCPProcessor.cxx, line 250) and 2) XML writers.
I checked the code in Catalyst, and TimeValue seems to be set to the correct time there.
It is in the XML writers where the problem seems to occur. Specifically, in vtkXMLCompositeDataWriter.cxx, function WriteData(), where the TimeValue field data is getting added. If you query the time being used there, it is the wrong time.
The strange thing is that if I query the time of the grid at any point in the adaptor or catalyst python script, it shows the correct time. Somehow by the time the code gets to the XML writer, querying the time gives the wrong answer.
Also, sometimes I see this warning when running. Seems likely to be related.
`( 13.808s) [pvbatch.9 ]vtkPVTrivialProducer.cx:95 WARN| vtkPVTrivialProducer (0xf950250): Requesting time 5.50247 but only 1.00257 is available`
The Pagosa adaptor also writes out vtm files. The vtm files do no have this issue. TimeValue has the correct time. Also, the vth files have vti files associated with them. Those vti files also have the right time. It's something specific to the .vth file.
Note: When I say "query the time", I mean something like the below code. It's exactly how the code which adds TimeValue get the time.
`double time = grid->GetInformation()->Get(vtkDataObject::DATA_TIME_STEP());`
@patchett2002 @cory.quammen
How to Reproduce
-----------------------------
Example dataset: [GridCellData.tar.gz](/uploads/9c1206d08b9a45dc495184337570139f/GridCellData.tar.gz)
Catalyst python script: [CoProcess_vth.py](/uploads/49b84d842d1066b39c2deb298001e633/CoProcess_vth.py)
Miniapp script: [filedriver_miniapp.py](/uploads/5278610bc8073da11673fb41039764a1/filedriver_miniapp.py)
I have modified `filedriver_miniapp.py` from the original so that it sets the time to be 0, 1, 2, etc., independent of what the time was in the original files that were read in. So you would expect in the resulting files to have `TimeValue` of 0, 1, 2, etc.
To run, use the command
`pvpython filedriver_miniapp.py -g "GridCellData/*.vth" -s CoProcess_vth.py`
The resulting files will be in a directory called `pv_files`. Load the .vth files in a text editor, and inspect the `TimeValue` xml entry. `TimeValue` will be 0 for all .vth files.5.9 (Fall 2020)Utkarsh AyachitUtkarsh Ayachithttps://gitlab.kitware.com/paraview/paraview/-/issues/20045File path is not updating on macOS Paraview 5.8.02020-10-27T21:23:31-04:00lorak41File path is not updating on macOS Paraview 5.8.0File path is not updating in the file explorer when using Navigate Up.
(macOS 10.15.5, Paraview 5.8.0)
![Jun-30-2020_17-49-47](/uploads/6c105860a1ad38d5350b4dfb0f78b368/Jun-30-2020_17-49-47.gif)File path is not updating in the file explorer when using Navigate Up.
(macOS 10.15.5, Paraview 5.8.0)
![Jun-30-2020_17-49-47](/uploads/6c105860a1ad38d5350b4dfb0f78b368/Jun-30-2020_17-49-47.gif)5.9 (Fall 2020)Cory Quammencory.quammen@kitware.comCory Quammencory.quammen@kitware.comhttps://gitlab.kitware.com/paraview/paraview/-/issues/19994Plot Over Line Crash if Inherite Representation Properties enabled2020-10-14T02:50:20-04:00ym jiaPlot Over Line Crash if Inherite Representation Properties enabledTo Reproduce(5.7 or later, 5.6 will not crash):
0. Settings -> General -> Check 'Inherit Representation Properties'
1. load a png image
2. filter->plot over line
3. applyTo Reproduce(5.7 or later, 5.6 will not crash):
0. Settings -> General -> Check 'Inherit Representation Properties'
1. load a png image
2. filter->plot over line
3. applyYohann Bearzi (Kitware)Yohann Bearzi (Kitware)https://gitlab.kitware.com/paraview/paraview/-/issues/19963ParaView 5.8 crashes when slicing nested multi-block in parallel2024-02-27T05:02:02-05:00Jean M. FavreParaView 5.8 crashes when slicing nested multi-block in parallelCreating the first slice works fine, but ParaView crashes as soon as I interactively drag the slicing plane. My dataset is a nested multi-block with empty blocks except one block, which is an Unstructuredgrid. I have extracted a very sma...Creating the first slice works fine, but ParaView crashes as soon as I interactively drag the slicing plane. My dataset is a nested multi-block with empty blocks except one block, which is an Unstructuredgrid. I have extracted a very small version of the data to use as a reproducer.
untar the file and load in parallel (2 pvserver tasks are enough to crash)
[crash.vtm.tar](/uploads/d11717d0228e2333bd62f3b719ff0d4f/crash.vtm.tar)5.8.1Utkarsh AyachitUtkarsh Ayachithttps://gitlab.kitware.com/paraview/paraview/-/issues/19918PolyLine source points can't be changed manually in the GUI2020-06-04T21:41:06-04:00Mathieu Westphal (Kitware)PolyLine source points can't be changed manually in the GUI * run ParaView
* Sources -> PolyLine Source
* Points location can be edited be on validation, the value is reseted
A workaround is to use python with
```
p = GetActiveSource()
p.Points = [0.0, 1.0, 0.0, 1.0, 0.0, 0.0]
```
5.8.0 an... * run ParaView
* Sources -> PolyLine Source
* Points location can be edited be on validation, the value is reseted
A workaround is to use python with
```
p = GetActiveSource()
p.Points = [0.0, 1.0, 0.0, 1.0, 0.0, 0.0]
```
5.8.0 and master.5.8.1Cory Quammencory.quammen@kitware.comCory Quammencory.quammen@kitware.comhttps://gitlab.kitware.com/paraview/paraview/-/issues/19910slice offset does nothing2020-06-02T07:52:12-04:00W. Alan Scottslice offset does nothingSlice offset does nothing. Here is how to replicate:
* master, and also 5.8.0, Linux, builtin server.
* disk_out_ref.exo. Turn on variables. Apply.
* Slice. Apply.
* Change the offset to a million, 1e6. Apply.
Nothing happens.Slice offset does nothing. Here is how to replicate:
* master, and also 5.8.0, Linux, builtin server.
* disk_out_ref.exo. Turn on variables. Apply.
* Slice. Apply.
* Change the offset to a million, 1e6. Apply.
Nothing happens.5.10 (Fall 2021)Vicente Boleavicente.bolea@kitware.comVicente Boleavicente.bolea@kitware.comhttps://gitlab.kitware.com/paraview/paraview/-/issues/19908Cell size filter dies with CTH AMR2020-05-19T21:22:57-04:00W. Alan ScottCell size filter dies with CTH AMRThe cell size filter is dying when run on a CTH AMR dataset. Here is how to replicate:
* master 5/1/2020 (and 5.8.0), Linux, local server.
* Load spcta_a.4.[0-3]. All vars on. Apply. (I believe this is called something like dave's sm...The cell size filter is dying when run on a CTH AMR dataset. Here is how to replicate:
* master 5/1/2020 (and 5.8.0), Linux, local server.
* Load spcta_a.4.[0-3]. All vars on. Apply. (I believe this is called something like dave's small cth at Kitware).
* cell size filter. Unselect everything other than Compute Volume. Apply.
Crash.
This is an important filter for CTH, since it could be used to calculate density.
@cory.quammen Could we possibly move this one to 5.8.1?5.8.1Cory Quammencory.quammen@kitware.comCory Quammencory.quammen@kitware.comhttps://gitlab.kitware.com/paraview/paraview/-/issues/19880Glyph filter sometimes produces misplaced arrows2020-05-19T21:27:14-04:00DavidGlyph filter sometimes produces misplaced arrowsThis issue is from the discussion in [a thread on the ParaView forums.](https://discourse.paraview.org/t/misplaced-arrows-from-glyph-filter-in-5-8-0-under-linux/4160)
It's arising under Linux, 64-bit, 5.8.0 build downloaded from paravie...This issue is from the discussion in [a thread on the ParaView forums.](https://discourse.paraview.org/t/misplaced-arrows-from-glyph-filter-in-5-8-0-under-linux/4160)
It's arising under Linux, 64-bit, 5.8.0 build downloaded from paraview.org, and also occurs on a nightly build from 28th April.
Summary: After reading a VTU file with Int32 as the types for the connectivity and offset arrays, the Glyph filter when run on cell data sometimes produces arrows in incorrect places where there are no cells. It is not consistent; changing, e.g., the glyph scaling and re-applying will change the location of the arrows that are produced. If the VTU file uses Int64 for the types of connectivity and offset but is otherwise identical, then the issue does not arise.
Steps to reproduce:
1. Open the attached cleaned32.vtu and apply
2. Select current and surface with edges, reduce opacity to 0.2 so the glyphs can be seen
3. Filters->Glyph, select orientation array current_dir, no scale array, scale factor 5, all points, apply
4. If need be, switch back and forth between scale factor 4 + apply and scale factor 5 + apply a few times. At some point you’ll see the misplaced arrows.
Example picture of the problem (not always reproduced exactly):
![misplaced](/uploads/0290b0da9995140be66da28ca10cedc8/misplaced.png)
The issue does not occur if you use cleaned.vtu (which has Int64 as the offset and connectivity type).
[cleaned32.vtu](/uploads/3d56ba8a7a05414a0518d4d08b8e81d9/cleaned32.vtu)
[cleaned.vtu](/uploads/e1fbb08e9787764983b1e44322c9bdab/cleaned.vtu)5.8.1https://gitlab.kitware.com/paraview/paraview/-/issues/19810Crash on View -> Output Messages during reverse connection2020-04-27T11:17:29-04:00Ethan StamCrash on View -> Output Messages during reverse connectionParaView 5.8.0 from paraview.org/downloads, MacOS 10.14.6
ParaView crashes when trying to show the output messages window while waiting for a reverse connection. Note: this is only happening when the output messages pane was previously ...ParaView 5.8.0 from paraview.org/downloads, MacOS 10.14.6
ParaView crashes when trying to show the output messages window while waiting for a reverse connection. Note: this is only happening when the output messages pane was previously docked within the ParaView GUI. If the pane is separate, it doesn't crash. See the video examples below:
Note: This also crashes with Export Inspector (docked and undocked) and the Memory Inspector (docked)
Docked:
![docked](/uploads/dc8e2d97c2448ba50d14e273a8c86670/docked.mov)
Not docked:
![undocked](/uploads/4f9029769604d6a9f7b3336c9551eb76/undocked.mov)5.8.1Cory Quammencory.quammen@kitware.comCory Quammencory.quammen@kitware.comhttps://gitlab.kitware.com/paraview/paraview/-/issues/19787Build of vtkhdf5 fails: missing H5Tinit.c2021-06-22T21:34:43-04:00Mathieu Westphal (Kitware)Build of vtkhdf5 fails: missing H5Tinit.cClean build. March 23, 2020.
```
rm -rf ./*
cmake -G Ninja -DPARAVIEW_USE_MPI=ON -DVTK_SMP_IMPLEMENTATION_TYPE=TBB ../paraview
ninja
```
```
[1903/5533] Building C object VTK/ThirdParty/hdf5/vtkhdf5/src/CMakeFiles/vtkhdf5_src.dir/__/...Clean build. March 23, 2020.
```
rm -rf ./*
cmake -G Ninja -DPARAVIEW_USE_MPI=ON -DVTK_SMP_IMPLEMENTATION_TYPE=TBB ../paraview
ninja
```
```
[1903/5533] Building C object VTK/ThirdParty/hdf5/vtkhdf5/src/CMakeFiles/vtkhdf5_src.dir/__/H5Tinit.c.o
FAILED: VTK/ThirdParty/hdf5/vtkhdf5/src/CMakeFiles/vtkhdf5_src.dir/__/H5Tinit.c.o
/usr/bin/cc -DH5_BUILT_AS_DYNAMIC_LIB -Dhdf5_shared_EXPORTS -Dvtkhdf5_src_EXPORTS -I/home/glow/work/paraview/paraviewThird/paraview/VTK/ThirdParty/hdf5/vtkhdf5/src -IVTK/ThirdParty/hdf5/vtkhdf5 -IVTK/ThirdParty/hdf5/vtkhdf5/src -IVTK/ThirdParty/zlib/vtkzlib -I/home/glow/work/paraview/paraviewThird/paraview/VTK/ThirdParty/zlib/vtkzlib -isystem VTK/ThirdParty/zlib -isystem /home/glow/work/paraview/paraviewThird/paraview/VTK/ThirdParty/zlib -std=c99 -Wall -Wextra -Wshadow -Og -ftrapv -fno-common -pedantic -Wall -Wextra -fmessage-length=0 -g -fPIC -std=gnu99 -MD -MT VTK/ThirdParty/hdf5/vtkhdf5/src/CMakeFiles/vtkhdf5_src.dir/__/H5Tinit.c.o -MF VTK/ThirdParty/hdf5/vtkhdf5/src/CMakeFiles/vtkhdf5_src.dir/__/H5Tinit.c.o.d -o VTK/ThirdParty/hdf5/vtkhdf5/src/CMakeFiles/vtkhdf5_src.dir/__/H5Tinit.c.o -c VTK/ThirdParty/hdf5/vtkhdf5/H5Tinit.c
cc: error: VTK/ThirdParty/hdf5/vtkhdf5/H5Tinit.c: No such file or directory
cc: fatal error: no input files
compilation terminated.
[1912/5533] Building CXX object VTK/Render
```
```
ls ../paraview/VTK/ThirdParty/hdf5/vtkhdf5/H5Tinit.c
ls: cannot access '../paraview/VTK/ThirdParty/hdf5/vtkhdf5/H5Tinit.c': No such file or directory
```
`VTK_MODULE_USE_EXTERNAL_VTK_hdf5 = ON` is a work around.` ninja -j 1` is another.
@ben.boeckelMartin Diehlmartin.diehl@kuleuven.beMartin Diehlmartin.diehl@kuleuven.behttps://gitlab.kitware.com/paraview/paraview/-/issues/19707Color Map Mapping Data histogram gets confused2020-06-04T21:38:36-04:00W. Alan ScottColor Map Mapping Data histogram gets confusedThere is a case where the color map mapping data histogram gets confused. Here is how to replicate:
* 5.8.0, Windows, builtin server.
* Sources/ Wavelet. Apply.
* Color by RDTdata, Representation Surface.
* Color map editor.
* Display ...There is a case where the color map mapping data histogram gets confused. Here is how to replicate:
* 5.8.0, Windows, builtin server.
* Sources/ Wavelet. Apply.
* Color by RDTdata, Representation Surface.
* Color map editor.
* Display data histogram.
* Automatically recompute data for histogram.
* Turn OFF Display data histogram.
Now, the Automatically recompute data histogram button should turn off.
* Grab the left, Min color legend control in the Mapping Data. Drag it into the middle.
The Histogram appears. This is a bug.5.8.1Cory Quammencory.quammen@kitware.comCory Quammencory.quammen@kitware.comhttps://gitlab.kitware.com/paraview/paraview/-/issues/19688Pressing OpenVR plugin closes the ParaView2023-03-01T11:58:17-05:00Samanvith APressing OpenVR plugin closes the ParaViewI have loaded the OpenVR plugin. Now, whenever I try to press the send to OpenVR the ParaView closes automatically.
My ParaView version - ParaView-5.8.0-RC3-Windows-Python3.7-msvc2015-64bitI have loaded the OpenVR plugin. Now, whenever I try to press the send to OpenVR the ParaView closes automatically.
My ParaView version - ParaView-5.8.0-RC3-Windows-Python3.7-msvc2015-64bithttps://gitlab.kitware.com/paraview/paraview/-/issues/19660SPHVolumeInterpolator and PointVolumeInterpolator have their 3D Bounding Box ...2021-08-11T12:23:00-04:00Jean M. FavreSPHVolumeInterpolator and PointVolumeInterpolator have their 3D Bounding Box widget offset from the input dataEasy to reproduce for V5.8-RC2:
Wavelet + CleanToGrid + SPHVolumeInterpolator
the 3D cuboid widget is not centered over the volume, but appears to be centered on the 0-th point of the grid
N.B. The SPHLine- and SPHPlane- interpolators...Easy to reproduce for V5.8-RC2:
Wavelet + CleanToGrid + SPHVolumeInterpolator
the 3D cuboid widget is not centered over the volume, but appears to be centered on the 0-th point of the grid
N.B. The SPHLine- and SPHPlane- interpolators are correctly centered over the volume5.10 (Fall 2021)Utkarsh AyachitUtkarsh Ayachithttps://gitlab.kitware.com/paraview/paraview/-/issues/19624Right click set block opacity does not work2020-02-03T15:10:23-05:00Ethan StamRight click set block opacity does not workParaView nightly binary on MacOS 10.14.6
Setting any opacity less than one on a block causes it to disappear.
Steps to reproduce:
* Open can.ex2 example data, Apply
* Right click on either block in RenderView1
* Set opacity to 0.5 a...ParaView nightly binary on MacOS 10.14.6
Setting any opacity less than one on a block causes it to disappear.
Steps to reproduce:
* Open can.ex2 example data, Apply
* Right click on either block in RenderView1
* Set opacity to 0.5 and click OK. The block disappears
![Screen_Recording_2020-01-27_at_12.32.22_PM](/uploads/71c315e460ff1b61dc629b31efc35d26/Screen_Recording_2020-01-27_at_12.32.22_PM.mov)5.8 (Winter 2020)Cory Quammencory.quammen@kitware.comCory Quammencory.quammen@kitware.comhttps://gitlab.kitware.com/paraview/paraview/-/issues/19588Spreadsheet displays incorrect values for field data in Paraview 5.72020-01-31T20:12:44-05:00Loïc BertheSpreadsheet displays incorrect values for field data in Paraview 5.7With Paraview 5.7, the spreadsheet displays incorrects values for field data.
Here is a test file showing the problem : [test_FieldData.xdmf](/uploads/7a2920380e0993b106f369ee1a4fb7f5/test_FieldData.xdmf).
You will find below two scr...With Paraview 5.7, the spreadsheet displays incorrects values for field data.
Here is a test file showing the problem : [test_FieldData.xdmf](/uploads/7a2920380e0993b106f369ee1a4fb7f5/test_FieldData.xdmf).
You will find below two screenshots of the spreadsheet in Paraview 5.5 and paraview 5.7 :
![Test_paraview-5.5](/uploads/75652da3fc0446d233d8656ebfcd6935/Test_paraview-5.5.png)
--> Paraview 5.5 displays field data correctly
![Test_paraview-5.7](/uploads/bc43876fc769ba34c8bc96ecf2ec0102/Test_paraview-5.7.png)
--> Paraview 5.7 displays incorrects values
Best regards,
Loïc5.8 (Winter 2020)Utkarsh AyachitUtkarsh Ayachithttps://gitlab.kitware.com/paraview/paraview/-/issues/19574"Hover points on" and "Hover cells on" and interactive selection not updated...2023-11-16T18:36:18-05:00Florian Maurin"Hover points on" and "Hover cells on" and interactive selection not updated when switching geometriesTo reproduce the bug:
* Open the two geometries attached
[triangle_stress_1.vtu](/uploads/b5f48ba74765219f3305b3c36d60dd53/triangle_stress_1.vtu)
[triangle_stress_2.vtu](/uploads/3db1aa4ac89cc8b18a4fe64623b72e43/triangle_stress_2.vtu)
* ...To reproduce the bug:
* Open the two geometries attached
[triangle_stress_1.vtu](/uploads/b5f48ba74765219f3305b3c36d60dd53/triangle_stress_1.vtu)
[triangle_stress_2.vtu](/uploads/3db1aa4ac89cc8b18a4fe64623b72e43/triangle_stress_2.vtu)
* Select the first one (triangle_stress_1)
* Clic on "Hover points on", move the mouse to an edge of the triangle. The indicated stress should be 1.
* Select the second file (triangle_stress_2), and deselect the first file (the order of the operation is here important).
* Move the mouse to an edge. The indicated stress is 1, whereas it should be 2!
See the picture below, where the scale indicates a stress of 2 (the expected value), whereas the stress reported by "Hover points on" is 1.
If the order of the operation is deselect the first file, and then select the second one, the correct stress is reported in "Hover points on".
My Paraview version is the development one that was on master Yesterday, so just before it was forked to 5.8 RC1.
This issue seams to be related to this one https://gitlab.kitware.com/paraview/paraview/issues/19177 and https://gitlab.kitware.com/paraview/paraview/issues/18313 .
![HoverPointsOnBug](/uploads/fa3917be6412ea4f0f12e77363fdf904/HoverPointsOnBug.png)Spiros TsalikisSpiros Tsalikishttps://gitlab.kitware.com/paraview/paraview/-/issues/19505TemporalCache segfault when not using "SnapToTimeSteps" animation mode2020-10-22T11:40:03-04:00Mathieu Westphal (Kitware)TemporalCache segfault when not using "SnapToTimeSteps" animation modeTemporalCache segfault when not using "SnapToTimeSteps" animation mode
Steps to reproduce :
* Open ParaView
* Open can.ex2 or any temporal dataset
* View -> Animation View
* Change snap to time step to RealTime or Sequence
* Chang...TemporalCache segfault when not using "SnapToTimeSteps" animation mode
Steps to reproduce :
* Open ParaView
* Open can.ex2 or any temporal dataset
* View -> Animation View
* Change snap to time step to RealTime or Sequence
* Change time step
* Segfault
```
Thread 1 "paraview" received signal SIGSEGV, Segmentation fault.
vtkTemporalDataSetCache::RequestData (this=0x55555c4e05a0, inputVector=0x55555b7f9240, outputVector=0x55555c4e4890) at /home/glow/work/paraview/paraviewThird/paraview/VTK/Filters/Hybrid/vtkTemporalDataSetCache.cxx:298
298 output->GetInformation()->Set(vtkDataObject::DATA_TIME_STEP(), upTime);
(gdb) bt
#0 vtkTemporalDataSetCache::RequestData (this=0x55555c4e05a0, inputVector=0x55555b7f9240, outputVector=0x55555c4e4890) at /home/glow/work/paraview/paraviewThird/paraview/VTK/Filters/Hybrid/vtkTemporalDataSetCache.cxx:298
#1 0x00007fffeb2ea535 in vtkTemporalDataSetCache::ProcessRequest (this=0x55555c4e05a0, request=0x55555c67e130, inputVector=0x55555b7f9240, outputVector=0x55555c4e4890)
at /home/glow/work/paraview/paraviewThird/paraview/VTK/Filters/Hybrid/vtkTemporalDataSetCache.cxx:63
#2 0x00007fffef1a6bc5 in vtkExecutive::CallAlgorithm (this=0x55555c428c60, request=0x55555c67e130, direction=1, inInfo=0x55555b7f9240, outInfo=0x55555c4e4890)
at /home/glow/work/paraview/paraviewThird/paraview/VTK/Common/ExecutionModel/vtkExecutive.cxx:746
#3 0x00007fffef19ecd8 in vtkDemandDrivenPipeline::ExecuteData (this=0x55555c428c60, request=0x55555c67e130, inInfo=0x55555b7f9240, outInfo=0x55555c4e4890)
at /home/glow/work/paraview/paraviewThird/paraview/VTK/Common/ExecutionModel/vtkDemandDrivenPipeline.cxx:462
#4 0x00007fffef19399b in vtkCompositeDataPipeline::ExecuteData (this=0x55555c428c60, request=0x55555c67e130, inInfoVec=0x55555b7f9240, outInfoVec=0x55555c4e4890)
at /home/glow/work/paraview/paraviewThird/paraview/VTK/Common/ExecutionModel/vtkCompositeDataPipeline.cxx:161
#5 0x00007fffef19e3c0 in vtkDemandDrivenPipeline::ProcessRequest (this=0x55555c428c60, request=0x55555c67e130, inInfoVec=0x55555b7f9240, outInfoVec=0x55555c4e4890)
at /home/glow/work/paraview/paraviewThird/paraview/VTK/Common/ExecutionModel/vtkDemandDrivenPipeline.cxx:261
#6 0x00007fffef208692 in vtkStreamingDemandDrivenPipeline::ProcessRequest (this=0x55555c428c60, request=0x55555c67e130, inInfoVec=0x55555b7f9240, outInfoVec=0x55555c4e4890)
at /home/glow/work/paraview/paraviewThird/paraview/VTK/Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.cxx:343
#7 0x00007fffef196251 in vtkCompositeDataPipeline::ForwardUpstream (this=0x555559f5ef70, request=0x55555c67e130) at /home/glow/work/paraview/paraviewThird/paraview/VTK/Common/ExecutionModel/vtkCompositeDataPipeline.cxx:726
#8 0x00007fffef19e2bc in vtkDemandDrivenPipeline::ProcessRequest (this=0x555559f5ef70, request=0x55555c67e130, inInfoVec=0x55555b975e90, outInfoVec=0x55555b9673a0)
at /home/glow/work/paraview/paraviewThird/paraview/VTK/Common/ExecutionModel/vtkDemandDrivenPipeline.cxx:247
#9 0x00007fffef208692 in vtkStreamingDemandDrivenPipeline::ProcessRequest (this=0x555559f5ef70, request=0x55555c67e130, inInfoVec=0x55555b975e90, outInfoVec=0x55555b9673a0)
at /home/glow/work/paraview/paraviewThird/paraview/VTK/Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.cxx:343
#10 0x00007fffef196251 in vtkCompositeDataPipeline::ForwardUpstream (this=0x55555c961f10, request=0x55555c67e130) at /home/glow/work/paraview/paraviewThird/paraview/VTK/Common/ExecutionModel/vtkCompositeDataPipeline.cxx:726
#11 0x00007ffff5b61730 in vtkPVDataRepresentationPipeline::ForwardUpstream (this=0x55555c961f10, request=0x55555c67e130)
at /home/glow/work/paraview/paraviewThird/paraview/ParaViewCore/ClientServerCore/Rendering/vtkPVDataRepresentationPipeline.cxx:56
#12 0x00007fffef19e2bc in vtkDemandDrivenPipeline::ProcessRequest (this=0x55555c961f10, request=0x55555c67e130, inInfoVec=0x55555c7821a0, outInfoVec=0x55555c95c320)
at /home/glow/work/paraview/paraviewThird/paraview/VTK/Common/ExecutionModel/vtkDemandDrivenPipeline.cxx:247
#13 0x00007fffef208692 in vtkStreamingDemandDrivenPipeline::ProcessRequest (this=0x55555c961f10, request=0x55555c67e130, inInfoVec=0x55555c7821a0, outInfoVec=0x55555c95c320)
at /home/glow/work/paraview/paraviewThird/paraview/VTK/Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.cxx:343
```https://gitlab.kitware.com/paraview/paraview/-/issues/19503Multiblock inspector has a small bug when choosing a color which is default2020-06-16T17:35:11-04:00Mathieu Westphal (Kitware)Multiblock inspector has a small bug when choosing a color which is defaultWhen choosing a color for a block, if willing to color in black, the color is not applied.
Steps to reproduce :
* Open ParaView
* Open a multiblock dataset, Apply
* View -> Multiblock inspector
* Double click on the color watch of ...When choosing a color for a block, if willing to color in black, the color is not applied.
Steps to reproduce :
* Open ParaView
* Open a multiblock dataset, Apply
* View -> Multiblock inspector
* Double click on the color watch of a block, the color dialog shows up
* Choose black as a color (it is the default), Ok, **nothing happens**
* Double click on the color watch of a block, the color dialog shows up
* Choose black as a color , Ok, black is correctly applied.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/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
Florian