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:
qsh. The following table lists the major differences between them:
|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
For graphics and GUI-based applications,
qsh delivers better performance than
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.
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