Login in
The Beowulf cluster is separated from the rest of the School's Linux system and you need to log into one of the two entry nodes directly (names will be provided). The system only accepts secure communications, so you have to use SSH rather than Telnet to log in, and SFTP rather than FTP to transfer files to the system. A commonly used suite of programs to do this is PuTTY, which doesn't require Admin privileges to install, possibly explaining its popularity. Only use PuTTY versions downloaded from here - others may contain viruses etc.
You can find a basic desription of how to use PuTTY to login here (Remember to select the SSH radiobutton).
You can find a basic description of how to transfer files using PSFTP here (to change to a location on your PC type eg. lcd c:/Java/src/project/, to change to a directory on the cluster, type eg. cd /home/me/Java/src/project/. You can then use get and put as described. help brings up the command list).
Once you are logged in, you are in the Linux environment. This is very different to Windows. If you are not used to it beware - Linux is much less forgiving than Windows - if you delete anything it is usually gone forever. Through the PuTTY terminal, your interaction is via a typed "command line" - yes it is hideous, but if you use it a lot it slowly moves from being hideous to just being unpleasant. You can find a basic list of the commands here. If you intend to spend any time at all on the system, you could do worse than work through this UNIX tutorial - there will be minor differences, but most of it would be appropriate. Starting out, you may find it easier to make changes to files on Windows, and then SFTP them across. The standard command line text editor, lord help us, is "vi". You start it by typing vi filename. You can find a list of vi commands here. Best of luck...
Communication between nodes
The system will use your username to communicate between nodes on the system. Theoretically this means that the first time two nodes communicate in a program run, it should ask you for a password. This would be quite a pain. Fortunately SSH has a solution. Under SSH you can replace passwords with a key-system. Essentially, each time you log into a node, SSH presents half of a complicated encryption key for you. The node you are logging into will have the other half of the key. If the two halves match, you don't have to type anything, you're just let straight through.
This therefore makes communication between nodes under your username much smoother (infact, it would be hard to work without it). The only problem is that you have to set it up the first time you use it. Essentially this involves generating your half of the key, and then SSHing into each node and agreeing the node you've logged into is the machine you were expecting. The machine is then given the other half of the key to keep for next time. Details are on your sheets. Remember to log out of each machine by typing exit before logging into the next node. You'll be supplied with node names. Don't set up a key with PuTTY in the GIS lab, or anyone on the machine will be able to log in as you! Login in to the entry nodes first using your password, then set up the key within the command line for the other nodes.
Running multiple versions of the same code
You can batch distribute multiple versions of the same program, by running cexec command. Your command could be a single command (try cexec ls), a complex command in double-quotes (eg. cexec "java MyModel"), or a shell script (a .sh file containing multiple commands, one command per line).
Shared space vs. local space
It is much faster to write at read to local space on each node. The best place to write to on each machine is /tmp - this is unique to each machine. If you want to write to a space that is shared between all of the machines, write to your home directory - there is only one of these, but it can be seen by all machines.
Compiling parallel Java
Java programs on our clusters use the mpiJava library to add parallel behaviour (API docs). You will therefore need to add the mpiJava classes to your CLASSPATH. You can find the files at /apps/mpiJava/lib/classes/ As this is Linux, the CLASSPATHs need to be colon separated, not semicolon. You may find it easier to make a little shell script to compile or run the files, like this one: makeit.sh, which you'd put at the root of your source tree and run by typing makeit.sh. You can edit it in Notepad.
Running parallel Java
mpiJava is version of the MPI standard. The MPI standard defines what methods and classes a library should implement in order to communicate across a cluster system. The mpiJava library uses "native" code (ie code running outside the JVM) to communicate with LAM. The LAM program does the actual communicating for programs written to the MPI specifications. Before you can run any code, therefore, you need to start LAM, which you can do by typing lamboot. When you are finished your session, you also need to shut down LAM by typing lamhalt. To run LAM, you need to set up some environment variables. The details, classicly, are in the man pages.
Once you have the LAM up and running, you can run your model across multiple nodes using the prunjava numberOfNodes classname command, eg. pJavarun 10 packagename.Model. The shell script above includes this, though it can complicate things if the class doesn't compile first time.