job control

quick start example

(note: the file names used in this example (myprogram, my_input_file, my_output_file, myjob.qsub) are all examples. you can name your files whatever you want.)

let's say you have a program named myprogram and that you would normally run it on your own computer with the command:

% ./myprogram < my_input_file  > my_output_file

to run this on wesley do the following:

i. create a job script file that contains the following two lines. name it anything you like (we'll call it myjob.qsub in this example).

cd $pbs_o_workdir
./myprogram < my_input_file > my_output_file

place myjob.qsub in the same directory that contains myprogram and my_input_file.

ii. submit the job to the queue with the qsub command. the minimum arguments for qsub are the time limit and the name of the job script. for example,

% qsub -l walltime=2:30:00 myjob.qsub

in this example we specified a time limit of 2 hours and 30 minutes. if the job runs longer it will automatically be killed. (this feature is to prevent programs that might end up in infinite loops from wasting computer time).

after the qsub command is executed, the job will enter the queue and then run as soon as there is an available compute node. you can examine the queue any time using either the qstat or showq commands (both are useful since they describe the queue in slightly different ways).

when the job completes, besides any normal output files from the program, you will find two additional files that end with .ojobid and .ejobid. these are the standard output and error output that you would normally see on your screen.

note that it is safe to log out of wesley immediately after you submit the job with qsub. the job will remain in the queue and run normally even if you are no longer logged in.

commands to manage your jobs

submitting jobs

qsub
sqjobs

viewing job and queue status

userjobs
qstat
showq
freenode [-c][-a]

deleting/terminating jobs

qdel
sqkill