5-Minute Intro

To submit a job to the grid engine, use

$ echo "ls" > myscript
$ qsub myscript
Your job 600093 ("myscript") has been submitted

Creates myscript.o600093 and myscript.e600093 in your home directory, which contain the output of the job (…o… is stdout, …e… is stderr).

If you want the script to start in the current working directory (the one from which you run 'qsub'), then use the command-line option -cwd. Also, use -V if the script should use the same environment as the one qsub was started with. This is often what you want, especially the !PATH is often not set correctly if you don't do this. Use -N name to give the script a different name

$ qsub -cwd -V -N "rhubarb" myscript
Your job 600095 ("rhubarb") has been submitted.

Since -cwd was used, the output will be written to rhubarb.o600095 rhubarb.e600095 in the current directory.

If you want your job to run on the Opterons, then use the parameters -q '*@@i386hosts' (or see below for other possible host groups). If you do not specify where the job should run, it will be sent to a !SPARC machine.

Very important, in case you make a mistake: qdel <jobid> or qdel -u <username> deletes jobs.

To see what jobs are running, use qstat, or qstat -u <username>.

Other switches

Read the man page for details!

Use -o filename and -e filename to specify the exact file names for stdout and stderr (if not given, then !JOBNAME.o!JOBID/!JOBNAME.e!JOBID is used, as above).

Staying in the working directory

Use -cwd to make your script start automatically in the directory which was the working directory at the time qsub was called.

qsub -cwd myscript.sh

Host Groups

(Taken from a mail to the cluster-user mailing list.)

Note: We strongly discourage the use of the “-l arch=…” option. Instead, specify an appropriate host group when submitting jobs. For example, if you have code that submits jobs that should run on the AMD Opteron systems only, replace any occurrence of

  • qsub -l 'arch=sol-x86' /some/path/command.sh

with

  • qsub -q '*@@i386hosts' /some/path/command.sh

(The “double-at” in this example is not a typo! ;-)

The following currently defined host groups are probably useful for the restriction of your compute jobs:

host group members
@i386hosts all Opteron-based systems
@largehosts Opteron-based with more than 4G RAM
@sparchosts all !SPARC-based systems
@t1 Netra T1 systems
@x1 Netra X1 systems
@netras all Netras (X1 and T1)
@smphosts !SPARC systems with 8 or more !CPUs, 64G RAM or more

Data Directories

Frage: Was genau ist technisch der Unterschied zwischen /vol/cluster-data und /vol/cluster-data-nocache und wann sollte ich welchen Pfad benutzen?

Antwort: Beide verzeichnisse ziegen physikalisch auf dieselben daten. die nocache-variante greift direkt zu und ist damit beim lesen und schreiben so schnell oder langsam, wie man es gewohnt ist.

die /vol/cluster-data/ variante greift uber cachefs zu. dies sorgt dafuer, dass beim mehrfachen lesen vom selben host die daten bereits lokal auf dem host liegen, und somit der fileserver nicht belastet wird. (und somit auch schneller ist, als normal)beim ersten lesen und beim scheiben ist diese variante deutlich langsamer.

generell: /vol/cluster-data/ ist zu verwenden, wenn viele hosts oft auf dieselben daten lesend zugreifen. das ist z.b. fuer sequenzdatenbanken oder auch programmdateien selbst der fall.

in allen anderen faellen, kann man die nocache variante nehemen.

auf KEINEN fall den cluster auf dateien im homedir rechnen lassen!!! auch scripte sollten dort besser nicht liegen. zum testen auf 5 hosts ok, fuer produktive sachen NIE. (sprengt uns den normalen fileserver!)