Example of batch job execution
This document is a former NIG supercomputer (2019) document and is kept for reference purposes.
Please note that it does not work in the same way on the current NIG supercomputer (2025).
Example 1: Running a binary file
The following example shows how to write typical options for running a batch job on the NIG supercomputer. ( For the full list of options, refer to man qsub, man qlogin, etc.).
qsub -cwd -V \
-l short \
-l d_rt=00:20:00 -l s_rt=00:20:00 \
-l s_vmem=1G -l mem_req=1G \
-N extract_flatfile \
-b y \
gzip -d ddbjvrt9.seq.gz
The -cwd
and -V
options in the first line relate to the running environment of the job.
Option | Description |
---|---|
-v environment | One job takes over the environment variables of the environment which executed the qsub. |
-v environment=value | Set one environment variable for each job. |
-V | All environment variables of the environment which executed qsub are passed on to the job. |
-cwd | The job is executed on the current directory. (If not specified, the job will run on the $HOME directory.) |
The second line represents the type of queue. A queue (Queue) is created for each type of worker node's computer in the GENERAL INSTITUTE supercomputer. If you do not specify any queue, the job is submitted to the epyc queue. ( The available worker nodes are searched for in the order of Type1b => Type1a).
Queue Name | Type of Compute Node | Maximum Job Execution Time | Initial Available Memory |
---|---|---|---|
intel | Thin node Type2a | 124 days | 8GB |
epyc | Thin node Type1a, Type1b | 124 days | Type1b 4GB, Type1a 8GB |
gpu | Thin node Type2b (GPU node) | 124 days | |
short | Thin node Type2b (GPU node) | 1 hour | |
medium | medium node | 124 days |
The third line is the maximum job running time.
For example, if you specify a maximum job running time of 8 days as the job is expected to be finished within 8 days, specify 192 hours (8 days x 24 hours) for the -l d_rt
and -l s_rt
options. -It is necessary to specify the same value for the -l d_rt
option and the -l s_rt
option.
qsub -l d_rt=192:00:00 -l s_rt=192:00:00 test.sh
Jobs can continue to run for up to four months, except for the short queue (maximum one hour). However, in order to facilitate job scheduling, the Grid Engine is configured in the GENETECH supercomputer to assume that the job will be completed within three days if the -l d_rt
or -l s_rt
option is not specified. Therefore, if the computation time is expected to exceed three days, be sure to specify the -l d_rt
and -l s_rt
options. (For correct job scheduling, it is recommended to always specify the -l d_rt
and -l s_rt
options. Specify a little longer than expected, as the programme execution will be forced to terminate when the execution limit time is reached).
The fourth line specifies the amount of memory to be used. Specify the same value for -l s_vmem
and -l mem_req
. The units can be G, M, K, etc.
Line 5 specifies the job name.
Line 6 indicates that a binary executable file is about to be executed (e.g. not a shell script).
Line 7 is the actual call to the programme to be executed on the worker node.
Example 2: Running shell scripts, etc.
qsub -cwd -V \
-l epyc \
-l d_rt=192:00:00 -l s_rt=192:00:00 \
-l s_vmem=20G -l mem_req=20G \
-N an_example \
-S /bin/bash \
example.sh arg1 arg2
The difference between example 1 and example 2 is lines 6 and 7. When calling scripts such as bash or perl, this is how you write it.
Example 3: Job Script
In the above examples 1 and 2, many options were specified, but you can simplify the call by writing the options in a script and calling that script.
To do this, prepare a job_script.sh
like the following and submit it with qsub -S /bin/bash job_script.sh
.
#!/bin/bash
#$ -cwd
#$ -V
#$ -l epyc
#$ -l d_rt=192:00:00
#$ -l s_rt=192:00:00
#$ -l s_vmem=20G
#$ -l mem_req=20G
#$ -N an_example
#$ -S /bin/bash
example.sh arg1 arg2