The basic startup instructions for using Sun Grid Engine at the Institute of Astronomy are given in the IoA user guide (accessible only from the IoA or MRAO for some reason); this page is intended to be a few hints and tips once you've read that.
There are two ways of giving options to Sun Grid Engine, either on the command line to `qsub', or via lines starting with the magic incantation `#$' in your Sun Grid Engine script [1]. I'd advise using the `<samp>#$</samp>' method if possible as this keeps the options with the code they're being used to run. Self-documentation is good.
Some of the more useful options:
Option | Effect |
---|---|
-cwd | Run the job in the directory `qsub' was run from, rather than your home directory. |
-e <filename> and -o <filename> | Send the standard error and standard output (respectively) of your program to files given. (If you don't give this option, they will be send to `<job name>.e<job id>' and `<job name>.o<job id>', where <job id> is a unique number used by Sun Grid Engine to identify your job). |
-m and -M <email-address> | -m sets the conditions under which Sun Grid Engine will send a `status' e-mail; you probably want `-m bea' which will send mail when the job begins, when it ends and if it is aborted for any reason. To use this feature, you'll also have to set the -M option to specify the e-mail address you want the messages sent to [2]. |
-S | Sets the interpreter used to process this script. I'd
advise starting every Sun Grid Engine script with something like:
#!/usr/bin/tcsh #$ -S /usr/bin/tcshso the script is run by the same interpreter, independent of whether it is run under Sun Grid Engine or not. (I've put `tcsh' in that example as it's the default shell on the IoA machines; do see the University Computing Service's page on Csh Programming Considered Harmful, though). |
-l <name>=<value> | Set various limits for your job, thus restricting
which machines it can run on. The most useful of these are probably:
|
Due to a rather bizarre design decision[3] on the part of Sun, `qsh' doesn't work straight out of the box (at least for local logins on our system). If your `$DISPLAY' environment variable is set to `:0.0' or `localhost:0.0', change it to being `<host name of your machine>:0.0' (eg `cass45:0.0' if you happen to be me), and things may start working again. I'd appreciate any feedback on the success of this workaround.
You may also like to see Richard's SGE page, which say much the same as here, but in a more user-friendly fashion.
[1] It's possible to change this magic string via the `-C' command line option. I'd advise doing this only if you're using an interpreter which doesn't recognise `#' as a comment character though.
[2] The default for the -M option (which is <userid>@<machine you ran `qsub' from>) doesn't work. (If you really want to know why, it's because most of the machines in the department don't run an MTA, and they don't have MX records).
[3] Not doing the workaround automatically like most other programs manage to do...