Conference call notes 20161207 - easybuilders/easybuild GitHub Wiki

(back to Conference calls)

Notes on the 65th EasyBuild conference call, Wednesday December 7th 2016 (5pm - 6pm CET)

Attendees

Alphabetical list of attendees (7):

  • Damian Alvarez Mallon (JSC, Germany)
  • Pablo Escobar (UniBas, Switzerland)
  • Markus Geimer (JSC, Germany)
  • Fotis Georgatos (Illumina, UK)
  • Kenneth Hoste (HPC-UGent)
  • Adam Huffman (Francis Crick Institute, UK)
  • Robert Schmidt (OHRI, Canada)

Agenda

Notes

Update on RPATH support
  • opt-out option for RPATH via toolchain option
    • Pablo: a couple of examples of RPATH currently failing, too hard to figure out, just opt-out?
    • Pablo is interested in helping out with that
  • fairly close to stable?
    • should not wait until all corner cases are covered
  • distinction of 'link-only' dependencies should also be there
    • https://github.com/hpcugent/easybuild-framework/pull/1960
    • should still be able to include 'module load' statements in generated modules
      • e.g., for Pablo's use case of protecting users from breaking stuff by changing the environment
      • also makes it explicit which versions of dependencies were used
      • not including loads for dependencies also affects people using ${EBROOT...} in their scripts
        • can be fixed by including $EBROOT... for link deps in 'parent' module?
    • this may be an issue for e.g. R, where additional extensions can also be installed by users...
    • also interesting: having multiple module trees with different types of module files (with/without $LD_LIBRARY_PATH, link deps, etc...)
2017a common toolchains

  • proposal for foss/2017a:

    • GCC 6.3 + binutils 2.27
    • OpenMPI 1.10.4
      • foss/2016b: 1.10.3
      • note: too soon to jump to OpenMPI 2.0.1 (?)
    • OpenBLAS 0.2.19 + LAPACK 3.6.1 + ScaLAPACK 2.0.2
      • foss/2016b: OpenBLAS 0.2.18, LAPACK 3.6.1, ScaLAPACK 2.0.2
    • FFTW 3.3.5
      • foss/2016b: 3.3.4

  • proposal for intel/2017a:

    • (GCC 6.3 + binutils 2.27 as base)
      • intel/2016b: GCC 5.4 + binutils 2.26 as base
    • Intel compilers 2017.1.132
      • intel/2016b: 2016.3.210
    • Intel MPI 2017.1.132
      • intel/2016b: 5.1.3.181
    • Intel MKL 2017.1.132
      • intel/2016b: 11.3.3.210
Other

  • Damian: Python on Compiler level vs on GCCcore level

    • build Python with Intel compilers vs GCCcore
    • maybe not for Python itself, but certainly for numpy/scipy
      • numpy/scipy are installed in a different level of the hierarchy
    • initial benchmarking seem to suggest that moving to GCCcore makes sense
    • somewhat related to 'enhanced' toolchains that incl. a Python (Perl/R/...)
    • what about getting rid of Tk dep in Python?
      • not building Tkinter in Python base lib isn't that hard
      • building Tkinter separately is harder...
      • would make sense for a 'bare' Python installation
    • @ JSC: fight between 'bare' Python vs 'optimised Python'

  • Pablo: building software with EasyBuild inside of a Singularity container

    • in theory things may work inside of container but break outside when OS deps are available (e.g. Python packages)
    • related issue: getting MPI to work inside of Singularity container with IB support
      • Kenneth/Rob: workarounds exist to make it work, cleaner solution in Singularity itself is in the works

  • Rob: practical arrangements w.r.t. logistics for EasyBuild User Meeting in Jülich