Local changes to the qsub script

The qsub and qalter commands have a local option -Q, which is recommended to select the logical queue for the job. As on the other HPCF systems, its value is made up of a letter and a number, with the former specifying the time the job may run for and the latter the number of CPUs it may use. This may have values:

• u2 - 2 CPUs on 1 node for 10 minutes
• u4 - 4 CPUs on 2 nodes for 10 minutes
• u8 - 8 CPUs on 4 nodes for 10 minutes
• u16 - 16 CPUs on 8 nodes for 10 minutes
• u32 - 32 CPUs on 16 nodes for 10 minutes
• u64 - 64 CPUs on 32 nodes for 10 minutes
• t2 - 2 CPUs on 1 node for 2 hours
• t4 - 4 CPUs on 2 nodes for 2 hours
• t8 - 8 CPUs on 4 nodes for 2 hours
• t16 - 16 CPUs on 8 nodes for 2 hours
• t32 - 32 CPUs on 16 nodes for 2 hours
• t64 - 64 CPUs on 32 nodes for 2 hours
• s2 - 2 CPUs on 1 node for 24 hours
• s4 - 4 CPUs on 2 nodes for 24 hours
• s8 - 8 CPUs on 4 nodes for 24 hours
• s16 - 16 CPUs on 8 nodes for 24 hours
• s32 - 32 CPUs on 16 nodes for 24 hours
• s64 - 64 CPUs on 32 nodes for 24 hours
• u2-l - 2 CPUs on 1 node for 10 minutes with 4GB per cpu
• u4-l - 4 CPUs on 2 nodes for 10 minutes with 4GB per cpu
  
• u8-l - 8 CPUs on 4 nodes for 10 minutes with 4GB per cpu
• u16-l - 16 CPUs on 8 nodes for 10 minutes with 4GB per cpu
• u32-l - 32 CPUs on 16 nodes for 10 minutes with 4GB per cpu
• t2-1 - 2 CPUs on 1 node for 2 hours with 4GB per cpu
• t4-1 - 4 CPUs on 2 nodes for 2 hours with 4GB per cpu
• t8-l - 8 CPUs on 4 nodes for 2 hours with 4GB per cpu
• t16-1 - 16 CPUs on 8 nodes for 2 hours with 4GB per cpu
• t32-1 - 32 CPUs on 16 nodes for 2 hours with 4GB per cpu
• s2-l - 2 CPUs on 1 node for 24 hours with 4GB per cpu
• s4-l - 4 CPUs on 2 nodes for 24 hours with 4GB per cpu
• s8-l - 8 CPUs on 4 nodes for 24 hours with 4GB per cpu
• s16-l - 16 CPUs on 8 nodes for 24 hours with 4GB per cpu
• s32-l - 32 CPUs on 16 nodes for 24 hours with 4GB per cpu

The logical queues are simple queue environments with an associated environment variable. If you use the -q option, you must also set the parallel environment and the number of processors to the same as in the environment name, and must use the number of CPUs actually allocated. You can then set the number of CPUs you intend to use with the HPCF_SLOTS environment variable. For example, `-q s32 -pe mpich 32' is equivalent to `-Q s32'. You are advised to use the -Q, form, for simplicity.

There is a pair of local options, -priority and -nopriority that may be used to select the priority (`charged') mechanism or deselect it. The default will usually be priority, if you have access to it; unfortunately, it is not possible to set the default yourself. While you can set the underlying parameter yourself (it is the Gridengine project, set by the -P argument), you are not advised to, as we may need to fiddle with the project names and other aspects.

The -e, -i and -o options must not specify remote hostnames, because the HPCF uses a common user directory model and jobs will be run on whatever machines are available. The -w option may be set to only e or v, mainly because no other settings make sense on the HPCF.

The -ac, -A, -c, -dc, -display, -hard, -inherit, -l, -m, -M, -masterq, -noshell, -nostdin, -ot, -P, -q, -sc, -soft and -u options must not be used. Note that checkpointing would be a useful feature if it worked and did not cause major trouble, but that has not been the case on any system at any time in the past 40 years.

If the command option -hpcf_dryrun is specified, the script will print out the expanded command that it would have called and the environment that it would use, and do nothing. This is unlikely to be of much use to users.

None of the environment variables SGE_ROOT, SGE_CELL, COMMD_PORT or COMMD_HOST may be used. The first should be set up correctly on login, and the others are not supported.