In HPC, you are usually dealing with massive multi-user systems and while many software packages are used by multiple users (and thus are preferably maintained centrally on the system), each user has his/her special requirements on the composition of these software packages and their various versions/flavours (and often these requirements even change for the same user for different projects). In order to manage this in a flexible, yet efficient way, we offer an easy-to-use environment module system which allows you to add/remove software from your personal OS environment at will, while at the same time protecting you from having inconsistencies in the selection that may cause unpredictable problems with your code (e.g. due to conflicts between simultaneously loaded library packages).

The whole installation and maintenance of the software is taken off by your local IT experts. The only thing you have to deal with is to tell the system which software you need. For this, the module command is used. Common operations are:

• To list all available modules, use:
  module av
  A typical output looks like this: All the modules are grouped into four different categories for a better overview (this does not affect the way you load or unload them):
  • core : modules for system architecture support, software bundles and essential services
  • compilers : modules for all installed/supported compilers
  • mpi : modules for all installed/supported MPI implementations/libraries
  • libraries : system libraries to compile and/or run your programs with
  • applications : applications & runtime environments that are provided & maintained for all users
• To show more information about a specific module, use:
  module help <modulename>
  A typical output for a moduke that depends on both a compiler and MPI library would look like this:
• To load/unload a module, use
  module load <modulename>
  module unload <modulename>
  Some modules cannot be loaded at the same time, e.g. you can only have a single compiler or MPI library being loaded at any given time to avoid any conflicts.
• To check which modules are currently loaded, use
  module list

Any dependencies among libraries (e.g. prerequisites of certain compiler/MPI versions) are automatically resolved. If a library or application is not supported by the current setup, a list of compatible setups will be provided.

For more information on the use of module and its command-line arguments, please consult the manpage.

The SCIAMA HPC system has not a homogeneous infrastructure. The login nodes, SCIAMA-1, SCIAMA-2 \& SCIAMA-3 do all feature different system architectures (e.g. CPU types). So they also all require very carefully optimized software environments to perform at their full potential. For any pre-installed software or library, this is all taken care of in the background for you. The only (and first thing (!)) you ALWAYS need to do when using the SCIAMA software module system is to pick and load your target system module from the following list:

• system/intel64 (default) : support module for generic 64-bit systems. This covers all parts of the SCIAMA HPC system (login nodes \& compute nodes), but does not provide any special optimization for any of the subsystems.
• system/sciama-{2,3,4} : support modules for SCIAMA-2, SCIAMA-3 and SCIAMA-4 respectively. Use these modules if you want to get versions of the compilers, libraries and applications that are specifically optimized for the system architecture of these systems (some applications may not have been optimized yet. In these cases, the more generic 64bit versions will be used instead. To check whether an optimized version exists for a specific software module, check the output of module help).

 

For information on how to optimize your own code/software

          –> see here

There exist a few predefined software/library bundles for your convenience. These contain a selection of commonly used libraries and applications to save you the time to worry about checking for compatible modules and to make it easier for you to reproduce the environments used for your projects. The following bundles are provided at the moment:

• bundles/<year>.<release>/serial (default): legacy bundle that contains the recommended compilers \& libraries for serial code at the time of creation (usually once or twice a year). These combinations of libraries have been tested for their compatibility and have a guaranteed long-term support.
• bundles/<year>.<release>/serial_oss : like the serial legacy bundle, but with the recommended open source compiler \& library alternatives.
• bundles/<year>.<release>/parallel : legacy bundle that contains the recommended compilers \& libraries for parallized code at the time of creation (usually once or twice a year). These combinations of libraries have been tested for their compatibility and have a guaranteed long-term support.
• bundles/<year>.<release>/parallel_oss : like the parallel legacy bundle, but with the recommended open source compiler \& library alternatives.
• bundles/tools : list of frequently used tools that will be updated in regular intervals (gv, gnuplot, mathematica, octave, maui, torque, etc.)

While it is possible to sequentially load all modules by hand, there is a quicker way to reload a software environment for a specific project/software. Simply write a file that contains all necessary module load requests (and a purge to clear all already loaded modules), e.g. my.modules

module purge
module load system/sciama-1
module load bundles/tools
module load intel_comp/2017.2

and source it either in the command line:

or as part of your submission batch script for running jobs on SCIAMA:

#!/bin/bash

#SBATCH --job-name=my_job
#SBATCH --ntasks=1
#SBATCH --partition=training.q

# set up the software environment to run your job in
source my.modules

srun ./myapplication ‐i ~/data/some_inputfile