View source for BioCompute Cluster


== How to set up a unix account: ==

To obtain a unix user name and password, create an account by registering at https://registrar.cs.huji.ac.il/account.

== Connecting to the hm server: ==

Before connecting to the hm server, an SSH connection needs to be set up. Instructions for set-up can be found at http://wiki.cs.huji.ac.il/wiki/Connecting_from_outside.
 
Every time you connect to the system, you will need to use a One-Time password (OTP) in addition to your unix (IDng) password. Instructions for obtaining OTPs can be found at http://wiki.cs.huji.ac.il/wiki/Password_and_OTP.

 
It is helpful to set up an FTP connection for easy file transfer between your desktop computer and the server. To do this with MobaXterm:

Create a new SFTP session by clicking on 'Session' and then 'SFTP'. Fill in the basic settings so that remote host = localhost, username = <your unix user name>, and the port = 9001. For example:
 
 [[File:Mobaxtermfig1.png]]
 
You will then need to create an SSH tunnel by clicking on 'Tunneling' and then 'New SSH Tunnel', and fill in the fields (using your unix user name) as follows:
 
[[File:Mobaxterm2.png]]
 
Before you start the transfer you will need to:

1 - start the tunnel by clicking on 'Tunneling' and press  the  [[File:arrow.png]] button

2- provide an OTP to open the tunnel

3- start the FTP connection by double clicking on the SFTP session

4- enter your unix password

The connection will eventually time out (you will see that the [[File:arrow.png]] button will no longer be pressed) after which you will need to re-do steps 1-4 to re-open it.

 
== Basic linux commands: ==


For an introduction to some basic linux commands, take a look at the https://wiki.cs.huji.ac.il/Intro_hm_cluster.pdf presentation.

== Understanding the file system: ==

The file system is divided into two main directories – icore and lustre.

Your icore directory can be found in /cs/icore/<your unix user name>. Icore is backed up with snapshots so a few previous versions of all files will be saved even after they are modified/deleted (assuming that the file system is up and running), however it has limited space. '''Icore should be used mainly to store your scripts'''. You should keep a copy of your scripts on Git, which allows you to save different versions. To use Git to back up scripts, see http://wiki.cs.huji.ac.il/wiki/Github.

Your lustre directory can be found in /mnt/lustre/hms-01/fs01/<your unix user name>. '''Lustre should be used mainly to store the data that you are currently working on''' as it is meant for quick and efficient computations. '''IMPORTANT: lustre is not backed up!''' This means that files on lustre that are accidentally deleted will be lost forever, so p'''lease be sure to back up all important files (e.g. on an external hard drive).'''

There are graphical interfaces that can make navigating the file system easier. For example, the nautilus file manager (can be opened with the command 'nautilus >& /dev/null &') and gedit text editor ('gedit >& /dev/null &'). For more information, take a look at the Intro_hm_cluster.pptx presentation.

== Using slurm on the hm cluster:  ==

The hm cluster currently has 44 nodes on which jobs can run. Slurm is a job scheduler that decides which node(s) a job will run on based on the job's requested resources (e.g. number of cpus, amount of memory, etc…), the availability of idle nodes, and the priority of the user which depends on how many jobs were run in the past.

All jobs should be submitted as sbatch scripts to slurm where they will be queued and will start running as soon as all of their requested resources become available.

Some resource arguments that most users will want to tweak are:

{| cellpadding=5 style="border:1px solid #BBB"
|Argument || Default value || Maximum value || Description || Notes 
|-
| -c, --cpus-per-task || 2 || 32 || number of cpus for job || Maximum depends on CPU used in cluster, hm I-CORE cluster is 32.
|-
| --mem || 50MB || ~64GB or ~128GB || memory allocation for job || Depends on memory of nodes, we have nodes with 64GB and 128GB of memory, you can't request all the memory since some is needed for the OS, if you want it all and don't care which node you can use: MaxMemPerNode. See below for more details.
|-
| -t, --time || 2 hours || 31 days || time limit for job || Currently 31 days may be reverted to 21 days later.
|-
| -N, --nodes || 1 || 44 || number of nodes to run job on ||Currently 44, may be increased in the future, either due to additional hardware purchases or reassigning of submit/test hosts to 'active duty' compute nodes.
|}

 

For more information on all sbatch arguments, e.g., the proper format for writing time limits, etc…, read the sbatch manual https://slurm.schedmd.com/sbatch.html.

== Submitting a job to the slurm queue: ==


There are 2 general ways to submit jobs using sbatch:

'''1. one-liner'''

Resources can be requested as arguments on the command line, for example:

<span style="font-family:Courier;">sbatch -N 2 --mem 8GB --wrap script.sh </span>

The above command will submit ''script.sh'' as a job to slurm with two nodes and 8GB of RAM requested. The --wrap argument is needed so that the script (or command) is wrapped in an sbatch script.
 
To run a command with arguments, you need to enclose the command and its arguments in quotes, for example:
 
<span style="font-family:Courier;">sbatch –o output.txt --wrap 'head -n 20 file.txt' </span>
 
The above code will submit the command 'head -n 20 file.txt' as a job to slurm and will write the output of the command (the first 20 lines of ''file.txt'') to the file ''output.txt.'' 
 

'''2. sbatch script (recommended)'''

Resources can be requested by adding special argument comments to bash scripts. These start with #SBATCH and then contain the sbatch argument, and will be parsed by sbatch until the script starts, so an #SBATCH argument written after the first command of the script will be ignored by sbatch. Here is an example of a bash script called ''my-sbatch-script.sh'' with sbatch arguments:

<span style="font-family:Courier;">#!/bin/bash<br>#SBATCH --mem 10GB<br>echo "hello world"<br># The following line will not be parsed by sbatch<br>#SBATCH --time 10</span>

The above script can then be submitted to the slurm queue from the command line as follows:

<span style="font-family:Courier;">sbatch my-sbatch-script.sh </span>
 
my-sbatch-script.sh will be submitted as a job to the slurm queue with 10GB of RAM requested. The time limit for the job will be the default two hours since the time parameter will not be parsed by sbatch as it is written after a command in the script.

== Requesting resources: ==


Make sure that your job does not request more resources than the maximum (please refer to table above). '''Jobs that request more than the maximum number of resources will not run.'''


'''Requests should be kept to as close to the needs of your job as possible''' for two main reasons:

1-      jobs are prioritized in the queue mainly based on requested resources, meaning that the more resources requested, the longer the job will take to start running since it needs to wait for all resources to become available

2-       while a job is running, all of its allocated resources will be unavailable to other users even if the job is not using them


'''Requesting multiple nodes:'''

Requesting multiple nodes for a specific job does not automatically divide the job among the nodes. There are a few ways to use multiple nodes simultaneously in order to save computation time:

1-      using mpirun

2-      using srun

3-      using an outer submit script – this is recommended as it is the simplest method 


1- using mpirun:

If you know that you are running a program that depends on OpenMPI, you can use mpirun to run the program on multiple nodes in parallel – see the mpi manual  (https://www.mpi-forum.org/docs/) for more information.


2- using srun:

Srun can be used within an sbatch script to utilize a subset of the total requested resources. It can be used to run a command using multiple nodes in parallel which is most useful if you want to run a script/command on many files at the same time, each as its own job on one node, for example:

<span style="font-family:Courier;">#!/bin/bash<br> #SBATCH -N 5<br> <br> files=(file0 file1 file2 file3 file4)<br> <br> for i in {0..4}<br> do <br>         srun -N 1 –o output.$i.txt head –n 20 ${files[$i]} &<br> done</span>

The above script will allocate five nodes as requested, and then will send five jobs to the slurm queue at the same time, each running on one node. The output of each job (the first twenty lines of the corresponding file) will be printed in the ''output.{i}.txt'' file. If you submit the above script as a job without using the srun command, for example:

<span style="font-family:Courier;">#!/bin/bash<br>#SBATCH -N 5<br> <br>files=(file0 file1 file2 file3 file4)<br> <br>for i in {0..4}<br>do<br>        head –n 20 ${files[$i]} &<br>done</span>

Once the above job starts running, it will hold five nodes unavailable to other users as requested, but it will only run on one node.


3- using an outer submit script:

The simplest way to run a script/command on many files at the same time, each as its own job on one node, is by using a for loop in a script that submits all of the jobs at once. For example:

<span style="font-family:Courier;">#!/bin/bash<br> <br>files=(file0 file1 file2 file3 file4)<br> <br>for file in ${files[*]}<br>do<br>      sbatch head.sh $file<br>done</span>

The above script loops through all files in the list 'files' and submits the script ''head.sh'' (with 'file' as an argument) as an sbatch job. The ''head.sh'' script will contain the sbatch arguments needed to run on one file. For example:

<span style="font-family:Courier;">#!/bin/bash<br>#SBATCH –o output.txt<br>#SBATCH –N 1<br>file=$1 #first argument from outer script<br>head –n 20 $file</span>
 
The ''head.sh'' script will be run as a job on one node (based on the sbatch arguments written in the script) on each of the 5 files in parallel.


'''Requesting multiple cpus:'''

If you are running a program that supports multithreading, you can request multiple cpus (up to the maximum) and then run the program while specifying the number of cpus you want it to use as a parameter. For example:

<span style="font-family:Courier;">#!/bin/bash<br>#SBATCH –c 32 #request 32 cpus<br>#SBATCH –o output.txt<br>sample=$1<br>bowtie2 -p 32 -x $genome -U $sample -S $sam >& bowtie2.log<br></span>

The above script can be submitted as a job that will run bowtie2 using 32 cpus on 'sample' (with the bowtie2 output saved in the file ''bowtie2.log'').
 

'''Requesting memory:'''

If the amount of memory requested is not enough for the job, it will be killed with an error message that the job exceeded the memory limit and you will need to increase the memory request. There is currently no simple method to know how much memory a job will need before it runs. Once an sbatch job is running you can check its accounting information with the 'sacct' command.

For more information, read the CS slurm wiki http://wiki.cs.huji.ac.il/wiki/Slurm.

== FAQs ==


1.  How do I check the status of my job?


By running the command 'squeue –u username' with your username you will see all of your submitted jobs and their status (ST column). PD means your job is pending in the queue waiting to start, and R means it is running. For a list of all status codes, read the 'JOB STATE CODES' section of the squeue manual https://slurm.schedmd.com/squeue.html.


2.  How do I cancel a job?


Jobs can be cancelled by running the command 'scancel jobid' where the jobid is the number that slurm assigned your job when it was submitted which you can see by running 'squeue –u username' and looking at the JOBID column.


3.  Why is my job taking so long to start running?


Jobs are prioritized in the slurm queue mainly based on the amount of resources requested. The more resources your job requests, the longer it will take to start running.


4.  How much memory/cpus did my job actually use?


When a job is running, you can use the following commands to see its accounting information:

sacct – see the sacct manual for more details (https://slurm.schedmd.com/sacct.html).

sstat – see the sstat manual for more details (https://slurm.schedmd.com/sstat.html).


5.  Can I submit a job and tell it to run at a later time?


You can tell a job what time you want it to start running with the parameter --begin:

<span style="font-family:Courier;">#SBATCH --begin HH:MM MM/DD/YY</span>
 
<nowiki>Alternatively, you can add dependencies to your jobs so that, for example, job #2 will not start until job #1 satisfies the provided condition, by using the job id. This can be done in a bash script:</nowiki>

<span style="font-family:Courier;">#!/bin/bash<br>jobid1=$(sbatch job1.sh)<br>sbatch –-dependency afterok:jobid1 job2.sh </span>
 
The above script submits ''job1.sh'' as a job and saves jobid in the variable jobid1. It then submits ''job2.sh'' as a job only once job1 finishes running with an exit code of 0 as defined by the condition 'afterok'. For more information on possible conditions, etc… please refer to the sbatch manual https://slurm.schedmd.com/sbatch.html.