Add ubuntu 22.04 to travis-ci

[TotoGaz]

This PR upgrades

• caliper from 2.4.0 to 2.8.0
• trilinos from 12.18.1 to 13.4.0

because they were not compiling on ubuntu 22.04 (see https://github.com/GEOSX/GEOSX/issues/2065 and https://github.com/GEOSX/thirdPartyLibs/issues/136).

About caliper

• The caliper support of CUDA::cupti is made optional (ENABLE_CALIPER_WITH_CUPTI) and does not automatically rely on the CUDA activation.
• It appears that none of our CUDA CI targets was compiling caliper with CUDA::cupti support, despite the explicit request (caliper was ignoring it: -- Could NOT find CUPTI (missing: CUPTI_LIBRARY CUPTI_INCLUDE_DIR) and -- CUpti support : No).
• Note that the provided CUDA::cupti path was wrong and ignored.
• It appears that pecan-gpu was the only target to try to compile caliper with cupti support, and it looks like there are issues about it (https://github.com/LLNL/Caliper/issues/385 or https://gitlab.kitware.com/cmake/cmake/-/issues/22761 & https://gitlab.kitware.com/cmake/cmake/-/merge_requests/7200)

Target Centos (7.6, clang 9.0.0 + gcc 4.9.3, open-mpi 1.10.7) is removed

• It can't compile trilinos 13.4.0 smoothly.
• It's not clear that it's still representative of a real use case for our developers.

Also

• python 3 is used on all targets.
• The size of the travis virtual machine is made explicit, not to depend on any undocumented and uncontrolled "behind the curtain" configuration by the travis support.

Relates to https://github.com/GEOSX/GEOSX/issues/1889

[TotoGaz]

@rrsettgast @bmhan12 can you check that the new trilinos builds on quartz? Which env do you wish to replicate if we remove the old clang 9 + gcc 4.9 target?

@XL64 can you check that it builds on Pangea 3?

[bmhan12]

can you check that the new trilinos builds on quartz?

I ran into the std - related errors you mentioned while building trilinos:

thirdPartyLibs/build-quartz-clang@10.0.0-release/trilinos/src/trilinos/packages/kokkos/core/src/Kokkos_CopyViews.hpp:1321:10: error: no template named 'is_trivially_copy_assignable' in namespace 'std'; did you mean 'has_trivial_copy_assign'?
    std::is_trivially_copy_assignable<

I need try again and target a different gcc, see if that fixes it...

Which env do you wish to replicate if we remove the old clang 9 + gcc 4.9 target?

I think we want clang@10 to replicate what we're currently using on quartz.

[TotoGaz]

I ran into the std - related errors you mentioned while building trilinos:

thirdPartyLibs/build-quartz-clang@10.0.0-release/trilinos/src/trilinos/packages/kokkos/core/src/Kokkos_CopyViews.hpp:1321:10: error: no template named 'is_trivially_copy_assignable' in namespace 'std'; did you mean 'has_trivial_copy_assign'?
    std::is_trivially_copy_assignable<

Is there any chance that adding a missing #include <type_traits> could help? I doubt it, but this may be worth a try?

I need try again and target a different gcc, see if that fixes it...

Which env do you wish to replicate if we remove the old clang 9 + gcc 4.9 target?

I think we want clang@10 to replicate what we're currently using on quartz.

Do you know which "underlying" gcc headers you are using? We would face issues with gcc < 5, put above it should be OK. I guess this is the critical question.

[bmhan12]

Do you know which "underlying" gcc headers you are using? We would face issues with gcc < 5, put above it should be OK.

I suspect the same thing. clang uses gcc 4.9.3 by default, trying out gcc 8.1.0...

[TotoGaz]

I suspect the same thing. clang uses gcc 4.9.3 by default, trying out gcc 8.1.0...

You mean clang 10 with gcc 8.1 as header backend?

[bmhan12]

You mean clang 10 with gcc 8.1 as header backend?

Yes. I verified the TPLs build and GEOSX passes tests on quartz after adding the following flags to the host-config:

set(CMAKE_C_FLAGS "--gcc-toolchain=/usr/tce/packages/gcc/gcc-8.1.0" CACHE STRING "")
set(CMAKE_CXX_FLAGS "--gcc-toolchain=/usr/tce/packages/gcc/gcc-8.1.0" CACHE STRING "")

[TotoGaz]

I've just validated with @karimifard that the auto deployment for ubuntu 22.04 is running on ubuntu 22.04 (poke @jafranc).

@bmhan12 @rrsettgast How should we proceed? IIUC, fixing the host-config file could be enough to get to the merge? What should be our policy w.r.t. the corresponding docker instance? Could we merge right now and create it afterwards or should we wait for quartz clang10 to get created?

Also there is Stanford's Sherlock target which is coming too (with @jafranc #193).

[XL64]

Build of TPL seems OK on P3 but the NVTX PR https://github.com/GEOSX/GEOSX/pull/1980 integration broke the GEOX build, I'll push a fix PR. Maybe I should enable NVTX by default so that it is tested in CI ?

[XL64]

Build of TPL seems OK on P3 but the NVTX PR GEOSX/GEOSX#1980 integration broke the GEOX build, I'll push a fix PR. Maybe I should enable NVTX by default so that it is tested in CI ?

Fixed here :https://github.com/GEOSX/GEOSX/pull/2096

[rrsettgast]

You mean clang 10 with gcc 8.1 as header backend?

Yes. I verified the TPLs build and GEOSX passes tests on quartz after adding the following flags to the host-config:

set(CMAKE_C_FLAGS "--gcc-toolchain=/usr/tce/packages/gcc/gcc-8.1.0" CACHE STRING "")
set(CMAKE_CXX_FLAGS "--gcc-toolchain=/usr/tce/packages/gcc/gcc-8.1.0" CACHE STRING "")

@bmhan12 Can you put this into a PR?

[bmhan12]

Can you put this into a PR?

PR opened here in LvArray: Geosx/LvArray#271

[TotoGaz]

@bmhan12 Yes I will!