Minutes 3 April 2006

Present: Shane, Poul, Andre, Karl, Greg

Apologies: Chris

• Basic parallelization philosophy

  Chris has suggested (via email) that we discuss the "basic philosophy of how the computational work will be split up amongst the computational nodes". He is concerned that people are thinking in terms of a general master/slave type approach.

  Shane thought all agreed that we don't want master-slave.

  Greg asks:

  • Do we know enough to rule out master-slave now?

  • If we had a heterogeneous system then might one node (e.g. a large shared

    memory system) perform well as a master?

  Shane points out that we are hoping to be running on super clusters and so master-slave is not going to scale so we need an alternative.

  Chris is suggesting:

  • "Each computational node will get a sub-domain of the complete coupled (multi-physics) computational problem which it will solve just like it would for a serial problem for that sub-domain. Communication is then used to synchronise the boundary points."

  People in Auckland are still not entirely clear on what philosophy Chris is suggesting:

  • Shane understood that Chris was suggesting that assembly and solve would

  happen on each node's (sub)domain, then occasionally (every few time steps perhaps) nodes would adjust for surrounding information. (How would this adjustment happen? Are Dirichlet boundary conditions used for the node's domain?)

  • Karl had thought that Chris was suggesting that assembly would be done on each

  node's domain individually to create a stiffness matrix for that domain and that a global distributed stiffness matrix would be constructed from the nodes' matrices. (Solving would still be distributed to the corresponding nodes but would use a global stiffness matrix rather than many nodal stiffness matrices.) (Karl now doubts his understanding.) If this is the case, Shane is hoping that we don't need the intermediate stiffness matrices.

• Fields

  • Poul:

    • Elements are now a subclass of an ensemble - an ensemble with no children.
    • Done examples with hanging nodes - need to make a few minor changes before posting.
    • Working on cubic Hermite.

  • Serialization/Diagrams:

    Shane wants a serialization.

    Poul says diagram shows dependencies visually.

    Suggestion from Andre to use Inkscape as an SVG editor for diagrams.

  • Nodes:

    Greg still concerned about how nodes are represented.

    Shane says this will be handled through naming and grouping.

  • Serialization.

    Should grouping be flexible so as to facilitate editing fieldml files directly? e.g. group by component or by node.

    Shane would like to be able to edit by hand.

    Poul says this is best done in software.

  • Greg: can we have element "one" and node "one".

    Poul: any object needs a unique name.

    This implies element_one, node_one.

  • Should we have a short hand notation for fielml serializations?

    Poul says can be done later.

    Shane wants it now.

• New job position:

  Peter has forwarded a job description to Maria.

  Does anyone know anyone who could be good for the job?

• www.cmiss.org

  • How are we going fix bugs in email notifications.

    Do we wait for Gareth to develop an understanding or does someone else dive in or can we get Carey to continue looking into it?

    It seems Carey is tied up with cellml priorities.

  • Alternatives?

    Andre: should we use something other than Plone?

    Poul not keen to start afresh after the investment into Plone.

  • Revert?

    Greg: should we revert to a version that works?

    Shane: same version as cellml easier to maintain.

    Poul: the cost in going backwards may be significant?