Conference call notes 20171220

(back to Conference calls)

Notes on the 92nd EasyBuild conference call, Wednesday December 20th 2017 (5pm - 5.30pm CEST)

Attendees

Alphabetical list of attendees (5):

• Kenneth Hoste (HPC-UGent, Belgium)
• Teo Ioannis (CSCS, Switserland)
• Alan O'Cais (JSC, Germany)
• Bart Oldeman (McGill University, Canada)
• Rafael Alejandro Sarmiento Perez (CSCS, Switserland)

Agenda

• agenda EasyBuild User Meeting
• 2018a update of common toolchains
• discussion requirements & possible syntax for version ranges
• Q&A

Notes

EUM agenda

• https://github.com/easybuilders/easybuild/wiki/3rd-EasyBuild-User-Meeting#agenda
• open slots for site presentations
• Alan: talk on uDocker rather than Singularity?
  • cfr. https://www.hpcwire.com/2017/12/18/researchers-advance-user-level-container-solution-hpc/

2018a common toolchains

• current status is still https://lists.ugent.be/wws/arc/easybuild/2017-12/msg00019.html
  • no changes expected unless testing with easyconfigs using */2017* toolchains reveals major problems...
• PRs for foss/2018a and intel/2018a definitions coming soon...
• Bart: low intensity AVX512 in Intel compilers 2017 update 5 (& newer) by default (was high intensity before)
  • flag available to enable high intensity AVX512 is available
  • default was changed to low intensity because of too small loops resulting in performace loss on Intel Skylake...
  • cfr. https://software.intel.com/en-us/cpp-compiler-18.0-developer-guide-and-reference-qopt-zmm-usage-qopt-zmm-usage
  • may make sense to define a toolchain option specifically for this?
• 2018a common toolchain definitions will be included in EasyBuild v3.5.1 (ETA mid Jan 2018)

Support for parsing/querying version ranges (for different use cases)

• relevant for:
  • more flexible dependency specifications in easyconfig files
    • cfr. https://github.com/easybuilders/easybuild-framework/issues/746 + discussion on mailing list
    • e.g. builddependencies = ('CMake', '>= 3.8')
    • whole lot more needed than just parsing those type of version ranges...
    • how would robot look for easyconfigs/modules that can resolve this dependency?
    • open debate whether this should actually be used at all in easyconfig (in central repository)
  • guards on software version in "fat" (.yeb) easyconfigs
    • e.g. https://github.com/easybuilders/easybuild-framework/blob/master/test/framework/easyconfigs/v2.0/toy-with-sections.eb
    • to specify which part of fat easyconfig is relevant for a particular software version
  • enhanced --filter-deps that allows to filter dependencies conditionally based on version
    • cfr. https://github.com/easybuilders/easybuild-framework/issues/2351
    • alternate notation (more flexible?) proposed by Maxime
    • allows for inclusive/exclusive 'borders' in version range
    • e.g. `--filter-deps=flex[2.5,2.6[
    • but hard to use this syntax inside [...]
• ideally whatever version range notations we want to support are implemented in a single location in the EasyBuild framework
  • functions like parse_version_range, is_version_in_range, etc.
  • existing libraries for this?
    • how is this done in RPMs (.spec files)?
    • pip supports some kind of ranges in requirements.txt files, how implemented?
• native YAML in (recent v3.x?) Python
  • vs https://pypi.python.org/pypi/PyYAML
  • certainly excellent JSON support available