Minutes 29 May 2006

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.