Difference between revisions of "May 15, 2020 JLabCE Management + PSSC"
Jump to navigation
Jump to search
(One intermediate revision by the same user not shown) | |||
Line 43: | Line 43: | ||
** Hall C | ** Hall C | ||
** Hall D | ** Hall D | ||
+ | ** Hall EIC | ||
* Modules (e.g. "module load") | * Modules (e.g. "module load") | ||
* Options: | * Options: | ||
Line 57: | Line 58: | ||
== Minutes == | == Minutes == | ||
− | '' | + | Attendees: David L., Thomas B., Brad S., Dmitry R., Mark I., Mauri U., Nathan Baltzell., Ole H., Zhiwen Z. |
+ | |||
+ | '''JLabCE Introduction''' | ||
+ | * Mauri was put on the spot with no warning to give a brief introduction to JLabCE. | ||
+ | ** System for building and maintaining versions of dependency packages used by various groups throughout the lab | ||
+ | ** Copies of source code kept at JLab | ||
+ | *** Allows permanent, stable availability | ||
+ | *** Allows for custom, local patches (e.g. GEANT4) | ||
+ | ** Binaries maintained in /site/12gev_phys with variations for version number, OS, and compiler | ||
+ | ** Docker container maintained with a standard version set | ||
+ | ** Suggested we consider CVMFS distribution | ||
+ | |||
+ | '''What do Halls currently use''' | ||
+ | * Hall-A | ||
+ | ** Main thing used is ROOT build | ||
+ | ** Analyzer is not part of CE so is built/maintained external to it | ||
+ | ** Many people use private installations of dependency packages (may not be aware of JLabCE versions) | ||
+ | ** CREX and PREX use specialized pairity analyzer software (may not benefit much from centralized management) | ||
+ | * Hall-B | ||
+ | ** Uses some packages built as part of CE, but environment set by hall-specific Modules config files | ||
+ | * Hall-C | ||
+ | ** Similar to Hall-A in that experimental groups tend to be loosely coupled so not much formal interdependency on software | ||
+ | ** Some groups migrating more to containers (Singularity and Docker) | ||
+ | * Hall-D | ||
+ | ** Version sets maintained in XML files | ||
+ | ** Single XML file is used to build packages, set environment, and document a complete version set | ||
+ | ** No dependency on JLabCE at all | ||
+ | * Hall EIC | ||
+ | ** Used home-grown ejpm up to now | ||
+ | ** Looking to transition to [https://spack.readthedocs.io/en/latest/ spack] | ||
+ | |||
+ | '''Modules''' | ||
+ | * Nathan currently using in Hall-B with good success | ||
+ | * Well established standard | ||
+ | * [https://spack.readthedocs.io/en/latest/module_file_support.html Supported in spack] | ||
+ | * Allows for "uber"-modules to group multiple packages together | ||
+ | |||
+ | '''spack''' | ||
+ | * Dmitry suggested we take a strong look at ''spack'' which provides the functionality we need in a modern, popular package manager | ||
+ | * General consensus we should look into this | ||
+ | * David volunteered himself and Thomas to investigate ''spack'' and to develop a proposal in consultation with Mauri and Dmitry | ||
+ | * Once a proposal is formed, another ad hoc meeting will be called to review and refine it. |
Latest revision as of 20:23, 15 May 2020
Meeting to discuss EPSCI maintenance of JLabCE + Resurrection of Physics Software Support Committee
Connection Info:
You can connect using BlueJeans Video conferencing (ID :740 025 234). (Click "Expand" to the right for details -->):
Meeting URL https://bluejeans.com/740025234 Meeting ID 740 025 234 Want to dial in from a phone? Dial one of the following numbers: +1.888.240.2560 (US Toll Free) (see all numbers - https://www.bluejeans.com/premium-numbers) Enter the meeting ID and passcode followed by # Connecting from a room system? Dial: bjn.vc or 199.48.152.152 and enter your meeting ID & passcode
Agenda
- JLabCE Introduction - Maurizio
- Scientific Software Webpage
- CUE location: /site/12gev_phys
- Docker
- Docker Hub
- New location of Dockerfile https://github.com/gemc/docker
- Old location of Dockerfile https://gitlab.com/ESC/containers/-/tree/master/Docker/JLEIC/jlabce
- What do Halls currently use?
- Hall A
- Hall B
- Hall C
- Hall D
- Hall EIC
- Modules (e.g. "module load")
- Options:
- Keep same
- Drop centralized version set and build packages upon request
- Officially support group defined version sets
- Service Now: Category = "Physics Division Supported Software"
- AOT
Reference
Minutes
Attendees: David L., Thomas B., Brad S., Dmitry R., Mark I., Mauri U., Nathan Baltzell., Ole H., Zhiwen Z.
JLabCE Introduction
- Mauri was put on the spot with no warning to give a brief introduction to JLabCE.
- System for building and maintaining versions of dependency packages used by various groups throughout the lab
- Copies of source code kept at JLab
- Allows permanent, stable availability
- Allows for custom, local patches (e.g. GEANT4)
- Binaries maintained in /site/12gev_phys with variations for version number, OS, and compiler
- Docker container maintained with a standard version set
- Suggested we consider CVMFS distribution
What do Halls currently use
- Hall-A
- Main thing used is ROOT build
- Analyzer is not part of CE so is built/maintained external to it
- Many people use private installations of dependency packages (may not be aware of JLabCE versions)
- CREX and PREX use specialized pairity analyzer software (may not benefit much from centralized management)
- Hall-B
- Uses some packages built as part of CE, but environment set by hall-specific Modules config files
- Hall-C
- Similar to Hall-A in that experimental groups tend to be loosely coupled so not much formal interdependency on software
- Some groups migrating more to containers (Singularity and Docker)
- Hall-D
- Version sets maintained in XML files
- Single XML file is used to build packages, set environment, and document a complete version set
- No dependency on JLabCE at all
- Hall EIC
- Used home-grown ejpm up to now
- Looking to transition to spack
Modules
- Nathan currently using in Hall-B with good success
- Well established standard
- Supported in spack
- Allows for "uber"-modules to group multiple packages together
spack
- Dmitry suggested we take a strong look at spack which provides the functionality we need in a modern, popular package manager
- General consensus we should look into this
- David volunteered himself and Thomas to investigate spack and to develop a proposal in consultation with Mauri and Dmitry
- Once a proposal is formed, another ad hoc meeting will be called to review and refine it.