Closed bartlettroscoe closed 3 years ago
@bscollin, I updated the TriBITS snapshot so this and PR https://github.com/CASL/Trilinos/pull/1 should be good to go.
Let me know if you have any trouble with this.
Minor issue wit this is that the docker looks like it needs to be updated to a more modern version of cmake. Also, I've made a repo: github.com/CASL/Trilinos so that we don't need to checkout a specific SHA1 anymore. The second should be easy to do, the first will be more work.
Below are my notes for debugging and addressing this issue. Also, this is info on how I can reproduce Futility builds for the next time I need to do this. Details are given below in "Detailed notes". In short, I used CMake 3.12.2 and GNU 7.2.0 compilers to build Futility on my local machine. The test results where:
100% tests passed, 0 tests failed out of 57
Subproject Time Summary:
Futility = 15.37 sec*proc (57 tests)
Label Time Summary:
BASIC = 15.37 sec*proc (57 tests)
CONTINUOUS = 15.37 sec*proc (57 tests)
HEAVY = 15.37 sec*proc (57 tests)
NIGHTLY = 15.37 sec*proc (57 tests)
(When did the testing categories get added as test labels? That is really nice!)
TASKS:
Clone repos and inspect versions of the repos [Done]
Set up a configure script and try doing a configure [Done]
Fix configure problems [Done]
Create PRs for CASL GitHub repos for Trilinos (https://github.com/CASL/Trilinos/pull/1) and Futility (this one) [Done]
Cherry-pick commits back to Trilinos repo branch and create Trilinos PR (https://github.com/trilinos/Trilinos/pull/6371) [Done]
Use git format-patch and git am to create PRs for kokkos and kokkos-kernels repos for these changes ... Not relavent to the current kokkos and kokkos-kernels repos as they have been massively refactored and don't have these problems anymore [Done]
FYI: using the configure script:
$ cat do-configure
#!/bin/bash
if [[ -e CMakeCache.txt ]] ; then
rm -r CMake*
fi
cmake \
-GNinja \
-DFutility_ENABLE_TESTS=ON \
"$@" \
/scratch/rabartl/Futility.base/Futility
I also tried this with ninja-fortran 1.8.2 from the Kitware fork, and it worked as well, but for some reason it build very slowly. The ninja build should use more parallelism and build faster but for some reason it only looked like it used one core to build. Not sure what that is about but that is a same. We see noticeable improvements in build times with Trilinos (especially on rebuilds due to faster dependency rule evaluation).
Hmmm...does something need to be updated on the Travis CI side?
Yes... I told you that... waiting on Mark
ok
@bscollin,
I just pushed the commit bfae4c598ce40291d5300517675ef9fca2b60128 which sets Tpetra_INST_INT_INT=OFF
. That should result in:
Processing ETI support: TpetraCore
-- TpetraCore: Processing ETI / test support
-- Enabled Scalar types: long long|double
-- Enabled LocalOrdinal types: int
-- Enabled GlobalOrdinal types: long long
-- Enabled Node types: Kokkos::Compat::KokkosSerialWrapperNode
-- Set of enabled types, before exclusions: S={long long} N={Kokkos::Compat::KokkosSerialWrapperNode} LO={int} GO={long long};S={double} N={Kokkos::Compat::KokkosSerialWrapperNode} LO={int} GO={long long}
In other words, that should cut the number of Tpetra instantiations form 6 to 2.
This goes along with the fixes to Trilinos in https://github.com/CASL/Trilinos/pull/1.
Without these changes, Futrility will not build with that updated version of Trilinos.