Running Interactive Jobs

Login nodes are most suitable for code development and debugging. Non-interactive batch processing is an environment for running jobs that take more than a few minutes and which require no interactions between the user and the application software. There are occasions where longer duration jobs that require user interaction may arise, hence a third category: Interactive Batch Session. With interactive batch, you can “checkout” one or more processors for hours of interactive use (think of that as your exclusive login shell). Use this judiciously as the interactive nature of the session often lends itself to lots of idling of the dedicated processors compared to non-interactive batch. Examples of interactive batch usages include:

• Running long-duration interactive MATLAB, R, IDL, etc. sessions
• GUI-based debugging requiring substantial run time
• Running timing benchmarks to study serial/parallel code performance

 

Interactive Job Using SCC Ondemand

The easiest way to run an interactive job on the SCC is through SCC OnDemand

“My Interactive Jobs” menu allows to see all running interactive jobs and to connect to them if the previous connection was interrupted.

 

Running Interactive Job From a Terminal

You can start an interactive job from a terminal (an application installed on your local computer and connected to the cluster using an ssh command). You can use one of the two methods: qrsh or qsh. The following table lists the major differences between them:

	qsh	qrsh
X-forwarding is required	✓	—
Session is opened in a separate window	✓	—
Allows for a graphics window to be opened by a program	✓	✓
Current environment variables can be passed to the session	✓	—
Batch-system environment variables ($NSLOTS, etc.) are set	✓	✓

Both methods have a default wallclock limit of 12 hours which users may override. Many options available to the qsub command can be used with qsh and qrsh commands.

For graphics and GUI-based applications, qsh delivers better performance than qrsh.

qrsh

The session invoked with qrsh command will start in your current window and, as such, does not require x-forwarding. However, if you want to start a graphics application within this session, you need to have x-forwarding enabled.

scc % qrsh

The above command requests exclusive access to one processor on one of the compute nodes with a default 12-hour wall time. This time allotment is more than adequate for most interactive batch jobs. If you need to request a longer time or other additional resources, you can add necessary options. For example, to request an interactive session with 4 processors for 24 hours:

scc % qrsh -l h_rt=24:00:00 -pe omp 4

To request an interactive session on a node with a GPU with the compute capability of 3.5:

scc % qrsh -P project_name -l gpus=1 -l gpu_c=3.5

By default, if an interactive batch request cannot be fulfilled immediately, you will see a message:

scc % qrsh 
Your "qrsh" request could not be scheduled, try again later.

To wait until a slot on the compute node becomes available to schedule an interactive session, add the -now n option to the qrsh command line:

scc % qrsh -now n

To exit the interactive session, type exit at the prompt.

qsh

Interactive sessions invoked using qsh will start in a separate xterm window and therefore require x-forwarding. This method allows a user to start Graphics or GUI-based applications.

scc % qsh 
Your job jobID ("INTERACTIVE") has been submitted
waiting for interactive job to be scheduled ...
Your interactive job jobID has been successfully scheduled.

The usage procedures for the qrsh commands are almost identical to those of qsh, although you cannot pass current environment variables (using the -V option).