Difference between revisions of "Jobscript"

From HPC Wiki
Jump to navigation Jump to search
m
 
(50 intermediate revisions by 5 users not shown)
Line 1: Line 1:
 +
[[Category:Basics]]
 
== General ==
 
== General ==
  
A jobscript can be used to submit the job you wish to execute to a batch system. It is similar to a [[sh-file]] and generally uses the same format, but is more powerful. Besides shell commands, you can put the so called magic cookie #BSUB. This allows you to specify a lot of parameters, e. g. the time and memory your application requires or - if your code runs in parallel - the number of compute slots to employ.
+
A jobscript can be used to submit the job you wish to execute to a [[Batch-Scheduler]]. It is very similar to a [[sh-file]] and generally uses the same format, but is more powerful. Besides shell commands, you can use so-called magic cookies, e.g. #BSUB for [[LSF]] systems. This allows you to specify a lot of parameters, e.g. the time and memory your application requires or - if your code runs in parallel - the number of compute slots to employ.
  
  
== #BSUB Usage ==
+
__TOC__
  
To use the magic cookie, start a new line in your script with "#BSUB". Following that, you can put one of the parameters shown below, where the word written in <...> should be replaced with a value.
 
  
 +
== Structure ==
  
 +
Like a regular [[sh-file]], your jobscript should start with a shebang (#!), e. g. in case you are using [[Shell|zsh]]:
 +
<syntaxhighlight lang="zsh">
 +
#!/usr/bin/env zsh
 +
</syntaxhighlight>
  
The big advantage of jobscript is that the parameters that are prefixed with "#BSUB", are treated just like command line arguments. By setting them inside your jobscript already, it's easier to adjust them or look them up later.
+
Usually, this first line is followed by several directives using magic cookies, that are explained in more depth in the next section.
 +
The third part of a jobscript consists of shell commands, for example, to change to your working directory, to load the needed [[Modules]] and to execute your application.
  
 +
== Magic Cookies ==
 +
 +
The magic cookie differs from [[Batch-Scheduler]] to Batch-Scheduler. Click [[Schedulers|here]] to figure out which one you are going to need.
 +
Depending on your batch system, these pages provide more information on how to use magic cookies in your jobscript: [[LSF#.23BSUB_Usage|LSF]], [[SLURM#.23SBATCH_Usage|SLURM]], [[Torque]].
 +
 +
One advantage of jobscripts is that the parameters that are prefixed with magic cookies are treated like comments. So you can run your jobscript as an [[sh-file]] without the [[Batch-Scheduler]] and if that works, still adjust and correct the lines with magic cookies destined for the [[Batch-Scheduler]].
  
 
== Job Submission ==
 
== Job Submission ==
  
$ bsub < jobscript.sh
+
Depending on your [[Schedulers|Batch-Scheduler]], proceed to one of the links below to find out how to submit your job to a batch system that controls the resources for computation:
 
+
[[LSF#Job_Submission|LSF]], [[SLURM#Job_Submission|SLURM]], [[Torque#Job_Submission|Torque]].
Note that, when you submit your job to the batch system as shown above, it may take some time before it leaves the queue and starts running. This waiting time depends on the current workload of the machines, as well as the time and memory you asked for in your jobscript. The rule of thumb is: the more resources your job needs (execution time, memory), the longer it will be queued.
 
  
You can always check the current status (pend or run) of your submitted jobs with the following shell command. It also prints the job ids.
+
Note that all incoming jobs (defined in a jobscript) are added to a queue. The [[Batch-Scheduler]] decides at what time a certain job is executed. The waiting time depends on various factors, e. g. the time and memory you asked for in your jobscript. The rule of thumb is: the more resources your job needs, the longer it will be queued.
  
$ bjobs
+
You can always check the current status of your submitted jobs and their ids with shell commands that are also explained on the pages linked above.
  
In order to remove a job that you submitted, you can type this command:
+
== References ==
  
$ bkill <job_id>
+
[[jobscript-examples|Jobscript examples]]

Latest revision as of 07:23, 4 September 2019

General

A jobscript can be used to submit the job you wish to execute to a Batch-Scheduler. It is very similar to a sh-file and generally uses the same format, but is more powerful. Besides shell commands, you can use so-called magic cookies, e.g. #BSUB for LSF systems. This allows you to specify a lot of parameters, e.g. the time and memory your application requires or - if your code runs in parallel - the number of compute slots to employ.



Structure

Like a regular sh-file, your jobscript should start with a shebang (#!), e. g. in case you are using zsh:

#!/usr/bin/env zsh

Usually, this first line is followed by several directives using magic cookies, that are explained in more depth in the next section. The third part of a jobscript consists of shell commands, for example, to change to your working directory, to load the needed Modules and to execute your application.

Magic Cookies

The magic cookie differs from Batch-Scheduler to Batch-Scheduler. Click here to figure out which one you are going to need. Depending on your batch system, these pages provide more information on how to use magic cookies in your jobscript: LSF, SLURM, Torque.

One advantage of jobscripts is that the parameters that are prefixed with magic cookies are treated like comments. So you can run your jobscript as an sh-file without the Batch-Scheduler and if that works, still adjust and correct the lines with magic cookies destined for the Batch-Scheduler.

Job Submission

Depending on your Batch-Scheduler, proceed to one of the links below to find out how to submit your job to a batch system that controls the resources for computation: LSF, SLURM, Torque.

Note that all incoming jobs (defined in a jobscript) are added to a queue. The Batch-Scheduler decides at what time a certain job is executed. The waiting time depends on various factors, e. g. the time and memory you asked for in your jobscript. The rule of thumb is: the more resources your job needs, the longer it will be queued.

You can always check the current status of your submitted jobs and their ids with shell commands that are also explained on the pages linked above.

References

Jobscript examples