SGE: Submitting Your First Job With Examples

Submitting a simple serial job to the queue (your own compiled application)

Assuming that you have correctly compiled your application to an executable called myprogram , a simple script to:

  • submit the job from your current working directory using your current module environment
  • using 1 hour of runtime
  • email you at the start and end of your job

 

Once the script has been saved to a file (e.g. sample_script.sh ), it can be submitted to the queue with the qsub command:

Submitting a serial application job to the queue (using ‘R’ as an example)

To run R (for example) in batch-mode you must first generate a list of commands for R to process in a file, e.g. r.in.

A script must then be created that will request resources from the queuing system and launch the R executable, for example runR.sh :

This can then be submitted to the queuing system using:

In this example, any results will then be made available in the file r.out .

Requesting an interactive session from the queue (using ‘R’ as an example)

A number of applications (R included) can run as interactive sessions as well as batch processes.
The queue system allows users to run a program on the back-end compute nodes but only if the required resources are available at the time the request is made.

The following will launch R interactively via the batch queue.

h_rt is the length of run-time the shell will exist for, so to run R for 6 hours:

Note that <option> must be set to one of

Option Description
--save DO save workspace at the end of the session
--no-save DON’T save workspace at the end of the session
--vanilla Combine --no-save , --no-restore , --no-site-file , --no-init-file and --no-environ

This will run R from within the terminal from which it was launched.

If qrsh can’t allocate resources to you within a couple of minutes it will report back with an error, particularly at busy times. Resubmitting your qrsh request normally works.

Checking the status of your job

Once you have submitted your job to the queue, you can check on its status using the qstat command. You will see a report displayed something like this:

The state column will indicate the progress of your job:

Code
Meaning
qw waiting in the queue to start
t transferring to a node (about to start)
r running
h job held back by user request
E error

Removing a job from the queue

If you want to remove a job from the queue, you can use the qdel command (perhaps there’s a bug in your code or you don’t need to run it anymore).

First, run qstat to get the job-ID of your job (it’s the leftmost column in the example above). Then:

( qdel 3049 in this example)

Altering the status of a job in the queue

It is possible to do this, but only with jobs that are still queuing.

If your job is currently running so it is more straightforward just to delete it by using qdel and then resubmitting a revised job to the queue.

If the job is still queued, you can change some of the parameters:

Get the jobid by running the qstat command (it will be the left hand column in the table displayed).

Find all the -l parameters from your submission script:

An example result might be:

Change the parameter you want, so here change the runtime from the initial 4 hrs to (say) 6 hours and then use the qalter command to alter the job entry in the queue: