The GAUSS executables are not multithreaded or parallel. The advantage of using GAUSS on Biowulf would be to run many GAUSS jobs simultaneously, i.e. a 'swarm' of single-threaded jobs.

There are 2 versions of GAUSS available, as shown in the table below. There are a limited number of licenses for GAUSS 10, so you will need to use GAUSS 3.2 to run swarm jobs.

There are several threading programs that can be used to multithread (i.e. run on multiple processors) specific parts of your programs. These are described here . These threading functions can be used to utilize all the processors on an allocated node. It is important to know exactly how many threads you are executing and match this number to the available processors on the node, so that you neither overload the node (very inefficient) or waste processors.

Since there are only 2 GAUSS 10 licenses, multithreaded GAUSS is the only good reason to run GAUSS 10 on Biowulf. For all other uses of GAUSS 10, it is probably simpler to run GAUSS 10 on Helix.

For example, the following sample code from the GAUSS 10 User Guide defines 4 concurrent threads:

ThreadStat n = m'm;    //Thread 1
ThreadBegin;           //Thread 2  
y = x'x;
z = y'y; 
ThreadEnd;
ThreadBegin;          //Thread 3
q = r'r; 
r = q'q;
ThreadEnd; 
ThreadStat p = o'o;   //Thread 4

Write a batch script along the following lines:

#!/bin/bash
# ---- this file is called myjobscript -------

module load gauss/10
cd mydir
tgauss multi.inp

This program can be submitted to a node with 4 processors (the dual-core, or 'dc' nodes) with the command:

qsub -l nodes=1:dc myjobscript

Create a batch input file, e.g. /home/username/gaussrun. Example:

#!/bin/tcsh
#PBS -N gauss
#PBS -m be
#PBS -k oe
#

module load gauss/3.2
cd mydir
gauss -v -b gauss.in > gauss.out

qsub -v np=1 -l nodes=1 gaussrun

Note that there is no need to ask for more than 1 node, since GAUSS 3.2 is single-threaded. This job will use only one processor on the node, and leave the remaining processor(s) unused. This is discouraged except for testing and debugging purposes, since it wastes processors.

The swarm program is designed to submit a group of commands to the Biowulf cluster. Each command is represented by a single line in the swarm command file that you creare, and runs as a separate batch job. See the swarm page for more information.

You should have 'module load gauss/3.2' in your .bashrc or .cshrc file.

Create a swarm command file, say, cmdfile, with each line containing a single gauss run. Example:

cd /home/user/mydir; gauss -v -b gauss1.in > gauss1.out
cd /home/user/mydir; gauss -v -b gauss2.in > gauss2.out
cd /home/user/mydir; gauss -v -b gauss3.in > gauss3.out
cd /home/user/mydir; gauss -v -b gauss4.in > gauss4.out
cd /home/user/mydir; gauss -v -b gauss5.in > gauss5.out

swarm -f cmdfile

If each Gauss process requires more than 1 GB of memory, use

swarm -g # -f cmdfile

Typing 'gauss' at the Biowulf prompt will bring up the GAUSS Xwindows interface. You can then type any GAUSS command into the window. Since this process will run on the Biowulf head node which is shared by many users, This should only be used for testing, or for small development tasks. All other Gauss jobs should be run via batch, as above.

If you really want to run interactively, you can allocate a node for interactive use. Once the node is allocated, you can type commands directly on the command-line. Example:

biowulf% qsub -I -l nodes=1
qsub: waiting for job 2011.biobos to start
qsub: job 2011.biobos ready

p139$ module load gauss/3.2

p139$ cd mydir

p139$ gauss -v -b gauss.in > gauss.out

p139$ exit
logout

qsub: job 2011.biobos completed
biobos$ 

qsub -V -I -l nodes=1

and your Xwindows graphics should be tunnelled through the ssh connection. See the Helix Xwindows page for more information about ssh and Xwindows.

• GAUSS has online help. Typing 'gauss' at the Biowulf prompt will bring up the GAUSS Xwindows interface. Click on the Help button to view the GAUSS help.
• A Short Introduction to GAUSS. PDF, 1997.