Telcon: 2017 06 08

Participants

1. Todd Gamblin (LLNL)
2. TBD

News

1. Tutorials!

   1. Adam Stewart is giving a Spack tutorial at ANL on June 12:

      • Title: Managing HPC Software Complexity with Spack
      • Speaker: Adam J. Stewart
      • Date: Monday, June 12th - Tuesday, June 13th
      • Time: 1:00 PM - 4:00 PM
      • Location: Argonne National Laboratory, Building 240, Rooms 1404-1405

   2. Todd will give a Spack tutorial at the HPC Knowledge Meeting in San Sebastian, Spain on June 16.

      • HPCKP program
      • Tutorial info

2. Update on spack environment implementation

   • See the Environments Road Map

   • Peter Scheibel (LLNL) has implemented a "context"

   • list of abstract "user specs" combined with concrete versions of them

   • allows us to represent a spack stack in terms of:

     • what the user asked for (user spec)
     • what was actually installed (concrete spec)

   • Can use this to reproduce a stack in different contexts, e.g.:

     • exactly the same stack, down to the architecture
     • same stack, different architecture/compiler
     • same stack, slightly different versions/variants
     • same stack according to only the user specs
       • i.e. only what the user asked for; otherwise use defaults for the reproducing machine
     • etc.

   • Elizabeth: needs to be some combination of user-editability and cmdline would be nice.

     • 1 file preferable for easy distribution
     • Todd & Elizabeth: user single file can be hard b/c you need to bundle packages, patches, etc.
       • single archive seems like it will be unwieldy if it's to be reproducible
     • Seems like we could have a YAML file kind of like Gemfile and/or pip's requirements.txt
       • user should edit user specs in this file or on command line.
       • "building" or "installing" this file generates a single file that allows the whole thing to be reproduced.

   • Elizabeth: note on reconcretization

     • option to reconcretize a spack context is important. Two options:
       1. add a new user spec to existing context;
          • reconcretize based on what's already in the context.
       2. reconcretize the whole thing from the user specs.

3. Greg Becker has a new PR allowing packages more control over their compiler flags

   • https://github.com/LLNL/spack/pull/4421
   • Unifies things like CFLAGS with the way Spack injects flags into the compiler wrappers.

4. We're adding a new configuration scope to Spack

   • /etc/spack scope -- for sysadmins on machines to provide reasonable defaults
   • Plan to use this on our Power/GPU machines
     • many different experimental compilers and MPI implementations floating around
     • need very specific settings for the particular hardware
     • want user compiles to "just work" on these systems.
   • Spack will check in /etc/spack for packages.yaml, compilers.yaml information
     • precedence would be to consider configs in this order (low to high, high overrides low):
       • defaults, /etc/spack, $spack/etc/spack, ~/.spack

Other discussion topics

• Tom Merrick is playing around with systemd and trying to get that to work
  • Currently not finding uchar.h
  • gcc builds its own libstdc++ that needs a config option or a patch
  • Potential source of nondeterminism in our gcc build (we should route this to spack's uchar.h)
• Tom is also having issues with R activation
  • https://github.com/LLNL/spack/issues/2951
  • some R base packages are bundled with R, which is pretty standard.
  • they're also in Spack so activating newer versions of them does not work well.
  • Todd: we should ping glennpj
• KT wants to share a spack install
  • share Trilinos package for all spack users
  • allow users to leverage this but experiment with higher-level dependencies
• KT has noticed that lua dependent installs are "escaping" from Spack
  • Ping @trws about this -- lua integration should be mirrorable.