Lmake

Job Scheduling

• Some computing jobs take a lot of time: hours, days, weeks,...
• We do not want to keep a command-line window open the whole time; therefore we run such jobs in the background
• Simple commands to do it in Linux:
  • To run the program immediately, then switch the whole console to the background: screen, tmux
  • To run the command when the computer becomes idle: batch
• Now we will concentrate on Sun Grid Engine, a complex software for managing many jobs from many users on a cluster consisting of multiple computers
• Basic workflow:
  • Submit a job (command) to a queue
  • The job waits in the queue until resources (memory, CPUs, etc.) become available on some computer
  • The job runs on the computer
  • Output of the job is stored in files
  • User can monitor the status of the job (waiting, running)
• Complex possibilities for assigning priorities and deadlines to jobs, managing multiple queues etc.
• Ideally all computers in the cluster share the same environment and filesystem
• We have a simple training cluster for this exercise:
  • You submit jobs to queue on vyuka
  • They will run on computer cpu02
  • This cluster is only temporarily available until next Thursday

Submitting a job (qsub)

Basic commad: qsub -b y -cwd 'command < input > output 2> error'

• quoting around command allows us to include special characters, such as <, > etc. and not to apply it to qsub command itself
• -b y treats command as binary, usually preferable for both binary programs and scripts
• -cwd executes command in the current directory
• -N name allows to set name of the job
• -l resource=value requests some non-default resources
• for example, we can use -l threads=2 to request 2 threads for parallel programs
• Grid engine will not check if you do not use more CPUs or memory than requested, be considerate (and perhaps occasionally watch your jobs by running top at the computer where they execute)
• qsub will create files for stdout and stderr, e.g. s2.o27 and s2.e27 for the job with name s2 and jobid 27

Monitoring and deleting jobs (qstat, qdel)

Command qstat displays jobs of the current user

• job 28 is running of server cpu02 (status <t>r), job 29 is waiting in queue (status qw)

job-ID  prior   name       user         state submit/start at     queue       
------------------------------------------------------------------------------
     28 0.50000 s3         bbrejova     r     03/15/2016 22:12:18 main.q@cpu02
     29 0.00000 s3         bbrejova     qw    03/15/2016 22:14:08             

• Command qstat -u '*' displays jobs of all users
• Finished jobs disappear from the list
• Command qstat -F threads shows how many threads available

queuename                      qtype resv/used/tot. load_avg arch          states
---------------------------------------------------------------------------------
main.q@cpu02.compbio.fmph.unib BIP   0/2/8          0.03     lx26-amd64
        hc:threads=0
     28 0.75000 s3         bbrejova     r     03/15/2016 22:12:18     1
     29 0.25000 s3         bbrejova     r     03/15/2016 22:14:18     1

• Command qdel deletes a job (waiting or running)

Interactive work on the cluster (qrsh), screen

Command qrsh creates a job which is a normal interactive shell running on the cluster

• In this shell you can manually run commands
• When you close the shell, the job finishes
• therefore it is a good idea to run qrsh within screen
  • run screen command, this creates a new shell
  • within this shell, run qrsh, then whatever commands
  • by pressing Ctrl-a d you "detach" the screen, so that both shells (local and qrsh) continue running but you can close your local window
  • later by running screen -r you get back to your shells

Running many small jobs

For example, we many need run some computation for each human gene (there are roughly 20,000 such genes). Here are some possibilties:

• Run a script which iterates through all jobs and runs them sequentially
  • Problems: Does not use parallelism, needs more programming to restart after some interruption
• Submit processing of each gene as a separate job to cluster (submitting done by a script/one-liner)
  • Jobs can run in parallel on many different computers
  • Problem: Queue gets very long, hard to monitor progress, hard to resubmit only unfinished jobs after some failure.
• Array jobs in qsub (option -t): runs jobs numbered 1,2,3...; number of the current job is in an environment variable, used by the script to decide which gene to process
  • Queue contains only running sub-jobs plus one line for the remaining part of the array job.
  • After failure, you can resubmit only unfinished portion of the interval (e.g. start from job 173).
• Next: using make in which you specify how to process each gene and submit a single make command to the queue
  • Make can execute multiple tasks in parallel using several threads on the same computer (qsub array jobs can run tasks on multiple computers)
  • It will automatically skip tasks which are already finished, so restart os easy

Make

Make is a system for automatically building programs (running compiler, linker etc)

• In particular, we will use GNU make
• Rules for compilation are written in a Makefile
• Rather complex syntax with many features, we will only cover basics

Rules

• The main part of a Makefile are rules specifying how to generate target files from some source files (prerequisites).
• For example the following rule generates file target.txt by concatenating files source1.txt and source2.txt:

target.txt : source1.txt source2.txt
      cat source1.txt source2.txt > target.txt

• The first line describes target and prerequisites, starts in the first column
• The following lines list commands to execute to create the target
• Each line with a command starts with a tab character

• If we have a directory with this rule in file called Makefile and files source1.txt and source2.txt, running make target.txt will run the cat command
• However, if target.txt already exists, the command will be run only if one of the prerequisites has more recent modification time than the target
• This allows to restart interrupted computations or rerun necessary parts after modification of some input files
• make automatically chains the rules as necessary:
  • if we run make target.txt and some prerequisite does not exist, make checks if it can be created by some other rule and runs that rule first
  • In general it first finds all necessary steps and runs them in appropriate order so that each rules has its prerequisites ready
  • Option make -n target will show which commands would be executed to build target (dry run) - good idea before running something potentially dangerous

Pattern rules

We can specify a general rule for files with a systematic naming scheme. For example, to create a .pdf file from a .tex file, we use the pdflatex command:

%.pdf : %.tex
      pdflatex $^

• In the first line, % denotes some variable part of the filename, which has to agree in the target and all prerequisites
• In commands, we can use several variables:
  • Variable $^ contains the names of the prerequisites (source)
  • Variable $@ contains the name of the target
  • Variable $* contains the string matched by %

Other useful tricks in Makefiles

Variables

Store some reusable values in variables, then use them several times in the Makefile:

MYPATH := /projects/trees/bin

target : source
       $(MYPATH)/script < $^ > $@

Wildcards, creating a list of targets from files in the directory

The following Makefile automatically creates .png version of each .eps file simply by running make:

EPS := $(wildcard *.eps)
EPSPNG := $(patsubst %.eps,%.png,$(EPS))

all:  $(EPSPNG)

clean:
        rm $(EPSPNG)

%.png : %.eps
        convert -density 250 $^ $@

• variable EPS contains names of all files matching *.eps
• variable EPSPNG contains desirable names of .png files
  • it is created by taking filenames in EPS and changing .eps to .png
• all is a "phony target" which is not really created
  • its rule has no commands but all .png files are prerequisites, so are done first
  • the first target in a Makefile (in this case all) is default when no other target is specified on the command-line
• clean is also a phony target for deleting generated .png files

Useful special built-in target names

Include these lines in your Makefile if desired

.SECONDARY:
# prevents deletion of intermediate targets in chained rules

.DELETE_ON_ERROR:
# delete targets if a rule fails

Parallel make

Running make with option -j 4 will run up to 4 commands in parallel if their dependencies are already finished. Ths allows easy parallelization on a single computer.

Alternatives to Makefiles

• Bioinformaticians often uses "pipelines" - sequences of commands run one after another, e.g. by a script or make
• There are many tools developed for automating computational pipelines, see e.g. this review: Jeremy Leipzig; A review of bioinformatic pipeline frameworks. Brief Bioinform 2016.
• For example Snakemake
  • Snake workflows can contain shell commands or Python code
  • Big advantage compared to make: pattern rules may contain multiple variable portions (in make only one % per filename)
  • For example, assume we have several FASTA files and several profiles (HMMs) representing protein families and we want to run each profile on each FASTA file:

rule HMMER:
     input: "{filename}.fasta", "{profile}.hmm"
     output: "{filename}_{profile}.hmmer"
     shell: "hmmsearch --domE 1e-5 --noali --domtblout {output} {input[1]} {input[0]}"