Minutes 28 November 2005

Present: Greg, Travis, Karl, Andre, Martyn.

Apologies: Peter, Shane, Carey.

How many meetings are we going to have?

Travis suggested that we have more meetings where they are useful, but was happy with one meeting per week right now. There were no objections.

Criteria for use of external projects

For projects to investigate further for ideas and directions ("examples"):

• What other groups/projects use the project?

Additional criteria for projects we might use directly ("resources"):

• Licences.
• Interoperability. What other projects are excluded by using one project?

Tavis noted that a lot of people have used PETSc in their projects and he has seen an example of people using PETSc in building a modelling project quickly.

John Pearce has used some of the projects on our References page. It would be good to get his input at a technical committee meeting.

Investigation or action first?

Martyn commented that a possible alternative to investigating a large number of external projects was to first embark on our project and then see what resources are required and what issues need to be resolved.

Greg suggested that we first decide how we want to achieve how goal and this would help us select which external projects are of use to us.

Karl thought that we weren't yet well-enough informed to know how to achieve our goal, and that investigating other projects would educate us on how best to achieve our goal.

Discussion proceeded on the issue of where the API would be between the data engine and the algorithms.

It was agreed that it would be nice if the data engine handled the distributed storage of data, and so the api would be independent of the memory model.

Discussion moved toward the concept of a (possibly distributed) data server (database) serving the data to a client directing the algorthm.

Further questions

What role is scripting going to play?

New staff

Travis pointed out that it may take 6 months for a new staff member from another country to leave their current position, move to NZ, and start work here.

It seemed a good idea to advertise for a lead developer as soon as possible.

This position would essentially be for a "scientific programmer". Skills in the following areas would be useful.

• distributed memory data management

• documents well

• The issue of C(++) or Fortran experience was raised.

  The external projects that may be used could be written in Fortran, C or C++.

  People did not see any problem with a programmer having minimal Fortran experience as a C programmer could probably learn Fortran reasonably easily. However, some programmers really dislike Fortran, and it is likely that some components of the project will use or interface with Fortran, so the advertisement should mention at least C and Fortran.