Skip to content

Conference call notes 20200819

Jump to bottom
Kenneth Hoste edited this page Aug 19, 2020 · 6 revisions

(back to Conference calls)

Notes on the 154th EasyBuild conference call, Wednesday August 19th 2020 (15:00 UTC - 17:00 CEST)

Attendees

Alphabetical list of attendees (11):

  • Maxime Boissonneault (ComputeCanada)
  • Simon Branford (Univ. of Birmingham, UK)
  • Kenneth Hoste (HPC-UGent, Belgium)
  • Adam Huffman (Big Data Institute, Oxford, UK)
  • Joachim Hein (Lunarc, Lund University, Sweden)
  • Victor Holanda Rusu (CSCS, Switzerland)
  • Mikael Öhman (Chalmers University of Technology, Sweden)
  • Fotis Georgatos (SDSC, Switzerland)
  • Jörg Saßmannshausen (NIHR Biomedical Research Centre, UK)
  • Bart Oldeman (ComputeCanada)
  • Davide Vanzo (Microsoft)

Agenda

  • recent developments + outlook to next release

  • 2020b common toolchains

  • fosscuda/2020a & CUDAcore discussion

  • moving Boost/HDF5/netCDF to compiler-only toolchains, to avoid indirect dep on MPI for many software packages

  • Q&A

Recent developments

  • leaning towards making next release v4.3.0 due to some significant changes in EasyBuild framework
  • ETA: end of August
  • recent changes
    • framework
      • bug fixes for apply_patch function
        • fix copying of (non-existing) file with apply_patch (PR #3400)
        • fix issues with applying PR patch in --from-pr (PR #3414)
      • correctly determine commit status in --merge-pr (PR #3406)
        • now takes into account both results from Travis CI & GitHub Actions
        • we need to combine the "combined commit status" and results of "check run suites" ourselves for this 🤦
        • caused some problems after disabling Travis CI checks for easyconfigs PRs (status was always "pending" according to --merge-pr)
      • create symlink from lib64 to lib subdir in installation directories to avoid that GCC prefers /lib64 system directories (PR #3401)
        • required to avoid that libraries from /lib64 are picked up instead of those provided through proper EasyBuild dependencies
        • do we need to provide a script to fix existing installations?
      • set up a minimal build environment when using system compiler (PR #3399
        • default is to set CC=gcc and CXX=g++, but this can be configured differently via --minimal-build-env
        • important in some environments to avoid that configure prefers x86_64-pc-linux-gnu-gcc command over gcc, which causes headaches when using --rpath because we only wrap the gcc command (cfr. issue #3398)
      • stop installing ccache wrapper for Fortran compiler (PR #3409)
        • ccache dropped support for caching Fortran compilations (never really worked well anyway)
    • easyblocks
      • added multi_deps support into QScintilla easyblock (PR #2077)
      • make TensorFlow easyblock also set $GCC_HOST_COMPILER_PREFIX to specify binutils location (PR #2210)
      • ensure stand-alone Python package being installed is in view when running 'pip check' by loading fake module first (PR #2114)
      • update Libint easyblock for versions >= 2.6.0 (PR #2116)
      • update CP2K easyblock for versions >= 7.1 (PR #2069)
      • fix for building NAMD on POWER (PR #2113)
      • custom easyblock for pybind11 (PR #2115)
      • handle /opt special case in CMakeMake easyblock... (PR #2105, PR #2124)
      • automatically add required -G Ninja when using CMakeNinja easyblock + add 'generator' custom easyconfig parameter for CMakeMake (PR #2120)
    • easyconfigs
  • to merge soon:

2020b update of common toolchains

  • base: GCC 10.2 + binutils 2.35 (see PR #10935
  • foss:
    • OpenMPI 4.1.0 (RC is available, final release soon)
    • OpenBLAS 0.3.10 (updated from 0.3.9 in 2020a)
    • FFTW 3.3.8 (no updates)
  • intel:
    • compilers: 2020 update 2
    • MPI: 2019 update 8
    • MKL: 2020 update 2
    • is GCC 10.x supported officially as base compiler?
      • strictly according to release notes: no => "gcc 4.8.5 to gcc 9.0.1" and "binutils 2.27 to binutils 2.31.1", but that seems very conservative
      • Kenneth has contacted Intel support, no reply yet
    • we can start experimenting with this to see if we hit any problems (especially with impi)
  • Mikael: also add other toolchains (iomkl, gimkl, gomkl, & friends)?
    • adding toolchains itself is not the issue
    • testing installations with these toolchains is the time-consuming part...
    • Mikael is mainly interested in gomkl

fosscuda/2020a

  • cfr. https://github.com/easybuilders/easybuild-easyconfigs/pull/10935
  • CUDA 11.0.2 compatible with GCC 9.3
  • UCX with CUDA support is key
    • we should have a way to force people to use the right CUDA
    • can be fixed by hardcoding UCX deps for gcccorecuda
  • Bart: if we could break one-to-one mapping of easyconfigs to modules, there may be a better approach
    • can we add support in framework to generate additional module files?
  • also needs fixes in HierarchicalMNS
    • need to get correct $MODULEPATH extensions for CUDA+GCC
    • can't be done by CUDA in Core level (since it needs to know about the compiler version)
    • can't be done in gcccuda toolchain (because toolchains are hidden)
    • is making the module file more dynamic to check for a GCC version and extend $MODULEPATH based on that?
    • Bart: leverage versionsuffix as a workaround?

Moving software to compiler-only toolchains

  • to avoid indirect dep on MPI for many software packages
  • relevant for Boost, HDF5, netCDF, FFTW, PETSc (indirectly), ...
  • for example, MariaDB is installed with gompi toolchain just because it depends on Boost (see PR #11061)
  • Maxime: Boost is the non-MPI version at Compute Canada (same for HDF5, netCDF)
    • Boost with MPI support is installed as Boost.MPI via modaltsoftname
    • Boost.MPI is basically a superset of Boost
    • a family directive is added in the module files to avoid having both Boost and Boost.MPI loaded
  • very few software actually uses the MPI capabilities of these software packages (even FFTW, VASP doesn't use it)
  • is there a way we can make a change like this in the 2020a generation of easyconfigs without being very disruptive?
    • one way would be renaming Boost to Boost.serial (but meh...)
    • or we could add easyconfigs like Boost.mt so stuff can start depending on it (Maxime's contributions)
    • going forward (2020b) we could make it explicit (Boost.serial or Boost.mt + Boost.MPI)
      • like Cray does
      • step-wise approach (from Boost -> Boost+Boost.mt -> Boost.MPI+Boost.mt)
  • example:
    • now: Boost/1.72.0-gompi-2020a => Boost/1.72.0-GCC-9.3.0
    • having both these modules available will cause some headaches
      • Mikael: also with recursive unloading...
  • only doing it going forward (2020b onwards)

Q&A

  • (none)

Clone this wiki locally