ParaView issueshttps://gitlab.kitware.com/paraview/paraview/-/issues2020-10-01T21:17:29-04:00https://gitlab.kitware.com/paraview/paraview/-/issues/19953Weird progress events on delete2020-10-01T21:17:29-04:00Utkarsh AyachitWeird progress events on delete* Open SAND2017-5827O-FSM_Residual_good-eigen.e, select all variable, apply
* Now delete it, you'll see progress bar updating as the delete happens! that's a bug!
Reverting f107c6b740279a47fa348bee6b99365c59b22106 fixes the issue. Thus...* Open SAND2017-5827O-FSM_Residual_good-eigen.e, select all variable, apply
* Now delete it, you'll see progress bar updating as the delete happens! that's a bug!
Reverting f107c6b740279a47fa348bee6b99365c59b22106 fixes the issue. Thus, caused by fix for #193765.9 (Fall 2020)Utkarsh AyachitUtkarsh Ayachithttps://gitlab.kitware.com/paraview/paraview/-/issues/20180vtkByteSwap.cxx is extremely inefficient2020-10-01T21:02:55-04:00W. Alan ScottvtkByteSwap.cxx is extremely inefficientvtkByteSwap.cxx is extremely inefficient. Here is a much faster chunk of code.[byteSwap.dif](/uploads/bfc47fd0feec4720df9d674ba365b8e6/byteSwap.dif)vtkByteSwap.cxx is extremely inefficient. Here is a much faster chunk of code.[byteSwap.dif](/uploads/bfc47fd0feec4720df9d674ba365b8e6/byteSwap.dif)5.9 (Fall 2020)Yohann Bearzi (Kitware)Yohann Bearzi (Kitware)https://gitlab.kitware.com/paraview/paraview/-/issues/20160Incorrect ghost-cell removal2020-10-01T20:55:52-04:00Utkarsh AyachitIncorrect ghost-cell removalvtkDataSet subclasses have code to remove ghost cells which is relied upon by vtkPVGeometryFilter to remove ghost cells. vtkPVGeometryFilter especially relies on `vtkPolyData::RemoveGhosteCells`. The code in `vtkPolyData::RemoveGhosteCel...vtkDataSet subclasses have code to remove ghost cells which is relied upon by vtkPVGeometryFilter to remove ghost cells. vtkPVGeometryFilter especially relies on `vtkPolyData::RemoveGhosteCells`. The code in `vtkPolyData::RemoveGhosteCells` does not correctly handle removal of cells marked HIDDENCELL, only handles DUPLICATECELL. This causes the following odd behaviour:
Steps:
1. open disk_out.ref.ex2, all variables, apply
2. Apply "Resample To Image" filter. Choose **Sampling Dimensions** of 16x16x16. Apply
3. Switch representation type to "Surface with Edges", you'll see something like this:
![image](/uploads/b00cd4ef0891b383275b0bee30024aea/image.png)
This is wrong. We should be seeing those regions that are outside the cylinder present in the original dataset. Those cells are indeed being marked as HIDDENCELL by the filter and should have been removed.
Next, try selecting the whole square face using **Select Cells On**.
![image](/uploads/a2c88f970081ef5fb4304f8bd056a49c/image.png)
Notice how only the the non-hidden cells get selected.
For this issue to be resolved, we simply need to extend `vtkPolyData::RemoveGhosteCells` to handle HIDDENCELL. It's a good opportunity to check if any other dataset subclass also has the same bug and resolve it too..5.9 (Fall 2020)Yohann Bearzi (Kitware)Yohann Bearzi (Kitware)https://gitlab.kitware.com/paraview/paraview/-/issues/20143Unexpected behavior of Tube with VaryRadius set to By Vector2020-10-01T20:51:32-04:00Kenneth MorelandUnexpected behavior of Tube with VaryRadius set to By VectorWhen you add the `Tube` filter to, say, the output of the stream tracer and then set the `Vary Radius` parameter to `By Vector`, you get behavior that is probably unexpected for most users.
Based on the labels, I would assume this setup...When you add the `Tube` filter to, say, the output of the stream tracer and then set the `Vary Radius` parameter to `By Vector`, you get behavior that is probably unexpected for most users.
Based on the labels, I would assume this setup would make the tubes wider for vectors with large magnitude and thinner for tubes with small magnitude (i.e. proportional to the speed). However, this is not what you get. Instead, the slower vectors have a wider radius than the faster vectors.
What is happening is that when you select to `Vary Radius` `By Vector`, you get a mass flux preserving variation. This is mentioned in [the VTK filter's doxygen](https://vtk.org/doc/nightly/html/classvtkTubeFilter.html#details), but not implied by the ParaView labels and not documented anywhere in the ParaView help.
At the very least, the label `By Vector` should be changed to help imply the actual behavior. For example, it could say `By Vector (Preserve Mass Flux)`.
It would also be helpful if a mode was added to `vtkTubeFilter` to vary the radius of the tubes proportionally to the magnitude of the vector.5.10 (Fall 2021)Yohann Bearzi (Kitware)Yohann Bearzi (Kitware)https://gitlab.kitware.com/paraview/paraview/-/issues/17134Missing status about filter that cannot be applied2020-10-01T03:08:07-04:00Mathieu Westphal (Kitware)Missing status about filter that cannot be appliedSome time before (works in 5.2, doesn't on master), it was possible to see why a filter cannot be applied when floating over the menu item.
It was visible in the status bar.
Now it does not appear at all.Some time before (works in 5.2, doesn't on master), it was possible to see why a filter cannot be applied when floating over the menu item.
It was visible in the status bar.
Now it does not appear at all.https://gitlab.kitware.com/paraview/paraview/-/issues/20240Warray-bounds warning on taanab2020-09-30T22:00:25-04:00Mickael PHILITWarray-bounds warning on taanabTaanab is generating a false positive warning.
- dim is of size 9.
- j should be lower than 4
- k should be lower than 3
- i should be lower than 3
- jmax * kmax + imax = 3 * 2 + 2 = 8 < 9
`
/home/kitware/Dashboards/slave/paraview_mas...Taanab is generating a false positive warning.
- dim is of size 9.
- j should be lower than 4
- k should be lower than 3
- i should be lower than 3
- jmax * kmax + imax = 3 * 2 + 2 = 8 < 9
`
/home/kitware/Dashboards/slave/paraview_master-taanab-linux-static-release_adios2_mpi_offscreen_osmesa_python3/source/VTKExtensions/CGNSWriter/vtkCGNSWriter.cxx: In static member function 'static bool vtkCGNSWriter::vtkPrivate::WriteStructuredGrid(write_info&, vtkStructuredGrid*, const char*, std::__cxx11::string&)':
[CTest: warning matched] /home/kitware/Dashboards/slave/paraview_master-taanab-linux-static-release_adios2_mpi_offscreen_osmesa_python3/source/VTKExtensions/CGNSWriter/vtkCGNSWriter.cxx:558:20: warning: array subscript is above array bounds [-Warray-bounds]
dim[j * k + i] = dim[3 * k + i];
^
[CTest: warning matched] /home/kitware/Dashboards/slave/paraview_master-taanab-linux-static-release_adios2_mpi_offscreen_osmesa_python3/source/VTKExtensions/CGNSWriter/vtkCGNSWriter.cxx:558:20: warning: array subscript is above array bounds [-Warray-bounds]
[CTest: warning matched] /home/kitware/Dashboards/slave/paraview_master-taanab-linux-static-release_adios2_mpi_offscreen_osmesa_python3/source/VTKExtensions/CGNSWriter/vtkCGNSWriter.cxx:558:37: warning: array subscript is above array bounds [-Warray-bounds]
dim[j * k + i] = dim[3 * k + i];
^
[CTest: warning matched] /home/kitware/Dashboards/slave/paraview_master-taanab-linux-static-release_adios2_mpi_offscreen_osmesa_python3/source/VTKExtensions/CGNSWriter/vtkCGNSWriter.cxx:558:20: warning: array subscript is above array bounds [-Warray-bounds]
dim[j * k + i] = dim[3 * k + i];
^
[CTest: warning matched] /home/kitware/Dashboards/slave/paraview_master-taanab-linux-static-release_adios2_mpi_offscreen_osmesa_python3/source/VTKExtensions/CGNSWriter/vtkCGNSWriter.cxx:558:37: warning: array subscript is above array bounds [-Warray-bounds]
dim[j * k + i] = dim[3 * k + i];
^
[CTest: warning matched] /home/kitware/Dashboards/slave/paraview_master-taanab-linux-static-release_adios2_mpi_offscreen_osmesa_python3/source/VTKExtensions/CGNSWriter/vtkCGNSWriter.cxx:558:20: warning: array subscript is above array bounds [-Warray-bounds]
dim[j * k + i] = dim[3 * k + i];
^
[CTest: warning matched] /home/kitware/Dashboards/slave/paraview_master-taanab-linux-static-release_adios2_mpi_offscreen_osmesa_python3/source/VTKExtensions/CGNSWriter/vtkCGNSWriter.cxx:558:37: warning: array subscript is above array bounds [-Warray-bounds]
dim[j * k + i] = dim[3 * k + i];
^
[CTest: warning matched] /home/kitware/Dashboards/slave/paraview_master-taanab-linux-static-release_adios2_mpi_offscreen_osmesa_python3/source/VTKExtensions/CGNSWriter/vtkCGNSWriter.cxx:558:20: warning: array subscript is above array bounds [-Warray-bounds]
dim[j * k + i] = dim[3 * k + i];
^
[CTest: warning matched] /home/kitware/Dashboards/slave/paraview_master-taanab-linux-static-release_adios2_mpi_offscreen_osmesa_python3/source/VTKExtensions/CGNSWriter/vtkCGNSWriter.cxx:558:37: warning: array subscript is above array bounds [-Warray-bounds]
dim[j * k + i] = dim[3 * k + i];
^
[CTest: warning matched] /home/kitware/Dashboards/slave/paraview_master-taanab-linux-static-release_adios2_mpi_offscreen_osmesa_python3/source/VTKExtensions/CGNSWriter/vtkCGNSWriter.cxx:558:37: warning: array subscript is above array bounds [-Warray-bounds]
[CTest: warning matched] /home/kitware/Dashboards/slave/paraview_master-taanab-linux-static-release_adios2_mpi_offscreen_osmesa_python3/source/VTKExtensions/CGNSWriter/vtkCGNSWriter.cxx:558:37: warning: array subscript is above array bounds [-Warray-bounds]
[CTest: warning matched] /home/kitware/Dashboards/slave/paraview_master-taanab-linux-static-release_adios2_mpi_offscreen_osmesa_python3/source/VTKExtensions/CGNSWriter/vtkCGNSWriter.cxx:558:37: warning: array subscript is above array bounds [-Warray-bounds]
[CTest: warning matched] /home/kitware/Dashboards/slave/paraview_master-taanab-linux-static-release_adios2_mpi_offscreen_osmesa_python3/source/VTKExtensions/CGNSWriter/vtkCGNSWriter.cxx:558:37: warning: array subscript is above array bounds [-Warray-bounds]
[CTest: warning matched] /home/kitware/Dashboards/slave/paraview_master-taanab-linux-static-release_adios2_mpi_offscreen_osmesa_python3/source/VTKExtensions/CGNSWriter/vtkCGNSWriter.cxx:558:20: warning: array subscript is above array bounds [-Warray-bounds]
dim[j * k + i] = dim[3 * k + i];
^
[CTest: warning matched] /home/kitware/Dashboards/slave/paraview_master-taanab-linux-static-release_adios2_mpi_offscreen_osmesa_python3/source/VTKExtensions/CGNSWriter/vtkCGNSWriter.cxx:558:37: warning: array subscript is above array bounds [-Warray-bounds]
dim[j * k + i] = dim[3 * k + i];
^
[CTest: warning matched] /home/kitware/Dashboards/slave/paraview_master-taanab-linux-static-release_adios2_mpi_offscreen_osmesa_python3/source/VTKExtensions/CGNSWriter/vtkCGNSWriter.cxx:558:20: warning: array subscript is above array bounds [-Warray-bounds]
dim[j * k + i] = dim[3 * k + i];
^
`https://gitlab.kitware.com/paraview/paraview/-/issues/20123Extract Generators: disabled items missing status information2020-09-30T19:36:20-04:00Utkarsh AyachitExtract Generators: disabled items missing status informationDisabled items in Extract Generators menu don't show status tip (like the filter menu) with information about why that generator is not available. Need to fix that.Disabled items in Extract Generators menu don't show status tip (like the filter menu) with information about why that generator is not available. Need to fix that.5.9 (Fall 2020)Vicente Boleavicente.bolea@kitware.comVicente Boleavicente.bolea@kitware.comhttps://gitlab.kitware.com/paraview/paraview/-/issues/20188XML partitioned-dataset writer does not work in parallel correctly.2020-09-30T19:14:03-04:00Utkarsh AyachitXML partitioned-dataset writer does not work in parallel correctly.* Connect to pvserver (2 ranks) using ParaView
* Open can.ex2, apply
* Create `Adaptive Resample to Image` filter, Apply.
* Show as `Surface` and color by `vtkProcessId` to confirm there are as many blocks as ranks (2 in this case)
* Sa...* Connect to pvserver (2 ranks) using ParaView
* Open can.ex2, apply
* Create `Adaptive Resample to Image` filter, Apply.
* Show as `Surface` and color by `vtkProcessId` to confirm there are as many blocks as ranks (2 in this case)
* Save data as `foo.vtpd`
Now restart ParaView (as builtin) and load the file that was saved. Either it will fail to load correctly or will only have 1 block. This is a bug.
This is happening because the writer for `vtkPartitionedDataSet` is not parallel aware and each rank ends up overwriting what an other rank wrote.
Same is probably true for vtkPartitionedDataSetCollection.5.10 (Fall 2021)Yohann Bearzi (Kitware)Yohann Bearzi (Kitware)https://gitlab.kitware.com/paraview/paraview/-/issues/19873ExtractSubsetWithSeed missing blocks with pvbatch2020-09-30T19:05:35-04:00W. Alan ScottExtractSubsetWithSeed missing blocks with pvbatchJeff wrapped this one up really well in a directory that I can give Kitware. Lets call it ExtractSubsetWithSeed missing blocks with pvbatch.
Here is what Jeff wrote in the README:
The contents of this directory demonstrate an error wi...Jeff wrapped this one up really well in a directory that I can give Kitware. Lets call it ExtractSubsetWithSeed missing blocks with pvbatch.
Here is what Jeff wrote in the README:
The contents of this directory demonstrate an error with the
ExtractSubsetWithSeed filter in pvbatch/catalyst. In the gui operation,
ExtractSubsetWithSeed successfully follows a path from block to block.
In the pvbatch operation, we only get data from one block. This error occurs
even on single process operation. To see this bug in operation (or for
debugging):
In the gui, open the cgns data set, including cell data. Make an
ExtractSubsetWithSeed filter with seed point [1.0, 0.08685, 0.08685] and
direction 'JK'. Render by surface, color by block and examine.
On the command line, execute the following line (make sure you have access to
pvbatch for paraview 5.8):
pvbatch --symmetric cgns2catalyst.py sparc-volume-1process.cgns -ps do_essws_script_from_gui.py
or
pvbatch cgns2catalyst.py sparc-volume-1process.cgns -ps do_essws_script_from_gui.py
And look at the output image.
(Snip second bug that has not been replicated)
Sending the tarball to Kitware.5.9 (Fall 2020)Utkarsh AyachitUtkarsh Ayachithttps://gitlab.kitware.com/paraview/paraview/-/issues/20169CGNS Reader: revert back to not use subset inclusion lattice for block selection2020-09-30T19:02:56-04:00Utkarsh AyachitCGNS Reader: revert back to not use subset inclusion lattice for block selectionCGNS Reader: revert back to not use subset inclusion lattice for block selection. The SIL is slow and provides unnecessary flexibility at the cost of complexity.
ref: https://discourse.paraview.org/t/cgnsseriesreader-usage-with-python/2...CGNS Reader: revert back to not use subset inclusion lattice for block selection. The SIL is slow and provides unnecessary flexibility at the cost of complexity.
ref: https://discourse.paraview.org/t/cgnsseriesreader-usage-with-python/2673/85.9 (Fall 2020)Utkarsh AyachitUtkarsh Ayachithttps://gitlab.kitware.com/paraview/paraview/-/issues/19831Color legend font sizes wrong with batch2020-09-30T19:00:44-04:00W. Alan ScottColor legend font sizes wrong with batchColor legend font sizes are wrong with batch. Here is how to replicate. I am sure it doesn't matter, but I am going to create a slice, with surface with edges.
* Linux, 5.8.0, builtin server.
* Start trace. Take defaults.
* Load disk_...Color legend font sizes are wrong with batch. Here is how to replicate. I am sure it doesn't matter, but I am going to create a slice, with surface with edges.
* Linux, 5.8.0, builtin server.
* Start trace. Take defaults.
* Load disk_out_ref.exo. All variables on. Apply.
* Slice. Z Normal. Hide plane tool. Apply.
* Color by Temp.
* Surface with Edges.
* Now, drag the color legend to the middle, bottom of the view. I want it to be horizontal.
* Save Screenshot.
* Stop trace. Uncomment the ViewSize command. Save somewhere as myTrace.py.
* Rename your screenshot from above to screenshotOriginal.png
* /.../pvbatch /.../myTrace.py
If you compare the screenshot from pvbatch and the original, you will see that the color legend text is different sizes. This is a bug.
This is possibly related to #198165.9 (Fall 2020)Utkarsh AyachitUtkarsh Ayachithttps://gitlab.kitware.com/paraview/paraview/-/issues/19565External use of hdf5 not easy to implement, and doesn't work.2020-09-30T17:50:45-04:00W. Alan ScottExternal use of hdf5 not easy to implement, and doesn't work.External use of hdf5 not easy to implement, and doesn't work. Here is from an e-mail with @jamauld. This is a followon to bug #19564:
Next, I tried turning VTK_MODULE_ENABLE_VTK_hdf5 back on, but then using
VTK_MODULE_USE_EXTERNAL_...External use of hdf5 not easy to implement, and doesn't work. Here is from an e-mail with @jamauld. This is a followon to bug #19564:
Next, I tried turning VTK_MODULE_ENABLE_VTK_hdf5 back on, but then using
VTK_MODULE_USE_EXTERNAL_VTK_hdf5:BOOL=ON
This successfully found SPARC's hdf5 library and used that for configure.
But then my build failed. When linking the pvserver executable (and a couple others, like maybe pvdataserver), I got undefined symbol errors. The undefined symbols were like H5Create (or H5PCreate or something), and they were undefined in the library
libhdf5_hl.a
when I messed around with the nm command, I discovered that the symbols were undefined in the libhdf5_hl.a library, but they were defined in the libhdf5.a library.
When I looked at the link.txt file for pvserver, I saw that both the libhdf5.a and libhdf5_hl.a were in the link line, but libhdf5.a came first. I added libhdf5.a again after libhdf5_hl.a. Then pvserver linked. Clearly if libhdf5 was shared the order wouldn't have mattered. I don't want to add all symbols for libhdf5.a because that might bloat the binary.
What we need here is a successful compile ordering of the static hdf5 libraries in the link.txt file. Also, it would probably help to be able to specify using system hdf5 libraries up at the superbuild cmake level as well.
Getting either #19564 or this bug fixed is a crisis. We can take either, depending on which is easier, but would prefer getting #19564 fixed first. Setting milestone and labels appropriately.5.9 (Fall 2020)https://gitlab.kitware.com/paraview/paraview/-/issues/20230Update third-party packages2020-09-30T15:53:37-04:00Cory Quammencory.quammen@kitware.comUpdate third-party packagesTodo - Find which packages have newer releases and update.Todo - Find which packages have newer releases and update.5.9 (Fall 2020)https://gitlab.kitware.com/paraview/paraview/-/issues/19333ParaView hangs when reading big CGNS SIL2020-09-30T02:59:13-04:00Mickael PHILITParaView hangs when reading big CGNS SILWhen opening a CGNS file with around 400 CGNS zones, calls to ClearSelections or SetSelections of the SIL class are very slow to process and ends up with the interface hanging.
Initialization of the SIL status is not fast enough.When opening a CGNS file with around 400 CGNS zones, calls to ClearSelections or SetSelections of the SIL class are very slow to process and ends up with the interface hanging.
Initialization of the SIL status is not fast enough.https://gitlab.kitware.com/paraview/paraview/-/issues/19371ParaView ignores Blocks on this dataset2020-09-29T20:37:51-04:00W. Alan ScottParaView ignores Blocks on this datasetMy user gave me a dataset that ignores block selections. This dataset came from a single .g file, then was spread into numerous .g files. The block selection does not work. Here is how to replicate:
* Windows (or Linux), 5.6.0 (or 5.7...My user gave me a dataset that ignores block selections. This dataset came from a single .g file, then was spread into numerous .g files. The block selection does not work. Here is how to replicate:
* Windows (or Linux), 5.6.0 (or 5.7.0), built in server.
* Open the spread dataset, ztest.g.8.[0-7].
* Select only the second and third block (i.e., leave block 98 unselected).
* Apply.
* Compare with selecting all blocks. They are the same. This is a bug.
Dataset is paraview_block_issue.tar.bz2 on Windows. User is Mike W. I can pass this to Cory and/or Utkarsh.
@utkarsh.ayachit @cory.quammen I would appreciate this being looked at as soon as possible (and the contract allows). This may represent a bug on Sandia's code's part, and I would like to give feedback if true.5.9 (Fall 2020)Utkarsh AyachitUtkarsh Ayachithttps://gitlab.kitware.com/paraview/paraview/-/issues/19816FontSize not respected in batch mode2020-09-29T20:31:56-04:00Jean M. FavreFontSize not respected in batch mode
I find it impossible to render Text() objects to fit in the viewport when using pvbatch. Using the GUI, everything fits perfectly well on the screen. When rendered in batch, FontSize are not respected.
[FontSize.py](/uploads/eb123a4f7a...
I find it impossible to render Text() objects to fit in the viewport when using pvbatch. Using the GUI, everything fits perfectly well on the screen. When rendered in batch, FontSize are not respected.
[FontSize.py](/uploads/eb123a4f7a58214c23f9c7c8b2143a68/FontSize.py)5.9 (Fall 2020)Utkarsh AyachitUtkarsh Ayachithttps://gitlab.kitware.com/paraview/paraview/-/issues/20175default_servers.pvsc changed since removable for shared forwarding2020-09-29T20:15:21-04:00Utkarsh Ayachitdefault_servers.pvsc changed since removable for shared forwarding`default_servers.pvsc` was previously searched under lib/.. now it's under bin/....
We should fix this.`default_servers.pvsc` was previously searched under lib/.. now it's under bin/....
We should fix this.5.9 (Fall 2020)Utkarsh AyachitUtkarsh Ayachithttps://gitlab.kitware.com/paraview/paraview/-/issues/19073Save data products on the client, or server, side2020-09-28T20:36:38-04:00W. Alan ScottSave data products on the client, or server, sidePlease add the ability to save data products on the client, or the server side. Default as we have now. This is important for .csv files, where a user is trying to do some data analysis, and wants her data to be local. Alternatively, ...Please add the ability to save data products on the client, or the server side. Default as we have now. This is important for .csv files, where a user is trying to do some data analysis, and wants her data to be local. Alternatively, we have cases where screen shots and movies need to be used on the remote side, and have to be manually copied.
Not sure how important this is at this time. Requested by Watney.5.9 (Fall 2020)https://gitlab.kitware.com/paraview/paraview/-/issues/20234Server which auto launches pvserver fails2020-09-28T18:31:17-04:00Boonthanome NouanesengsyServer which auto launches pvserver failsI am trying to create a server that will launch pvserver automatically. I create a new server, with the external command "mpirun -np 4 \<pvserver\>", where \<pvserver\> is the path to the pvserver executable. When I try to connect to thi...I am trying to create a server that will launch pvserver automatically. I create a new server, with the external command "mpirun -np 4 \<pvserver\>", where \<pvserver\> is the path to the pvserver executable. When I try to connect to this server, it will fail with following message:
```
critical: In unknown, line 0
critical: Command aborted.
```
I think this is probably the same error, but if I have a python script that tries to launch pvserver with mpirun, then that also fails. So if I had a python script with the following:
```
import subprocess
subprocess.call(['mpirun', '-np', str(4), pvserver])
```
If I do `python start_pvserver.py`, that works. If I do `pvpython start_pvserver.py`, that will fail. If I remove mpirun and just have pvserver, that will work.
I'm running on a Mac with Catalina, with OpenMPI 4.0.3. This is on the latest git version of Paraview.
@patchett2002 @cory.quammenhttps://gitlab.kitware.com/paraview/paraview/-/issues/20233Paraview::qttesting error2020-09-28T10:42:47-04:00clm1123Paraview::qttesting errorCMake Error at VTK/CMake/vtkModule.cmake:4993 (message):
The ParaView::qttesting is being built as an internal third party library,
but a matching target was not created.
Call Stack (most recent call first):
ThirdParty/QtTesting/CM...CMake Error at VTK/CMake/vtkModule.cmake:4993 (message):
The ParaView::qttesting is being built as an internal third party library,
but a matching target was not created.
Call Stack (most recent call first):
ThirdParty/QtTesting/CMakeLists.txt:53 (vtk_module_third_party_internal)