Build status of Trilinos - testing.sandia.gov not reachable

[mathsen]

Hello,

in the Wiki it is mentioned that Trilinos uses CTest and also in some other bug reports e.g. here pictures of the test results or references to testing.sandia.gov or testing-dev.sandia.gov are mentioned.
I currently try to build Trilinos on different platforms and there seems to be a regression introduced in current master branch regarding builds on Windows. It would be really interesting to see for me, if regression tests are passing or in general with which compilers Trilinos currently builds.
Unfortunately neither testing.sandia.gov nor testing-dev.sandia.gov are reachable for me - I can't even resolve the IP, e.g.:

dig +short testing.sandia.gov @9.9.9.9

returns nothing. Are the test results only available internally or is there a way of how I can have a look at those?

Thanks and many greetings
mathsen

[cgcgcg]

Our dashboards used to be accessible. Then legal things changed and we had to stop that. We are working on making more of our testing accessible again though. We are not testing on Windows, but people have been building there. Do you have an error message that you could share?

[mathsen]

@cgcgcg Thank you very much for this information! It would be really great to have some kind of build status publicly available again!
Regarding my build problem: normally I use and test the software under linux. Currently we try to integrate MueLu AMG in a software, where compilation also on Windows is mandatory.
Unfortunately I currently don't have access to such a Windows machine (and won't have it for one further week), but I had a couple of problems when compiling Trilinos with Visual Studio 2022 in combination with the Intel compiler:

1. Current Trilinos master gives in configuration with cmake a warning, that "Tpetra is not available on Windows"
2. Nevertheless configuring continues and when Kokkos performs a C++17 test this fails, because the compiler aborts due to it doesn't know "-Wno-inline" and "-Wno-deprecated". I grepped in the Trilinos source code but did not find any relevant position, where these flags are set.
3. When I use Trilinos 16.0.0 problems 1) and 2) are not there: I get no Tpetra warning, configuring with cmake works just fine, but I get compilation errors very early somewhere in Teuchos.

Since I don't have a machine currently available I unfortunately can't give you more information right now. I will follow up on this, once I have again a Windows machine available and can make more tests.
I can also open new issues then (if you want to close this one, since it was only a "question").

Many greetings
mathsen

[cgcgcg]

@mathsen

1. No idea where that comes from.
2. Please comment out these lines and check if that gets you further
   

   Trilinos/cmake/ProjectCompilerPostConfig.cmake

   Lines 55 to 56 in e0e55eb

   	deprecated-declarations
   	inline

   
   @sebrowne We might have to make the warnings stuff fully conditional on the compiler identification.

[sebrowne]

   @sebrowne We might have to make the warnings stuff fully conditional on the compiler identification.

Argh I didn't think of that, yes, that should be conditional for GCC (I guess). Meaning, we always disable those warnings, but only for GCC. I'll open a PR today.

[mathsen]

Hello everybody,

sorry for the late reply. But finally I have some more infos about compilation on Windows. First @cgcgcg: the lines that you mentioned were responsible for the "-Wno-inline" and "-Wno-deprecated" errors. I commented them out (already some time ago) and then the problem was gone.

In the meantime I have worked on getting Trilinos compiled on Windows, using Microsofts cl compiler from Visual Studio 2022.
Since the current master branch gave me more compilation errors than trilinos-release-16-0-0, I focused on version 16 and could get this to a state, where it compiles and MueLu runs from within my own code. Here are my cmake settings, that compiles Trilinos as static library:

cmake -S . -B build \
    -G "Visual Studio 17 2022" -A x64 \
    -D CMAKE_CXX_STANDARD=17 \
    -D CMAKE_VERBOSE_MAKEFILE=ON \
    -D CMAKE_BUILD_TYPE="RELEASE" \
    -D BUILD_SHARED_LIBS=OFF \
    -D MPI_USE_COMPILER_WRAPPERS=ON \
    -D Trilinos_EXTRA_LINK_FLAGS="${MPI_LIB}" \
    -D CMAKE_C_FLAGS="-I ${MPI_INCLUDE_DIR}" \
    -D CMAKE_CXX_FLAGS="-I ${MPI_INCLUDE_DIR} -permissive- -bigobj -EHsc -wd4003" \
    -D Trilinos_ENABLE_Tpetra=ON \
    -D Trilinos_ENABLE_EXPLICIT_INSTANTIATION=ON \
    -D Trilinos_ENABLE_TESTS=OFF \
    -D Trilinos_ENABLE_EXAMPLES=OFF \
    -D Trilinos_ENABLE_MueLu=ON \
    -D MueLu_ENABLE_TESTS=OFF \
    -D MueLu_ENABLE_EXAMPLES=OFF \
    -D Trilinos_ENABLE_Ifpack2=ON \
    -D Tpetra_INST_INT_INT=ON \
    -D TPL_ENABLE_BLAS=ON \
    -D Trilinos_ENABLE_PyTrilinos=OFF \
    -D Trilinos_ENABLE_Gtest=OFF \
    -D Trilinos_ENABLE_DLlib=ON \
    -D Trilinos_ENABLE_TrilinosFrameworkTests=OFF \
    -D Trilinos_ENABLE_TrilinosATDMConfigTests=OFF \
    -D TPL_ENABLE_gtest=OFF \
    -D TPL_ENABLE_MPI=ON \
    -D TPL_ENABLE_HDF5=OFF \
    -D Trilinos_ENABLE_KokkosKernels=ON \
    -D BLAS_LIBRARY_DIRS="${BLAS_DIR}" \
    -D LAPACK_LIBRARY_DIRS="${LAPACK_DIR}" \
    -D BLAS_LIBRARY_NAMES="mkl_intel_lp64;mkl_sequential;mkl_core" \
    -D LAPACK_LIBRARY_NAMES="" \
    -D CMAKE_INSTALL_PREFIX="${INSTALL_DIR}"

Note that especially the CXX flags -permissive- -bigobj -EHsc -wd4003 were needed to successfully compile Trilinos.
Additionally, I needed to apply a couple of changes, that I attach here as a zipped patch:
trilinos-release-16-0-0.zip

This changes are not enough to get e.g. the whole thing compiled with

-D MueLu_ENABLE_TESTS=OFF

since e.g. Hierarchy.cpp relies on POSIX functions. I made a first attempt to replace them with c++17 filesystem functions, but did not test this thoroughly:

muelu_tests.zip

Wit this I'm able to use Tpetra matrices and vectors with a Belos cg and a MueLu AMG preconditioner on Windows.
If wanted I can make more tests on Windows or start looking into getting master to compile on Windows.
Thanks for the support here so far and many greetings
mathsen

[cgcgcg]

@mathsen Thanks! I think I understand most of these changes.

What's the deal with this one?

diff --git a/packages/xpetra/sup/Matrix/Xpetra_CrsMatrixWrap_decl.hpp b/packages/xpetra/sup/Matrix/Xpetra_CrsMatrixWrap_decl.hpp
index cfa773d099c..65d44fdac61 100644
--- a/packages/xpetra/sup/Matrix/Xpetra_CrsMatrixWrap_decl.hpp
+++ b/packages/xpetra/sup/Matrix/Xpetra_CrsMatrixWrap_decl.hpp
@@ -454,7 +454,7 @@ class CrsMatrixWrap : public Matrix<Scalar, LocalOrdinal, GlobalOrdinal, Node> {

 #ifdef HAVE_XPETRA_TPETRA
   virtual local_matrix_type getLocalMatrixDevice() const;
-  virtual typename local_matrix_type::HostMirror getLocalMatrixHost() const;
+  virtual typename Xpetra::CrsMatrix<Scalar, LocalOrdinal, GlobalOrdinal, Node>::local_matrix_type::HostMirror getLocalMatrixHost() const;
 #else
 #ifdef __GNUC__
 #warning "Xpetra Kokkos interface for CrsMatrix is enabled (HAVE_XPETRA_KOKKOS_REFACTOR) but Tpetra is disabled. The Kokkos interface needs Tpetra to be enabled, too."

[mathsen]

@cgcgcg Without this change cl fails to compile with this error:

D:\trilinos\script_generated_files\trilinos\packages\xpetra\sup\Matrix\Xpetra_CrsMatrixWrap_def.hpp(449,86): error C2244: 'Xpetra::CrsMatrixWrap<Scalar,LocalOrdinal,GlobalOrdinal,Node>::getLocalMatrixHost': unable to match function definition to an existing declaration [D:\trilinos\script_generated_files\build\intel-release\packages\xpetra\sup\xpetra-sup.vcxproj]
       D:\trilinos\script_generated_files\trilinos\packages\xpetra\sup\Matrix\Xpetra_CrsMatrixWrap_def.hpp(449,59): message : see declaration of 'Xpetra::CrsMatrixWrap<Scalar,LocalOrdinal,GlobalOrdinal,Node>::getLocalMatrixHost' [D:\trilinos\script_generated_files\build\intel-release\packages\xpetra\sup\xpetra-sup.vcxproj]
       D:\trilinos\script_generated_files\trilinos\packages\xpetra\sup\Matrix\Xpetra_CrsMatrixWrap_def.hpp(449,86): message : definition [D:\trilinos\script_generated_files\build\intel-release\packages\xpetra\sup\xpetra-sup.vcxproj]
       D:\trilinos\script_generated_files\trilinos\packages\xpetra\sup\Matrix\Xpetra_CrsMatrixWrap_def.hpp(449,86): message : 'Xpetra::CrsMatrix<Scalar,LocalOrdinal,GlobalOrdinal,Node>::local_matrix_type::HostMirror Xpetra::CrsMatrixWrap<Scalar,LocalOrdinal,GlobalOrdinal,Node>::getLocalMatrixHost(void) const' [D:\trilinos\script_generated_files\build\intel-release\packages\xpetra\sup\xpetra-sup.vcxproj]
       D:\trilinos\script_generated_files\trilinos\packages\xpetra\sup\Matrix\Xpetra_CrsMatrixWrap_def.hpp(449,86): message : existing declarations [D:\trilinos\script_generated_files\build\intel-release\packages\xpetra\sup\xpetra-sup.vcxproj]
       D:\trilinos\script_generated_files\trilinos\packages\xpetra\sup\Matrix\Xpetra_CrsMatrixWrap_def.hpp(449,86): message : 'CrsMatrixWrap<Scalar,LocalOrdinal,GlobalOrdinal,Node>::local_matrix_type::HostMirror Xpetra::CrsMatrixWrap<Scalar,LocalOrdinal,GlobalOrdinal,Node>::getLocalMatrixHost(void) const' [D:\trilinos\script_generated_files\build\intel-release\packages\xpetra\sup\xpetra-sup.vcxproj]
         Xpetra_MatrixFactory.cpp

So cl complains about the function definition's return type not matching the declared return type. I simply changed the declared return type to the one implemented in Xpetra_CrsMatrixWrap_def.hpp as a quick fix - which made the compiler happy :)

[cgcgcg]

Ah, I see what's happening. Yep, we can fix that.

[cgcgcg]

@mathsen I made some modifications to your changes and submitted them as PR #13841 against current develop. I'm now evaluating your MueLu changes and will open a PR once I'm happy.

What issues did you see with current develop?