-
Notifications
You must be signed in to change notification settings - Fork 144
Conference call notes 20190123
(back to Conference calls)
Notes on the 118th EasyBuild conference call, Wednesday Jan 23rd 2019 (17:00 - 18:00 CET)
Alphabetical list of attendees (9):
- Damian Alvarez (JSC, Germany)
- Fotis Georgatos (SDSC, Switzerland)
- Victor Holanda (CSCS, Switzerland)
- Kenneth Hoste (HPC-UGent, Belgium)
- Adam Huffman (Big Data Institute, UK)
- Alan O'Cais (JSC, Germany)
- Mikael Öhman (Chalmers University of Technology, Sweden)
- Bart Oldeman (ComputeCanada)
- Davide Vanzo (Vanderbilt University, US)
- updates on upcoming EasyBuild v3.8.1
- test report for proposed 2019a common toolchains
- follow-up on moving Python to GCCcore
- update on porting EasyBuild to Python 3
- Q&A
- ETA: by EUM19
- framework
- https://github.com/easybuilders/easybuild-framework/milestone/62
- highlights:
- PRs targeted for 3.8.1 have been merged
- not planning to merge anything else for 3.8.1 (unless a major issue pops up)
- TODO
- (none)
- easyblocks
- https://github.com/easybuilders/easybuild-easyblocks/milestone/53
- highlights:
- adding
include/python<version>
to$CPATH
inPython
module was merged + reverted- because of problems that surfaced with
ROOT
- cfr. https://github.com/easybuilders/easybuild-easyblocks/pull/1620
- because of problems that surfaced with
- several software-specific minor updates/fixes
- adding
- TODO:
- handling of
$LDSHARED
inPythonPackage
easyblock
- handling of
- easyconfigs
- https://github.com/easybuilders/easybuild-easyconfigs/milestone/56
- highlights:
- various software updates/additions, minor software-specific bug fixes
- TODO:
- 2019a toolchains are considered a blocker for EasyBuild 3.8.1
-
see https://gist.github.com/boegel/68b542fa564fd370e8b0e7710a320f6f
-
not having a CUDA compatible with GCC 8.x is not considered a blocker for using GCC 8.x in
fosscuda/2019a
-
Damian: some of the failures may have already been fixed in JSC repo
- ELPA: some codes depend on old ELPA versions
- 2016.5 & 2018.x worked with Intel 2019
- ELPA: some codes depend on old ELPA versions
-
Victor: why is ELPA needed as dependency for QuantumESPRESSO?
- Alan: extra capabilities/performance improvements?
-
no objections were raised to go forward with current
foss/2019a
andintel/2019a
proposals based on test report -
unclear which Python 3.x to go with for 2019a generation of easyconfigs (3.6 vs 3.7)?
- still some Python packages not compatible yet with Python 3.7 (e.g. TensorFlow)?
- see https://github.com/easybuilders/easybuild-easyconfigs/issues/6682 for list of problematic packages (needs to be revisited/updated)
-
cfr. https://github.com/easybuilders/easybuild-easyconfigs/issues/7463
-
motivation: one single easyconfig for pkgs like ...
-
preferred option is suggestion 1
-
main disadvantage is that numpy will not actually use libimf even when linked to it
- libm get precedence because it's used by the Python interpreter
- results in performance hit
- one IntelPython benchmark showed significant slowdown
- in theory could be 3-4x slowdown, but unclear whether it's actually relevant in real world applications
- only workaround is to enforce use of libimf via $LD_PRELOAD (not tried yet by Mikael)
- Bart: statically linking libimf in numpy?
- was tried by Mikael, but didn't seem to work
- Alan: another option could be to use RPATH
- problem will get less severe over time since glibc is catching up on libimf
- but getting a new glibc in the OS takes a long time
-
bundle vs separate easyconfigs
-
module alias: Python/3.6.6-intel-2019a -> SciPy/2019-intel-2019a-Python-3.6.6
- can also be done for numpy -> SciPy
- done via ModuleAlias generic easyblock
- see https://easybuild.readthedocs.io/en/latest/Wrapping_dependencies.html
-
Bart: working on support for installing a single easyconfig for multiple Python versions
- iterate over builddependencies
- not rely on $PYTHONPATH but on a self-defined one (e.g. $EBPYTHONPREFIX) together with a site.py script
- opens the door to renaming Python/2.x to Python2 and allowing to load it together with Python 3.x
-
to be discussed also during EasyBuild User Meeting next week
- good progress in
4.x
branch (which is currently up-to-date withdevelop
) - see https://github.com/easybuilders/easybuild-framework/issues?q=label%3Apython3+is%3Aclosed
- TODO:
- make full set of framework tests pass on top of Python 3
- then move on to easyblock (mostly w.r.t.
import vsc.*
?) - nothing to do for easyconfigs?
-
Åke: UCX and PMIx for OpenMPI: include in OpenMPI easyconfigs in the future?
- additional deps for OpenMPI?
- Damian: UCX usually comes with OFED stack, low-level lib, not well suited for inclusion as dep
- Bart: UCX is more like a low-level lib (on top of ibverbs)
- similar to
- installed as a module at Umeå
- decision whether to include as a dependency or not is site-specific
- Davide: UCX is needed to make OpenMPI versions work with MOFED 4.4.x...
- only OpenMPI 3.1.x supports (Mellanox) OFED 4.4.x, be aware of this before you upgrade!
- Bart: also better w.r.t. performance
- Bart: PMIx is even worse (used for job startup & communication with job scheduler)
- OpenMPI already includes a specific version of PMIx, which have to be compatible with Slurm you're using
- Bart: UCX is more like a low-level lib (on top of ibverbs)
- Bart: not a good idea to include it by default, since UCX + Omnipath does not work
- Damian: UCX gets half the bandwidth compared to OpenIB (related to not being able to use multiports?)
- Victor: similar at CSCS
- Kenneth: could be best handled via login in an OpenMPI easyblock...
- dedicated docs on how to configure OpenMPI would be great
-
Victor (CSCS) expressed interest in helping out with porting of EasyBuild to Python 3
-
all talks at EasyBuild User Meeting will be streamed & recorded
- see the EasyBuild YouTube channel: https://www.youtube.com/channel/UCqPyXwACj3sjtOho7m4haVA