Excerpt |
---|
Pawsey provides and maintains a number of prebuilt libraries and applications on Setonix, most of which are installed and managed through Spack. This page outlines how users can use Spack to install additional software or different builds of existing software that are not provided by Pawsey supported modules. |
...
To familiarise yourself with Spack features and concepts, read the Spack documentation (external site).
Note |
---|
Please keep in mind that versions listed in examples may change as new software stacks are deployed. |
Motivation for using Spack
...
Note | ||
---|---|---|
| ||
The Spack setup at Pawsey is capable of handling both system-wide and user package installations. However, the current implementation does not properly generate user modulefiles for interpreted languages such as Python and R. For Python package installations, we recommend using pip or setuptools, see: Installing Python Packages For R package installations, we recommend using the R package manager, see: Installing R Packages |
Note | ||
---|---|---|
| ||
The 0.17.0 version of Spack currently deployed on Setonix does not support installations of applications depending on ROCm, the AMD GPU computing platform. We will soon deploy a new software stack with a more recent version of Spack. |
Using Spack
First, the Spack module has to be loaded:
$ module load spack/0.17.0
...
Using Spack
First, the Spack module has to be loaded:
$ module load spack/0.21.0
Users can invoke Spack with the spack
command. spack
accepts a subcommand, or Spack command, as the first argument:
...
Column | |||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||
|
Install a package for the entire project team
Pawsey provides a utility script, called spack_project.sh
introduced a new Spack subcommand, spack project
, to perform package installations with Spack that need to be visible to for the entire project team, rather than just a single user.
This script is a drop-in replacement for the spack
command:
$ spack_project.sh $ spack project spec <arguments>
$ spack _ project .sh install <arguments>
The key differences compared to spack
are the locations where packages are installed and modulefiles are created:
- Software:
/software/projects/<project-id>/setonix/<datetag>/software/<arch>/<compiler>/<package>-<version>-<unique_hash>
- Modulefiles:
/software/projects/<project-id>/setonix/<datetag>/modules/<cpu-arch>/<compiler-name>/<compiler-version>/<package>/<version>-<unique_hash>.lua
...
/software/projects/<project-id>/<user-id>/setonix/<datetag>/modules/<cpu-arch>/<compiler-name>/<compiler-version>/<package>/<version>-<unique_hash>.lua
...
Column | |||||||||
---|---|---|---|---|---|---|---|---|---|
| |||||||||
|
Installing a software package from a user-modified source code
...
.
Column | |||||
---|---|---|---|---|---|
|
Installing a software package from a user-modified source code
It is quite common for users to modify or patch the code of popular applications such as LAMMPS and Gromacs. You can use Spack to install the modified code as long as there exists a recipe for it (otherwise you can always create one). Here is an example on how to install a modified Gromacs source code.
First, we need a Spack recipe that takes a tar file from the current working directory rather than the Internetthe current working directory rather than the Internet (note that this is a long command so next line won't display properly in a small window):
$ cp -r /software/setonix/20222024.1105/spack/var/spack/repos/builtin/packages/gromacs $MYSOFTWARE/setonix/spack_repo/packages
...
in the same directory of the tar file.
Uninstalling software built with Spack
To remove the modules created with Spack use the command:
$ spack module lmod rm
and answer questions from the promt.
To remove the installed software with Spack use the command:
$ spack uninstall <package>@<version>
and answer questions from the promt.
Software built with Spack
Spack makes use of dynamic libraries and rpath
when building software. The use of rpath
means that executables contain the paths in which libraries are search searched for at runtime. The result of using rpath
is that runtime are reproducible as executables will always point to the same library regardless of environment at runtime. A consequence of this is that if software has been built with not the desired version and build of library, it is not easy to have the executable use a different version. The package must be rebuilt with the different version of the library.
...