The MIRTH Simulator clusterThe MIRTH Simulator clusterUsing Pentium 4s, except for the interactive dual node and disk node, which have dual Xeons. Nodes have 40 Gb system disks and 512 Mb memory except as stated:
Why single-CPU nodes instead of duals? Benchmarking indicated that they give better performance/$. In dual Xeon systems the CPUs compete for memory bandwidth, so that the speedup with using both is typically much lower than a factor of 2, often as low as 1.5 (i.e., only 50% more speed than a single CPU). This, combined with Xeons being expensive relative to Pentium4s of the same GHz, leads to a better performance/$ for the single-CPU systems. Also, the single-CPU option has one network channel per CPU, rather than one shared between two CPUs.
The ROCKS Cluster Distribution, "An Open Source Linux Cluster Solution", version 3.2.0 (Shasta). This is based on Red Hat, and has all the important things included: MPI, cluster monitoring software, etc
Optional packages (rolls) installed:
Some other non-rocks packages have also been installed, notably the 3-D visualization package OpenDX. Click here for information on using DX.Also GMT, xmgrace and xv.
Log in using ssh. Use "ssh -X", as then X-windows will automatically be sent to the machine in front of you without fiddling around with "setenv DISPLAY ..." and so on. They will also tunnel through any firewalls, NAT routers etc., all the way through to your home high-speed wireless network if you have one.
Monitor the cluster using mozilla, a web browser that will fire up displaying an information page with useful links:
Run batch jobs using PBS/Maui. See separate instructions. The main difference to the setup on komp is to use mpiexec in your scripts instead of mpirun. It is not necessary to specify the number of nodes- it gets this information from the queueing system. This only works for GNU-compiled jobs though. Stay tuned for information on using Intel compilers.
Running interactive jobs (for development, debugging etc.). Scalar jobs can be run on c0-0 to c0-2 (log in using ssh), and for debugging purposes you could run small parallel jobs on these nodes, giving mpirun a machinefile telling it what nodes to run on. For parallel jobs you can get an interactive partition on the batch nodes by using "qsub -I ..." but you may have to wait a long time for it.
Write output to the scratch disk /f or to the RAID disks. /f appears as /home/f on the nodes. Information on RAIDs will be added when available.
Getting your files on and off. Use sftp and scp (regular ftp and rcp are not secure so are disabled).