History for Minutes 29 May 2006

changed:
-
Present: Shane, Andre, Karl, Greg, Travis, Peter, Poul.

An "audio recording":ftp://ftp.bioeng.auckland.ac.nz:/cmiss/opencmiss/cmiss-meeting-290506.ogg is available.

F90 mpitest

* Chris has been putting together an MPI test code that currently does an
  assembly and he is adding a solver to it.

MPI Test problem proposal

* Peter: One of the goals of the test is to determine whether an
  object-oriented approach can compare speed-wise to more traditional
  approaches.

* The proposed test problem is intended to be simple to implement but still
  contain features similar to a cardiac simulation.

* There was some discussion over what should be used as a solver.

  * The solution time of iterative solvers depends on convergence criteria
    which may differ between solvers but direct LU solvers are not likely to
    be the solvers used in a cardiac simulation.

  * Conjugate-gradient is a simple solver that forms a basis for many solvers
    and is probably available in many pre-existing packages.  If convergence
    criteria differ between solvers then a fixed number of iterations can be
    used for the test.

  * If a solver is used a transient test problem then most of the time is
    likely to be spent in the solver.

  * A explicit time integration method essentially requires a matrix-vector
    multiplication and so contains a small amount of communication and avoids
    the need for an external solver.

  * However, an (at least partially) implicit time integration is likely to be
    used in cardiac simulation.

* This led to the proposal of two (similar) test problems.

  1 A transient heat equation solved by a finite element method with an
     explicit time integration (forward-differencing).

    * A 2D domain makes communication a little more interesting than 1D.

    * A suggested analytic solution is something of the form::

        sin( k x ) exp( \lambda t ) + x^2 - y^2

  2 A static Laplace or Poisson equation with a conjugate gradient solve.

    * The assembly stage would be timed separately from the solve stage.


Test System

* Proposal for using bioeng22, 4-way (2 x dual-core) amd64 Linux for a test
  system.

  * Don't want to wait for our POWER5 cluster.

  * Easier to build popular packages (e.g. PetSC, libmesh) on a popular (well
    tested) operating system.

  * Disadvantage is that many people run things on it.

  * Our new cluster system will run Linux.  When that is running, it would make
    sense to move our existing hpc partitions to Linux also so that
    compute.bioeng is just part of a more homgeneous cluster (binaries for
    smaller nodes will also run on large shared memory system).
    Might need another licence for Totalview.


Scientific Modelling Software

* There are four candidates for pre-existing (parallel) modelling software,
  but libmesh and Sundance look the most appealing on the surface.

  * libmesh

    * Travis liked the look of libmesh from examples and mesh and solver
      structures involved.

      * 4 or 5 graphical outputs.

      * Standard formats for mesh information.

      * Several people have hooked in Livermore AMG solver into Petsc - should
        therefore be possible to hook into libmesh.

    * Shane: before adopting this software for use we should open a dialog
      with the developers.  One question to ask is: what would they think of
      us adding cubic Hermite elements?

  * Sundance

    * High level

    * heavily templated 

  * LifeV

    * Although their is a documentaion, Karl didn't see any examples to get
      started like those in libmesh.

  * FreePOOMA descended from POOMA which was originally (but no longer)
    developed Los Alamos.

    * Has appealing features but can't see any evidence of a diverse community
      of developers.


Two Job Positions

* MPI programmer

  * Travis suggested submitting the job advert to NA Digest.

* cmiss.org development

  * Need a replacement for Carey.


Meeting finished 12:00.