History for Minutes 28 November 2005

changed:
-
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.