Starting at distribution 5785 most of our scientific software is available via the Spack packages manager. Form a user perspective, these software packages are available as modules. However, there are some differences between these modules and other modules.
Spack modules are not automatically available on most hosts. To make them available, enter the command
module load spackThen, if you execute “module avail”, you will see that a rather large number of packages was added to the list. You can also load a specific Spack based package directly (in your sbtach scripts, etc), using for example:
module load spack netcdf-fortranNote that this will load all the dependencies of the module as well, so in this case netcdf-c and openmpi will be loaded too.
In order to ensure the widest comparability, most of the Spack packages are compiled for the plain x86 CPU model. In specific cases, where this may be a problem (of performance or anything else), we do support CPU model variations. See more details about this in the “CPU model variation” section of this page.
Spack packages may vary in 3 aspects: The software version, the CPU model, and the compiler, used to compile the package. This information (in addition to the CPU model version) is manifested in the packages listing, according to the scheme:
<package name>-<package version>-<cpu model>-<compiler>-<uuid>
Notice that just like with other modules, one version of the package is the default, marked by (D) and that when mentioning a module name you can always specify just the prefix to the point where it is unique. So for example, to load Java 1.8, you can execute:
module load openjdk/1.8
In order to properly use Spack modules in your scripts, you usually have to know the absolute path of the package (so that you know where libraries and include files are). You can find this information by executing
module display <package>
For example:
$ module display netcdf-fortran
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
/etc/lmod/spack/x86-64-v1/netcdf-fortran/4.6.1-x86_64-gcc-12.2.0-4d45por:
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
whatis("NetCDF (network Common Data Form) is a set of software libraries and machine-independent data formats that support the creation, access, and sharing of array-oriented scientific data. This is the Fortran distribution.")
depends_on("gcc-runtime/12.2.0-x86_64-gcc-12.2.0-hkheshq")
depends_on("glibc/2.36-x86_64-gcc-12.2.0-xbrglcy")
depends_on("netcdf-c/4.9.2-x86_64-gcc-12.2.0-wgshx3j")
prepend_path("PATH","/usr/local/spack/opt/spack/linux-debian12-x86_64/gcc-12.2.0/netcdf-fortran-4.6.1-4d45porhetdhr462vjbcw7ejqp5jacii/bin")
prepend_path("MANPATH","/usr/local/spack/opt/spack/linux-debian12-x86_64/gcc-12.2.0/netcdf-fortran-4.6.1-4d45porhetdhr462vjbcw7ejqp5jacii/share/man")
prepend_path("PKG_CONFIG_PATH","/usr/local/spack/opt/spack/linux-debian12-x86_64/gcc-12.2.0/netcdf-fortran-4.6.1-4d45porhetdhr462vjbcw7ejqp5jacii/lib/pkgconfig")
prepend_path("CMAKE_PREFIX_PATH","/usr/local/spack/opt/spack/linux-debian12-x86_64/gcc-12.2.0/netcdf-fortran-4.6.1-4d45porhetdhr462vjbcw7ejqp5jacii/.")
setenv("SPACK_PACKAGE_PATH","/usr/local/spack/opt/spack/linux-debian12-x86_64/gcc-12.2.0/netcdf-fortran-4.6.1-4d45porhetdhr462vjbcw7ejqp5jacii")
setenv("SPACK_VARIANTS","~doc+pic+shared build_system=autotools")
append_path("MANPATH","")
help([[Name : netcdf-fortran
Version: 4.6.1
Target : x86_64
NetCDF (network Common Data Form) is a set of software libraries and
machine-independent data formats that support the creation, access, and
sharing of array-oriented scientific data. This is the Fortran
distribution.
]])
Notice especially, the line that specifies SPACK_PACKAGE_PATH and SPACK_VARIANTS
SPACK_PACKAGE_PATHThis is the root path of the software packages. If you were using software from /usr/local/hurcs/<software> for example, then this path should replace /usr/local/hurcs/<path> everywhere. We will make our best to keep the root path of packages static. However, to be on the safe side (and also because it is more elegant), you may want to include some lines in your scripts to extract these paths into variables. For example, if you are using netcdf-fortran then you need the locations of netcdf-fortran, netcdf-c and openmpi, so you can do something like:
module load spack
...
function load_package_get_path {
module load $1
echo $SPACK_PACKAGE_PATH
}
...
netcdf_mpi=$(load_package_get_path openmpi)
netcdf_c_path=$(load_package_get_path netcdf_c)
netcdf_f_path=$(load_package_get_path netcdf_fortran)
And then you can use these variables as the packages root
SPACK_VARIANTSThis variable is not very useful as a a variable, but it shows the specific options of the package ("Spack variant"). So if you need one of several package variants, this is how you can tell which is which.
Spack provides man python packages that are used in scientific computing. The modules of Python packages are named “py-<package>”. For example, the module for “pandas” appears as “py-pandas”
You can use Spack python modules in combination with a python virtualenv, but you have to set the virtualenv before you load the Spack modules. For example:
source <venv-dir>/bin/activate.csh
module load spack py-mpi4pyThis order also ensures that you will be able to pip install packages that depend on Spack packages. For example:
source <venv-dir>/bin/activate.csh
spack load cartopy
pip install scitools-iris
We do not encourage using Conda, nor we support it officially. However, miniconda3 is available as a Spack module. To initialize your conda environment correctly. You can use the load_package_get_path function, that was described above, like this:
module load spack
source $(load_package_get_path miniconda3)/etc/profile.d/conda.sh
conda activate <path to conda env>
Our Spack repository is designed for a CPU model variation. You will notice that the Spack packages are grouped based on the model version, as x86_v<n> (and that the model version appears in the package name too). The rule, by which the version is set, is this:
if grep -q avx512f /proc/cpuinfo; then
echo "x86-64-v4"
elif grep -q avx2 /proc/cpuinfo; then
echo "x86-64-v3"
elif grep -q sse4_2 /proc/cpuinfo; then
echo "x86-64-v2"
else
echo "x86-64-v1"
fi
At this point, we will compile packages for a variation, other than plain x86 on demand. So if you want us to create a version of a software package or tool that supports avx512 for example, please let us know