General information
With the , we also start using change to RHEL 9 for building our central module system available for all users. SPACK
SPACK has the advantage of allowing users to quickly build their own software packages themselves (if the package is supported, see “spack list <name>
”).
As the systemwide spack settings initially point to the read-only central installation, some of these settings have to be changed in order for users to build their own software via spack.
There are : a custom spack “environment”, or user specific config files in two ways~/.spack/
.
We recommend using an environment as listed below.
Creating:
spack env create <$HOME/path/to/environment> [myName4myEnv]
or (if you already are in that directory):
spack env create . [myName4myEnv]
Activating:
You can enable your environment with
spack env activate <$HOME/path/to/environment>
or using its symbolic name:
spack env activate myName4myEnv
Instead of “spack env activate
”, you can also use the shorter alias “spacktivate
”.
Deactivate
To leave the environment and return to the default settings, use
spack env deactivate
(or shorter: “despacktivate
”)
which will reduce your available modules again to those in the central SPACK module system.
SPACK Environment Config
Inside the environment you need to change some config settings. You can do this with “spack config edit
”, or by editing the <$HOME/path/to/environment>/spack.yaml
file with a text editor of your choice.
The config should be changed to look like this (comments “#…
” can be left out):
Environment spack.yaml
# This is a Spack Environment file.
#
# It describes a set of packages to be installed, along with
# configuration settings.
spack:
##### Config Settings #####
config:
install_tree:
root: ~/myspackapps
build_jobs: 16
build_stage:
- $tempdir/$user/spack-stage
- $user_cache_path/stage
test_stage: $user_cache_path/test
source_cache: ~/packapps/cache
misc_cache: $user_cache_path/cache
packages:
all:
permissions:
read: group
write: group
group: <YOUR USERID/TUID> # alternatively the GROUPID related to a project dir you want to use, need to change install_tree, too
gcc:
buildable: true
llvm:
buildable: true
intel-oneapi-compilers:
buildable: true
upstreams:
spack-instance-1:
install_tree: /shared/spapps
modules:
lmod: /shared/spmodules
##### Config Settings End #####
# add package specs to the `specs` list
specs: []
view: false
concretizer:
unify: when_possible
reuse: true
Software modules via SPACK
You can then add your software packages (in SPACK speak “specs”) to your environment as you wish.
Either use the spack
command -
spack add gcc@8 %gcc@11.4.1
or – before “activating it” – manually edit the <$HOME/path/to/environment>/spack.yml
file accordingly, followed then by “spacktivate
”.
To build (= compile + install) all specs added to your environment, use
spack install
or to just build a certain spec:
spack install gcc@8 %gcc@11.4.1
What's this @ and %:
The Spack syntax with “@” and “%” means here:
software@version
= create this software package in exactly this version%compiler@version
= using this compiler in exactly its version given
With a “:” (colon), you can also specify “from-to ranges” for versions:
software@1:3
= create either version 1, 2 or 3 of “software
”.
If you omit the “@version
” part altogether, Spack will use the most recent version of either “software
” or “%compiler
” (or the “preferred” compiler version for this “software
”, respectively).
Software modules via SPACK
LMod module files
If you want to have SPACK create “LMod readable” module files for your SPACK-built software, you need to configure a suitable module root directory in SPACK's <$HOME/path/to/environment>/spack.yml
file:
modules:
default:
roots:
lmod: ~/myspackmodules