Apple
Open the ‘Terminal’ application. In the terminal window, type
1 | ssh <username>@snellius.surf.nl |
To redirect any graphic output from the HPC system to your own system, you’ll need a X-server like XQuartz. Then, log in to the HPC system using.
1 | ssh -X <username>@snellius.surf.nl |
Manual use of miniconda
Step 1: Get Miniconda
1 | wget https://repo.anaconda.com/miniconda/Miniconda3-py37_4.10.3-Linux-x86_64.sh |
Step 2: Install Miniconda
(“-b” skips all confirmations with “yes”)
1 | bash Miniconda3-py37_4.10.3-Linux-x86_64.sh -b |
Initialize conda.
1 | ~/miniconda3/bin/conda init |
Close the current terminal and start a new one.
Check that conda has been installed: the shell prompt should start with the name of the currently active conda-environment.
By default, this is “(base)”.
Try the version parameter.
1 | (base) username@hostname:~$ conda --version |
The actual version, of course, can differ.
Update conda.
1 | conda update conda -y |
Step 3: Create a virtual conda-environment
1 | conda create --yes --name 01_pandas1.3 pandas=1.3.0 |
Step 4: Activate the environment
1 | conda activate 01_pandas1.3 |
Step 5: Create a kernel from the environment
If you want to use your environment as a Jupyter-kernel, you can continue with this step.
Install the ipykernel tool into the environment.
1 | conda ``install` `--``yes` `--channel anaconda ipykernel |
Run the ipykernel tool. The display name will identify your environment/kernel in Jupyter Notebooks.
1 | python3 -m ipykernel ``install` `--user --name 01_pandas1.3 --display-name ``"Py Pandas 1.3" |
You can now leave the environment again.
1 | conda deactivate |
Snellius partitions
Compute nodes are grouped into partitions in order to allow the user to select different hardware to run their software on. Each partition includes a subset of nodes with a different type of hardware and a specific maximum wall time.
The partitions can be selected by users via the SLURM option:
1 | #SBATCH --partition=<partition name> |
or
1 | #SBATCH -p <partition name> |
The partitions available on Snellius are summarised in the table. For details of the different hardware available on each node, please look at the Snellius hardware and file systems page.
Getting account and budget information
You can view your account details using
1 | $ accinfo |
This shows information such as the e-mail associated with the account, the initial and remaining budget, and until when the account is valid.
An overview of the SBU consumption for the current account can be obtained with
1 | $ accuse |
By default, consumption is shown for the current login, per month, over the last year. Per day usage can be obtained by adding the -d flag. The start and end of the period shown in the overview can be changed with the -s DD-MM-YYYYand -e DD-MM-YYYY flags, respectively. Finally, consumption for a specific account or login can be obtained using -a accountname and -u username, respectively.
In case you want to know the CPU/GPU budgets separately, you can try:
1 | accinfo --product=cpu``accinfo --product=gpu |
SLURM batch system
Defining the requirements of a job
For the batch system to know which nodes to allocate to you, and for how long, you need to start your jobscript by defining options for the SLURM batch system. The SLURM system will read all lines from the start of your job script until the first non-comment or empty line that does not start #SBATCH - hence all your SLURM options should be at the start of your job script, before anything else.
Shell
You can define the interpreter for your job script with a shebang), just like in any other script. For example, if you want to use Bash, you should start your script with
1 | #!/bin/bash |
Wall clock time
You can set the duration for which the nodes remain allocated to you (known as the wall clock time), using
1 | #SBATCH -t ``1``:``30``:``00 |
The duration can be specified in minutes, or in the MM:SS, or HH:MM:SS format (as in the example), of on the D-HH:MM:SS. In general, the maximum walltime for CPU jobs is 120 hours (5 days); for jobs submitted to the GPU queue, the maximum walltime is 120 hours. Some queues have a different maximum walltime.
Choose your wall clock time carefully: if your job is still running after the wall clock time has exceeded, it will be cancelled and you will lose your results!
In general, we recommend timing a minimal version of your computational task in order to estimate how long the total task will take. Then, choose your wall clock time liberally based on your expected runtime (e.g. 1.5-2x higher). Once you gain more experience in running similar-sized jobs, you could consider setting walltimes more accurately, as shorter jobs are slightly easier for the scheduler to fit in.
Partition
On our systems, different types of node are grouped into partitions each having different limit for wall-clock time, job size, access limitation, etc. Partitions can overlap, i.e. compute nodes can be contained in several partitions (e.g.: “normal” and “short” partitions share a large number of nodes but they have different maximum wall time limit).
Users can therefore request specific a node type by submitting to the partition which contain it (from the one available on each system).
To set the partition you want to submit to, use the -p argument. For example to run on the thin partition (available on Snellius) you would need to specify:
1 | #SBATCH -p thin |
If you don’t specify a partition, your job will be scheduled on the thin partition by default. You can check all available partitions, including their maximum walltime and number of nodes, using the sinfo command.
The available compute partitions that batch jobs can be submitted to can be listed by issuing the following command
1 | sinfo |
You can get a summary of the available partitions by using the -s flag.
1 | sinfo -s |
The available partitions of Snellius are described here.