Some things to know for Project 2.

- Error checking is important: I should not be able to make your
  program crash.

- The debugger is your friend.  ddd is a decent graphical debugger
  available for freebsd.  Take advantage of it!  When debugging, be
  sure to compile with -g, and with no optimization flags.

- Be sure it works on one processor.  This may require some special
  cases (or may not, depending on how you approach the problem)

- Debug mode should produce information such as this at each iteration:

Iteration 6... start at time 5.0878
Proc 0 Counters- living: 258242, died: 113297, born: 202621
Proc 1 Counters- living: 258242, died: 113297, born: 202621
Global Counters- living: 516484, died: 226594, born: 405242

- Non-debug mode should not produce any output in the part of the code
  which you will be timing.  Also avoid unnecessary communication when
  doing timings.

- Once your program is working, compile with optimization turned on
  (-O2 is good, but for mine -O3 REALLY sped things up) and of course
  make sure you're getting the same answers.

- Try to run your timing tests at Williams when no one else is using
  the machines.  This will make your timings more accurate and you
  will not upset anyone who is trying to use the machines.  It's
  always a good idea to run these kinds of things several times,
  throwing out the fastest and slowest times and taking an average to
  get more accurate timings.

  To run on 8 lab systems:

  mpirun -np 8 -machinefile ~terescoj/shared/cs338/tcl312 ./cell ARGS

  The file tcl312 is a list of machines in the lab for mpirun to
  choose from.

- My implementation requires that the grid size N (for an NxNxN
  simulation) is a multiple of the number of processes.  If you have
  this same restriction, be sure to choose your problem sizes
  appropriately for the timing tests.

About NCSA:

- Forward your NCSA mail somewhere that you will read it.  Put a
  .forward file in your home directory there with your preferred
  e-mail address in it.

- We can only run small jobs on modi4 (the login node) at NCSA.  It's
  also an interactive node, so there may be more processes trying to
  run than processors.  This is usually fine, but not for timings.  We
  will want to run our timing runs in the batch queues.  See
  ~terescoj/proj2/cell.b for a sample batch script.  Submit it with
  bsub < cell.b after copying it into your directory and modifying it
  for your own simulator.  See the NCSA web documentation for more
  details about submitting jobs.