Running LAM on CS Lab machines

    Here's what to do:

     On some lab machine:

     % ssh-keygen -t dsa
       (accept the defaults, and just hit RETURN when asked for a passphrase)

     % cd ~/.ssh
     % cat id_dsa.pub  >> authorized_keys2    

     now try it out: ssh somemachinename 

    # if you use bash:  add to your .bashrc or .bash_profile file:
    export LAMRSH=ssh

    # if you use another shell (you likely don't) add to your .cshrc  file:
    setenv LAMRSH ssh

1. Boot lam
   To boot lam, you need to have a lamhosts file in your lam subdirectory, and run recon to see if lam can be started on all nodes in your hostfile:

    % recon -v lamhosts   # see the example below for this file's format 
        

   Then, to boot lam on the hosts in your host file (this has to be once at the beginning of each session you run mpi programs):

    % lamboot -v lamhosts 

2. Run MPI applications
   • Compile your application using mpicc for C code, and mpic+= for C++ code (mpif77 is the mpi compiler for Fortran):

      % mpicc -o myprog myprog.c 

   • Create an appfile describing which host will run which executable(s) In some cases you may have more than one executable in your mpi application (see the mandelbrot example below where there are separate master and slave executables). Use mpirun and the appfile to run your MPI application:

      
          % cat appfile
            # 18 a.outs across 6 nodes (will spawn 3 a.outs per node)
            n0-5 /home/newhall/lam/test/a.out 
            n0-5 /home/newhall/lam/test/a.out 
            n0-5 /home/newhall/lam/test/a.out 
          % mpirun -v appfile	 
          

     or use the -np # command line option to mpirun to specify the number of processes to start on the nodes. For more options, see the mpirun man page.

           % mpirun -np 25 /home/newhall/lam/test/a.out
          

   • After each individual run of an MPI application, it is good to run lamclean to clean up any residual state from the last run before starting a new run:

      % lamclean -v 

3. mpitask
   As your MPI application runs, you can look at the state of the tasks by running mpitask. To continuously run this program every X seconds, use watch:

          # every 1 second, run mpitask
          %  watch -n 1  mpitask
         

4. Shutdown lam
   After you are done running your MPI applications, you should shut down lam by running lamhalt, or if lamhalt doesn't completely clean things up, then try lamwipe:

    
        % lamhalt
        % lamwipe -v lamhosts 

An Example MPI application to try

The Assignment

The Game of Life is a simple example of a class of problems that can be modeled using cellular automata; some physical and biological systems that evolve over time can be modeled using cellular automata. The problem space is divided into a number of cells each of which is a finite state machine. Each cell's evolution is computed in steps of time; each cell makes one state change, then each cell makes the next state change, and so on.

In the Game of Life, each cell, represented by an (i,j) element in an MxN matrix, contains an organism that is either dead or alive (represented by a 0 or 1). At each step in the game, a cell's state changes based on its current state and the state of its neighbors. The following are rules for a cell's state transition at each step:

1. A live cell with zero or one live neighbors dies from loneliness.
2. A live cell with four or more live neighbors dies due to overpopulation.
3. A dead cell with two or three live neighbors becomes alive.
4. Otherwise, a cell's state stays unchanged.

Using the lam implementation of MPI, write a message passing version of the game of life that takes three command line arguments: two dimension values (M and N) for the matrix; and K the number of iterations as input. The easiest way to parallize this program is to have one process for each cell in the MxN matrix. You are welcome to try another way of dividing up the matrix if you'd like (either way is fine). No matter how you decide to distribute the matrix, you should choose one process to be the master (0 is a good choice), and the others to be the slaves. The master should participates as a cell in the MxN matrix (or as a set of cells), but is also responsible for sending slaves their original values and receiving the final result from the slaves and printing it to stdout. I'd recommend using the SPMD model for your program, rather than having separate master and slave executables.

You should also have a debug mode where each slave sends the master its value at the end of a round, and the master after receiving values from all slaves, prints out the MxN matrix of round i values. This will help you debug your solution.

When your program is not running in debug mode, slaves should not send the master their intermediate results.

At each step, each cell needs to exchange information with its neighbors. Keep in mind that a cell in the middle has eight neighbors, and a cell in a corner has only three neighbors, and a cell on an edge has five neighbors. Make sure that at each iteration i, each process gets values from each of its neighbors corresponding to their ith state, and that you solution is deadlock free.

Here is some sample output from a run of my program with a 6x4 matrix for two rounds, with debugging turned on (I just use a compile-time flag, #define DEBUG 1, to turn it on/off):

Start:
------
0 0 0 1 
0 0 0 1 
0 1 0 0 
1 1 1 0 
0 1 0 0 
0 1 0 0 

Round 0:
-------
0 0 1 0 
0 0 1 0 
1 1 0 1 
1 0 1 0 
0 0 0 0 
1 0 1 0 

Round 1:
-------
0 1 0 1 
1 0 1 1 
1 0 0 1 
1 0 1 1 
1 0 1 1 
0 1 0 0