# Quick Start¶

It is possible to change your initial password using the usual unix command passwd on a login node. University of Cambridge users should note that this will make it different to your UIS Password - see the UIS Password Management Application <https://password.csx.cam.ac.uk> for changing the latter. Note that the security of both users’ data and the service itself depends strongly on choosing the password sensibly, which in the age of automated cracking programs unfortunately means the following:

• Use at least 10 characters
• Use a mixture of upper and lower case letters, numbers and at least one non-alphanumeric character
• Do not use dictionary words, common proper nouns or simple rearrangements of these
• Do not use family names, user identifiers, car registrations, media references, …
• Do not re-use a password in use on another system (this is for damage limitation in case of a compromise somewhere).

Tip

Passwords should be treated like credit card numbers (and not left around, emailed or shared etc). The above rules are similar to those which apply to systems elsewhere.

## Filesystems¶

Please see here for a summary of available filesystems and the rules governing them.

## Modules¶

We use the modules environment extensively. A module can for instance be associated with a particular version of Intel compiler, or different MPI libraries etc. Loading a module establishes the environment required to find the related include and library files at compile-time and run-time.

By default the environment is such that the most commonly required modules are already loaded. It is possible to see what modules are loaded by using the command module list

[abc123@login-e-7 ~]$module list Currently Loaded Modulefiles: 1) dot 7) rhel7/global 2) slurm 8) cuda/8.0 3) java/jdk1.8.0_45 9) gcc-5.4.0 4) turbovnc/2.0.1 10) openmpi-1.10.7 5) vgl/2.5.1/64 11) rhel7/default-gpu 6) singularity/current  The above shows that SLURM (the job queueing system software), as well as the Intel compilers and the Intel MPI environment are loaded (these are actually loaded as a result of loading the default- module, which is loaded automatically on login). Further commands: module load <module> -> load module module unload <module> -> unload module module purge -> unload all modules module list -> show currently loaded modules module avail -> show available modules module whatis -> show available modules with brief explanation  There are currently a large number of historical modules inherited from older systems that appear in response to module avail. Please avoid modules with names such as “sandybridge” and “nehalem” in their paths and prefer modules exhibiting the Spack hash (-4qrgkot in the example above). ## .bashrc¶ The default environment should be correctly established automatically via the modules system and the shell initialization scripts. For example, essential system software for compilation, credit and quota management, job execution and scheduling, error-correcting wrappers and MPI recommended settings are all applied in this way. This works by setting the PATH and LD_LIBRARY_PATH environment variables, amongst others, to particular values. Please be careful when editing your ~/.bashrc file, if you wish to do so, as this can wreck the default settings and create many problems if done incorrectly, potentially rendering the account unusable until administrative intervention. In particular, if you wish to modify PATH or LD_LIBRARY_PATH please be sure to preserve the existing settings, e.g. do export PATH=/your/custom/path/element:$PATH
export LD_LIBRARY_PATH=/your/custom/librarypath/element:\$LD_LIBRARY_PATH


and don’t simply overwrite the existing values, or you will have problems. If you are trying to add directories relating to centrally-installed software, please note that there is probably a module available which can be loaded to adjust the environment correctly.

Users who are returning to CSD3 after working on Darwin or Wilkes1 should check their ~/.bashrc files and if necessary DELETE any pre-existing lines such as these:

module load default-impi


since these will now interfere with the proper environment settings on CSD3 nodes.

It is highly recommended not to load modules in ~/.bashrc, as this may cause unexpected problems.

## Compiling¶

Note that the default-peta4 module, which is loaded by default on the Peta4 clusters, arranges for mpicc, mpif90 etc to be found and to use the Intel compilers automatically when invoked. These wrapper commands supply the correct flags for compiling with Intel MPI (which is currently the default MPI implementation for Peta4 compute nodes).

When compiling code, it is usually possible to remove any direct MPI library references in your Makefile as mpicc & mpif90 will take care of these details. In the Makefile, simply set

CC=mpicc


etc, or define

export CC=mpicc


etc in the shell before compilation.

If some required libraries are missing, please let us know and we can try to install them centrally (as a module).

## Running¶

Please note that the following resource limits apply:

On Peta4-Skylake, SL1 and SL2 users are limited to 1280 cores in use at any one time and a maximum wallclock runtime of 36 hours per job. On Peta4-KNL, SL1 and SL2 users are limited to 128 nodes in use at any one time and a maximum wallclock runtime of 36 hours per job. On Wilkes2-GPU, SL1 and SL2 are limited to 64 GPUs in use at any one time and a maximum wallclock runtime of 36 hours per job. SL3 users are similarly limited to 320 cores (Peta4-Skylake), 64 nodes (Peta4-KNL) and 32 GPUs (Wilkes2-GPU), all with up to 12 hours per job. For more information, please see this full description of service levels (SLs).

Please see the example job submission scripts under /usr/local/Cluster-Docs/SLURM. There are example scripts for launching an MPI application on Peta4 and Wilkes2 via the queueing system:

/usr/local/Cluster-Docs/SLURM/slurm_submit.peta4-skylake

/usr/local/Cluster-Docs/SLURM/slurm_submit.peta4-knl

/usr/local/Cluster-Docs/SLURM/slurm_submit.wilkes2


Copying this example file and then modifying the top section (where indicated) will create a script suitable for submission to the batch queueing system via the command sbatch.

There are also examples of submission scripts for specific applications in this documentation - see for example CASTEP or LAMMPS.

Peta4 and Wilkes2 operate the SLURM batch queueing system for managing resources. Some useful commands:

squeue      -> show global cluster information
sinfo       -> show global cluster information
sview       -> show global cluster information
scontrol show job nnnn -> examine the job with jobid nnnn
scontrol show node nodename -> examine the node with name nodename
sbatch      -> submits an executable script to the queueing system
sintr       -> submits an interactive job to the queueing system
srun        -> run a command either as a new job or within an existing job
scancel     -> delete a job
mybalance   -> show current balance of core hour credits


Once your application is compiled, e.g. to a binary called prog, it can be submitted to the queueing system as follows (we assume it is destined for Peta4-Skylake).

Firstly, copy the template SLURM submission script:

cp /usr/local/Cluster-Docs/SLURM/slurm_submit.peta4-skylake slurm_submit


(Note that for convenience newer users may have symbolic links to these template files in their home directories - these are read-only so making a copy is still necessary.)

Edit the copy slurm_submit, setting application to “prog” and workdir to the correct working directory. Set options to contain any desired command line options, e.g “>outfile 2>errfile” would redirect stdout and stderr to files which could be monitored while the job runs. Note the comment lines at the head of the script:

#! Which project should be charged:
#SBATCH -A CHANGEME
#! How many whole nodes should be allocated?
#SBATCH --nodes=2
#! How many (MPI) tasks will there be in total? (<= nodes*32)
#! How much wallclock time will be required?
#SBATCH --time=02:00:00
#! For 6GB per CPU, set "-p skylake"; for 12GB per CPU, set "-p skylake-himem":
#SBATCH -p skylake


These are comments to bash, but are interpreted by SLURM as requests to use 2 nodes, with 64 tasks in total (which because each Peta4-Skylake node has 32 cores, completely utilizes each node), for 2 hours of wall time (i.e. actual time as measured by a clock on the wall, rather than CPU time). Finally, the following command submits the job to the queueing system:

sbatch slurm_submit


Please note that each Peta4-Skylake node has 32 CPU cores, and one should normally be careful not to start more working processes or threads per node than there are CPUs per node.

Furthermore the Peta4-Skylake nodes come in two sizes - 6GB per CPU (192GB total RAM) and 12GB per CPU (384GB total RAM). These sizes are selected by the #SBATCH -p partition directive, i.e.

#SBATCH -p skylake


for 6GB per CPU nodes, and

#SBATCH -p skylake-himem


for 12GB per CPU nodes. Jobs requesting more than 6GB per CPU may still be submitted to the skylake partition, but may be automatically assigned extra CPUs to cover the additional memory, and will therefore be charged more usage credits. Therefore it is recommended that whenever possible jobs requiring more than 6GB per CPU be submitted to skylake-himem.

The Wilkes2-GPU nodes each contain 4 NVIDIA P100 GPUs. It is possible to request 1, 2, 3, or 4 GPUs for a single node job, but multinode jobs will need to request 4 GPUs per node, which would be done by using the directives

#SBATCH -p pascal
#SBATCH --gres=gpu:4


(see /usr/local/Cluster-Docs/SLURM/slurm_submit.wilkes2).

The Peta4-KNL nodes are specialised nodes each containing 256 logical CPUs, however only entire nodes are allocated. The memory mode of the KNL nodes allocated can be specified with the #SBATCH -C option. By default cache mode is assumed, but flat mode could be required using the directives

#SBATCH -p knl
#SBATCH -C flat


(see /usr/local/Cluster-Docs/SLURM/slurm_submit.peta4-knl). SLURM may need to reboot nodes if insufficiently many nodes in the desired mode can be found; this may introduce a startup delay of up to 30 minutes.

The job’s status in the queue can be monitored with squeue; alternatively use qstat or showq (add -u username to focus on a particular user’s jobs).

The job can be deleted with scancel <job_id> or qdel <job_id>.

When the job finishes (in error or correctly) there will normally be one file created in the submission directory with a name of the form slurm-NNNN.out (where NNNN is the job id).

## Problems¶

Please check first of all whether there is an answer to your question in the FAQ. If not, please request support with your details and job submittion scripts.