VTK-9.0.3, VTKExample-Infovis/Cxx skipped, InfovisBoost missing, 32 tests failed

This is Ubuntu 20.04.2 LTS / x86_64 / gcc 9.3.0 here.

I built the “VTK-9.0.3”.

The “make test” reports: “2116 - VTKExample-Infovis/Cxx (Skipped)
Looking into the “Examples/Infovis/Cxx/CMakeLists.txt” file, I find that all required (and also all optional) VTK package components were built.
So, I cannot find the reason why the “Infovis” examples cannot be built (I tried to build them “manually”, too).
What could be the reason?

The following “Infovis” related modules (shared libraries) were built: “InfovisBoostGraphAlgorithms”, “InfovisCore”, “InfovisLayout”, “IOInfovis”, “ViewsInfovis”.

The initial VTK cmake step does find “Boost”, including the “Boost::serialization” component (after “sudo apt-get install libboost-all-dev”):
-- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake (found version "1.71.0") found components: serialization

However, the “InfovisBoost” module was NOT built (even though I configured VTK adding “-DVTK_MODULE_ENABLE_VTK_InfovisBoost=YES”).
What could be the reason?

Finally, the “make test” reports that 32 tests failed out of 2122. I do not know if these are “known issues” or if there are real problems somewhere (Python 3.8.10 is used):

382 - VTK::InteractionWidgetsCxx-TestOrientationMarkerWidget (Failed)
649 - VTK::FiltersParallelGeometryCxx-MPI-TestPStructuredGridConnectivity (Failed)
650 - VTK::FiltersParallelGeometryCxx-MPI-TestPStructuredGridGhostDataGenerator (Failed)
651 - VTK::FiltersParallelGeometryCxx-MPI-TestPUnstructuredGridGhostCellsGenerator (Failed)
652 - VTK::FiltersParallelGeometryCxx-MPI-TestPUniformGridGhostDataGenerator (Failed)
654 - VTK::FiltersParallelGeometryCxx-MPI-ParallelConnectivity4 (Failed)
655 - VTK::FiltersParallelGeometryCxx-MPI-TestPolyhedralMeshDistributedDataFilter (Failed)
682 - VTK::FiltersHyperTreeCxx-TestHyperTreeGridBinaryEllipseMaterial (Failed)
686 - VTK::FiltersHyperTreeCxx-TestHyperTreeGridTernary2DFullMaterialBits (Failed)
689 - VTK::FiltersHyperTreeCxx-TestHyperTreeGridTernary3DAxisClipBox (Failed)
703 - VTK::FiltersHyperTreeCxx-TestHyperTreeGridTernary3DDualContour (Failed)
710 - VTK::FiltersHyperTreeCxx-TestHyperTreeGridTernary3DPlaneCutterDual (Failed)
717 - VTK::FiltersHyperTreeCxx-TestHyperTreeGridTernaryHyperbola (Failed)
720 - VTK::FiltersHyperTreeCxx-TestHyperTreeGridToDualGrid (Failed)
767 - VTK::FiltersParallelMPICxx-MPI-TestDistributedPointCloudFilter5 (Failed)
780 - VTK::FiltersParallelCxx-MPI-AggregateDataSet (Failed)
824 - VTK::FiltersModelingPython-TestCookieCutter (Failed)
826 - VTK::FiltersModelingPython-TestCookieCutter3 (Failed)
899 - VTK::RenderingOpenGL2Cxx-TestCoincident (Failed)
915 - VTK::RenderingOpenGL2Cxx-TestFluidMapper (Failed)
1042 - VTK::ChartsCoreCxx-TestMultipleScalarsToColors (Failed)
1284 - VTK::RenderingCoreCxx-TestEdgeFlags (Failed)
1422 - VTK::FiltersSourcesPython-TestStaticCellLocatorLineIntersection (Failed)
1423 - VTK::FiltersSourcesPython-TestStaticPointLocatorLineIntersection (Failed)
1559 - VTK::FiltersGeometryCxx-TestLinearToQuadraticCellsFilter (Failed)
1604 - VTK::FiltersGeneralCxx-TestDensifyPolyData (Failed)
1628 - VTK::FiltersGeneralCxx-TestYoungsMaterialInterface (Failed)
1642 - VTK::FiltersGeneralPython-TestFEDiscreteClipper2D (Failed)
1772 - VTK::FiltersCorePython-TestContour3DLinearGrid2 (Failed)
1814 - VTK::FiltersCorePython-contourCells (Failed)
1826 - VTK::FiltersCorePython-glyphComb (Failed)
1837 - VTK::FiltersCorePython-streamComb (Failed)

There are the -DVTK_MODULE_DEBUG=ON -DVTK_MODULE_DEBUG_ALL=ON flags you can pass to have VTK’s module system dump out its consideration of every module. I would recommend looking at that to see if it gives any insight into why the module might not be available. That said, I don’t know what would cause it to ignore its VTK_MODULE_ENABLE flag off hand.

Many thanks for your reply.

It seems everything is fine with the “InfovisBoost” module.
Sorry for misleading you.


The initial VTK cmake step reported:
-- VTK module debug building: VTK::InfovisBoost is being built

And I now also noted that “make test” reported:
296/2122 Test #296: VTK::InfovisBoostCxx-TestVariantSerialization ................................................ Passed 0.06 sec
VTK::InfovisBoost = 0.06 sec*proc (1 test)
vtkInfovisBoost = 0.06 sec*proc (1 test)

It looks like I had false expectations.
The “Infovis/Boost/vtk.module” file contains “LIBRARY_NAME vtkInfovisBoost”.
So, I expected that there would appear a “libvtkInfovisBoost-9.0.so.9.0.3” file.
No such library was built.
On the other hand, the “Infovis/Boost/CMakeLists.txt” file contains “vtk_module_add_module(VTK::InfovisBoost ... HEADER_ONLY)” (and indeed, the “vtkVariantBoostSerialization.h” file is present in the “include/vtk-9.0” directory after “make install”).
So, most probably, no shared library related to this module is expected to be built at all.
Am I right now?

This still leaves the problem of the skipped “VTKExample-Infovis/Cxx” test.
Do you know any magic flags which would “dump” some info on why this happens?

Ah, yep. It’s just a set of headers.

You can inspect VTK_${component}_FOUND and VTK_${component}_NOT_FOUND_MESSAGE (if it wasn’t found) for each component.

Many thanks again.

No matter what I try, I get no single message in the form “VTK_${component}_*FOUND*” when I try to build the “Examples/Infovis/Cxx”.
The cmake step ends with no errors, but it produces a “dummy” makefile (running “make” simply returns “Nothing to be done for 'all'.”).

I started to suspect that there is something wrong with the “Examples/Infovis/Cxx/CMakeLists.txt” file.

Have a look at lines 4 to 20:

set(vtk_modules         # the "set" BEGINS here
find_package(VTK        # the "find_package" BEGINS here
    RenderingOpenGL2)   # the "find_package" ENDS here ...
  OPTIONAL_COMPONENTS   # ... what is this then?
    ViewsQt)            # the "set" ENDS here

Is the “set” expected to execute commands that compute its arguments? I cannot find such a statement in the “set” documentation.

Is the “find_package” expected to return a list of packages? I cannot find such a statement in the “find_package” documentation.

Hmm. That’s a good question. That does indeed seem to be very wrong. I don’t know why there’s no error since it is invalid CMake syntax. I suspect it is leftover from copy pasta. Feel free to hack it up to remove the set(vtk_modules line and the extra ) before OPTIONAL_COMPONENTS. That should get a better result.

Huh, guess you learn something every day:

% cat foo.cmake
set(foo find_package(Threads))
% cmake --trace-expand -P foo.cmake
Running with expanded trace output on.
…/foo.cmake(1):  set(foo find_package ( Threads ) )
…/foo.cmake(4):  set(foo find_package ( Threads ) )

Eh, it wasn’t actually just that trivial.


Your patch mostly works.

Two executables cannot be linked: “Examples/Infovis/Cxx/EasyView” and “Examples/Infovis/Cxx/CustomLinkView”.
In both cases the “vtkDataObjectToTable::New()” is missing:

/usr/bin/ld: CMakeFiles/EasyView.dir/EasyView.cxx.o: undefined reference to symbol '_ZN20vtkDataObjectToTable3NewEv'
/usr/bin/ld: CMakeFiles/CustomLinkView.dir/CustomLinkView.cxx.o: undefined reference to symbol '_ZN20vtkDataObjectToTable3NewEv'
/usr/bin/ld: /.../lib/libvtkInfovisCore-9.0.so.1: error adding symbols: DSO missing from command line

Updated :slight_smile: . Thanks for testing.

Ah, yes. I forgot that there were “CMakeLists.txt” files in every subdirectory (which were using the broken “vtk_modules” variable). The strange thing was that the “Examples/Infovis/Cxx/StatsView” was built without problems.

Anyhow, I now rebuilt the whole VTK with your new patches, and all “Examples/Infovis/Cxx” executables are there (and the test said “Passed”).
Of course, there are still 32 tests that failed out of 2122 (the same as shown in my first post above).

Many thanks for your help.

Unfortunately, without test error output (and baseline image diffs for those tests), there’s not much to be done about a list of failing tests :slight_smile: .

I can provide whatever you need, just tell me how to do it.

The easiest is ctest --rerun-failed -VV (assuming that these are the failing tests from the last ctest run). Alternatively, you can use ctest to submit to the dashboard with ctest -M Experimental -T Test --rerun-failed followed by ctest -M Experimental -T Submit. Finding the entry on CDash and linking to it would also make the baseline image differences available.

I am attaching a file with my “failed tests” results.

Inside, you can find the “ctest_rerun_failed_VV.out.txt” file with a complete log from running the “ctest --rerun-failed -VV” command.

Out of the 32 tests that “failed” …

In 8 cases, “mpiexec” related tests die with an error: “There are not enough slots available in the system to satisfy the __SOME_NUMBER_ slots that were requested by the application”.
UPDATE: I added a “localhost slots=8” line in the “/etc/openmpi/openmpi-default-hostfile” file, and then all 8 “VTK::FiltersParallel*-MPI-*” tests run fine (i.e., “Passed”).

In 23 cases, a “.diff.png” file has been generated (all of them are also included in the attached file).

One case (test 1042) reports that “image differencing failed” due to different sizes. I think what happened is that my laptop’s screen is only 1600x900, and the original image is 800x900, so it got cut to 800x875 when running this test on my laptop (X11 “window decorations” used 25 pixels).

ctest_rerun_failed_VV.tar.gz (57.4 KB)

For future reference … the “failing” test 1042, mentioned in my previous post, is called “VTK::ChartsCoreCxx-TestMultipleScalarsToColors”.

@ben.boeckel Let me know if you need anything else from me.

I think filing an issue with the information is the best bet right now. I don’t know how much attention any hypothetical 9.0.4 might get. But, if the problems persist on master, then it is of much more interest.