Trilinos
Trilinos copied to clipboard
ShyLU: Cannot seem to generate tests (ctest returns "No tests were found!!!")
Question
@trilinos/<ShyLU>
Hello.
I am attempting to build ShyLU and all of its dependencies, tests, examples, dependencies' tests, and dependencies' examples. This is my current configure script (absolute paths with sensitive information replaced with {}
):
module load python
module load openmpi/4.0.2-intel20.4
module load hdf5
module load intel
../../cmake-3.21.0-linux-x86_64/bin/cmake \
-DCMAKE_BUILD_TYPE=RELEASE \
-DTrilinos_ENABLE_ShyLU=ON \
-DTrilinos_ENABLE_ALL_FORWARD_DEP_PACKAGES:BOOL=ON \
-DTrilinos_ENABLE_TESTS:BOOL=ON \
-DTrilinos_ENABLE_EXAMPLES:BOOL=ON \
-DTrilinos_TRACE_ADD_TEST:BOOL=ON \
-DTPL_ENABLE_ParMETIS=ON \
-DParMETIS_LIBRARY_DIRS={}/Trilinos/ParMETIS_build/lib \
-DHAVE_PARMETIS_VERSION_4_0_3=ON \
-DTPL_ENABLE_MPI=ON \
-DMPI_BASE_DIR=/opt/packages/openmpi/intel/4.0.2-intel20.4/ \
-DMPI_BIN_DIR=/opt/packages/openmpi/intel/4.0.2-intel20.4/bin/ \
-DMPI_EXEC=/opt/packages/openmpi/intel/4.0.2-intel20.4/bin/mpiexec \
-DTrilinos_ENABLE_OpenMP=ON \
-DMPI_C_COMPILER:FILEPATH=/opt/packages/openmpi/intel/4.0.2-intel20.4/bin/mpicc \
-DMPI_CXX_COMPILER:FILEPATH=/opt/packages/openmpi/intel/4.0.2-intel20.4/bin/mpic++ \
-DMPI_Fortran_COMPILER:FILEPATH=/opt/packages/openmpi/intel/4.0.2-intel20.4/bin/mpif90 \
-DBLAS_LIBRARY_DIRS={}/Trilinos/lapack-build/lib \
-DLAPACK_LIBRARY_DIRS={}/Trilinos/lapack-build/lib \
-DTrilinos_ENABLE_Fortran:BOOL=ON \
-DCMAKE_C_FLAGS:STRING="-I{}/Trilinos/ParMETIS_build/include" \
-DCMAKE_CXX_FLAGS:STRING="-I{}/Trilinos/ParMETIS_build/include" \
-DCMAKE_EXE_LINKER_FLAGS:STRING="-Wl,-rpath,/opt/packages/hdf5/hdf5-1.12.0/INTEL/lib -lhdf5" \
-DCMAKE_INSTALL_PREFIX={}/Trilinos/Trilinos_build \
-DTrilinos_SET_GROUP_AND_PERMISSIONS_ON_INSTALL_BASE_DIR={}/Trilinos/Trilinos_build \
-DTpetra_INST_SERIAL:BOOL=ON \
$EXTRA_ARGS \
..
I have built the project with make -j128
and the project appears to have built successfully. However, despite enabling Trilinos_ENABLE_TESTS:BOOL=ON
, when I run ctest -j128
I get the following:
Test project {}/Trilinos/Trilinos/build
No tests were found!!!
What am I doing wrong? Why are the tests not generating?
Did you happen to keep the CMake output? It should tell you which tests are enabled/disabled and why.
I did keep the CMake output, but it did not seem to report any information about tests. cmake-output.txt
Not sure why only ShyLU says that tests are enabled, despite Trilinos_ENABLE_TESTS:BOOL=ON
. Anyway, I think the reason you're not seeing any tests is that ShyLU has some subpackages. I had to pass for example ShyLU_DDFROSch_ENABLE_TESTS:BOOL=ON
as well to get the ShyLU_FROSch tests.
That seems to have at least enabled ShyLU's tests (by manually adding all flags of the form ShyLU_{submodule}_ENABLE_TESTS:BOOL=ON
) but seems very tedious to do for all of the other 50-something enabled packages. Is there a flag that properly recursively enables tests?
I think Trilinos only enables tests for user-enabled packages. Not sure how to enable tests for all enabled packages. @bartlettroscoe Do you know?
I think Trilinos only enables tests for user-enabled packages. Not sure how to enable tests for all enabled packages. @bartlettroscoe Do you know?
@computablee, are you asking for a way to "enable Package X and the tests and examples for all packages that Package X depends on upstream from Package X"?
Not sure why only ShyLU says that tests are enabled, despite Trilinos_ENABLE_TESTS:BOOL=ON
That only enables the tests for all of the packages that are explicitly enabled by the user, not all packages. See:
- https://docs.trilinos.org/files/TrilinosBuildReference.html#enable-or-disable-tests-for-specific-packages
which says:
Note that his will not result in the enable of the test suites for any packages that may only be implicitly enabled in order to build the explicitly enabled packages
Anyway, I think the reason you're not seeing any tests is that ShyLU has some subpackages
The ShyLU "package" actually does not have any subpackages. You can see this from looking at:
https://github.com/trilinos/Trilinos/blob/b3b2d8c63dd71e223a0296778f0fe5adf52a2aa5/PackagesList.cmake#L127
https://github.com/trilinos/Trilinos/blob/b3b2d8c63dd71e223a0296778f0fe5adf52a2aa5/packages/shylu/CMakeLists.txt#L1-L11
and
https://github.com/trilinos/Trilinos/blob/b3b2d8c63dd71e223a0296778f0fe5adf52a2aa5/packages/shylu/cmake/Dependencies.cmake#L1-L8
See, no subpackages, only dependencies on the packages ShyLU_DD and ShyLU_Node.
It would seem the only purpose for the ShyLU package is to provide the name "ShyLU" that will allow users to set Trilinos_ENABLE_ShyLU=ON
and trigger the enable of the packages ShyLU_Node
and ShyLU_DD
.
I am not judging. I am just explaining how it was set up by those who set this up. Because of this, the "ShyLU" package does not behave like other Trilinos packages when you try something like:
-DTrilinos_ENABLE_ShyLU=ON \
-DTrilinos_ENABLE_TESTS=ON \
or:
-DTrilinos_ENABLE_ShyLU=ON \
-DShyLU_ENABLE_TESTS=ON \
Because of the way this is set up, those enables will not enable any tests.
There are ways to address this with TriBITS that are more intuitive to users so that Trilinos_ENABLE_ShyLU=ON
behaves more like other Trilinos packages if there is interest.
Thank you for the responses. I have successfully gotten Trilinos to begin building the tests by manually enabling them. Unfortunately I am encountering some build errors with undefined references to Xpetra::TpetraMultiVector
when attempting to build the ShyLU_DD tests. Should I open a new issue since this is a different problem?
Are you possibly seeing #9471?
It looks like I might be. Unfortunately the system I am using is having filesystem issues today so I can't checkout the dev branch. Will check in on this tomorrow and inform you if that's my issue. Thank you again.
There are ways to address this with TriBITS that are more intuitive to users so that Trilinos_ENABLE_ShyLU=ON behaves more like other Trilinos packages if there is interest.
@bartlettroscoe Can you tell me ways to address this offline so it is more intuitive.
CC: @keitat
@bartlettroscoe Can you tell me ways to address this offline so it is more intuitive.
@srajama1, yes, we can make this part of FY22 planning for TriBITS with xSDK funding? I am thinking about the concept of a TriBITS meta-package. That could be used to define other nested collections of meta-packages as well like TrilinosLinearSolvers, TrilinosNonlinearSolvers, TrilinosParallelDataStructures, etc. We would need to do a fuller requirements analysis for this but that does not make sense until we complete TriBITSPub/TriBITS#367.
@bartlettroscoe I really like this idea. Building TrilinosLinearSolvers by itself without knowing all the packages is something I have advocated for several years. This is great! Let us take funding discussion offline.
This issue has had no activity for 365 days and is marked for closure. It will be closed after an additional 30 days of inactivity.
If you would like to keep this issue open please add a comment and/or remove the MARKED_FOR_CLOSURE
label.
If this issue should be kept open even with no activity beyond the time limits you can add the label DO_NOT_AUTOCLOSE
.
If it is ok for this issue to be closed, feel free to go ahead and close it. Please do not add any comments or change any labels or otherwise touch this issue unless your intention is to reset the inactivity counter for an additional year.