This manual has already discussed a number of features that make Linux a very powerful command line environment. One of the best features of all is that anything that can be typed on the command line can be automated by putting the same commands in a shell script.
Users that only run software already installed on the supercomputers may not need to read this section of the manual. Users who write their own software, want to do system administration, or find themselves doing a large amount of repetitive typing should read on.
A shell script, or just script, is different from a binary program in that the script is not compiled into an executable, machine language file. A script is a text file which contains commands in some scripting language. The script language interpreter executes the commands as it reads that text file. The advantage of shell scripts is that they are easy to write and automate tasks. The disadvantage is that they run much slower than compiled programs and are thus not an appropriate way to write the main program that uses thousands of hours of CPU time. Shell scripts automate many tasks within the operating system, and for the convenience of the users. Often scripts wrap the computationally intensive program, meaning that the shell script stages input data to the working directory, sets up environment variables, creates a nodes list, calls the computationally intensive program, then copies the results back to the users home directory.
There are thousands of scripting languages. Here are just a few to consider. Bourne shell scripts can be used to automate tasks on both Linux and Unix computers. Bash shell scripts have some enhanced features, but are specific to Linux and not on most Unix systems by default. Perl is a scripting language specifically for generating
reports of data with a tabular format. Python is a scripting language powerful enough to approach the level of capability of a compiled programming language, thus making it sometimes ideal for rather large scripting projects that aren’t quite big enough to justify going to a compiled language. The rest of this section of the manual will discuss Bourne shell scripting only.
A shell is the process which interacts with the commands issued by a logged-on user. Each logged-on user has his own shell. A new shell (and even multiple new shells) can be created by a user with the command “sh”. The command can also execute shell scripts.
For example If the file named “check” contained the lines #
date who
then the command
sh check
would create a separate shell from the one the user is operating under, execute the commands (printing the date and the current users on the screen), and return to the user's original shell. The new shell would disappear as soon as the commands were finished executing.
To create a check file that can be executed directly, without typing sh every time, write it like this.
#!/bin/sh date
who
Then make it be an executable file with the command
chmod +x check
Now you can just type “check”. This shell script works as though it is any other program, even though it is not a compiled program.
Another useful scripting feature is to use the accent character (backwards single quote at the top left of the keyboard) to feed the output from a command into a variable in the script, like this.
myname=`whoami`
This can be combined with the pipe discussed previously to make the following script, that we named myqstat
#!/bin/sh
# This shows only my jobs from qstat5 myname=`whoami`
qstat5 | grep $myname
Once the chmod command is used to make myqstat executable, you can type “myqstat” and see a listing of only your own jobs in the queue system. This is much more convenient than wading through thousands of lines of output to find the relevant information.
Scripts can contain many of the constructs found in other languages such as variables, loops, arrays, conditional statements (“if” statements), and subroutines. Some scripting languages have very rich feature sets, such as Python having more string processing functions than most compiled languages. Many books on scripting with titles containing phrases like “Unix Shell Programming”, “Learning BASH”, “Python”, or “Linux Shell Scripting” can be found at most book stores and libraries. A selection of these books are listed in the Bibliography at the end of this manual.
8. Working with the Queue System
Nearly all supercomputing facilities use a job queue system. A job queue system is similar to a printer queue in that a pile of work can be submitted then the queue system software will start each job when the necessary resources become available. In the case of a job queue system, the resources being managed are computer processors, memory, and sometimes software licenses.
The queue system is the researcher’s friend. If you want to get a large amount of work done, the best thing you can do is learn how to utilize the queue system effectively.
A queue system is a valuable tool for users. A pile of jobs can be submitted on Friday night to be run when resources become available. Before the invention of queue systems, supercomputer users would frequently find themselves having to log in at 2:00 a.m. on a Sunday morning because that was when the resources were available. The queue system also guarantees that the users job will get the number of CPUs and amount of memory that they requested when the job was submitted.
Programs run interactively (without using the queue system) on the login nodes are limited to 10 minutes of CPU time. After 10 minutes, interactive jobs are automatically killed. Any job larger than this, or using more than 2 cores, must be run through the queue system.
The queue system at the Alabama Supercomputer Center is a Torque queue system with a Moab scheduler. This is often referred to as a Torque/Moab queue system in order to minimize confusion with other types of Torque installations, such as those with the Torque or Maui schedulers.
The Torque/Moab queue system readily facilitates integrating multiple clusters under one queue system. Thus a job submitted from the dmc.asc.edu login node may actually end up running on the UV compute node. The queue scripts provided for running individual applications have been written to allow the software to run on any node where the specific application can be run. The queue scheduler will run the calculation on the node that gives the best turn around time. Users compiling their own applications must either specify the cluster where the application is compiled, or compile for both clusters and create a run script to select the correct version of the software. Submitting user written software to the queue system is discussed later in this manual.
HPC User Manual - Edition 10.1 Working with the Queue System
Reminder