Minutes 31 January 2006

Meeting held 11am 31 January 2006

Present: Shane, Peter (Peters reviewerer), Greg, Travis, Carey, Andre, Martyn, Karl

Apologies: Poul, Chris

An audio recording of the meeting can be "downloaded":ftp://ftp.bioeng.auckland.ac.nz/cmiss/opencmiss/meeting-31.1.2006.ogg

1 openCMISS modular structure and APIs.

Several people have aksed to know more about the components in the framework.

Peter would like to see more information on how the data structures will be accessed.

Shane says the API provides that.

Peter not clear that algorithms that know about parameters go through the API

Shane explains how your algorithm does have knowledge of the elements through the API.

Example possible modules: computation, graphics, user interface, scripting

Any subset of components can be linked into a single executable.

How are solutions stored? Shane thinks field - results at least.

What about matrices? Data structures should also be handling distributed arrays. The computation can specify to the data module how to distribute/store data.

Greg points out that you might want to store things different in different parts of your code, ie not have the machine architecture determine it for the whole problem - Shane says the API should provide for that.

Karl points out that we want to be providing a collection of building block like modules, not a monolithic do all library for only the problems we solve now.

Martyn asks how diverse could the modules be? Seems like teasing out the common computational code will be difficult.

Travis mentions how different computational problems need to know about other coupled problems. Eg coupled electromechanics - the electrics need to know things from the mechanics.

Travis says we seem to proceeding without thinking about MPI.

Shane: we want to start simple. we want to make it possible to add things such as MPI under the API, we want to get started...

Peter is going to finish off some diagrams and put them on the web to help clarify the picture of the framework.

Greg confirms that fieldml has nothing to do with architecture.

The first API is I need to able to get and set parameters

The second API is how do we evaluate fields eg possibly derivatives eg wrt xi1 - how do we describe these things?

Greg need some kind of mapping? Shane, cmgui creates objects. Also need to describe the wrt parameters in an efficient reusable way.

Cmgui only does 1st derivatives, then computated variable tried to address this.

There could be another little library does the evaluation of derivatives.

2 Data structures.

• Examples

3 Future Meetings.

• Development framework.
  • How are we going to develop code?
  • What documentation systems, bug systems, code management systems do we want to employ?

Shane talks about the plan:

The goal was the end Jan. That has come without an output, what is our plan now?

Peter proposes a meeting on Thursday 10am, to get a big picture view of Pouls FieldML progress and to start allocating tasks.