Present: Keith Wilson, Martyn Winn, Alun Ashton, Charles Ballard, Pryank Patel, Peter Briggs

The starting point for this meeting was a review of the minutes of the Developers' Meeting previously held at DL 23^rd May 2002. Points in those minutes were reviewed to identify where progress had been made and where further action could or should be taken:

Point 1) C libraries:

Review of actions

• Libraries were subsequently made available to the York developers via ftp; not clear if they were picked up.
• Eugene’s input is required on some issues wrt MMDB (e.g. replacement of Fortran SFREAD s/r)
• Still to be done: turn crossec functionality (obtaining f/f’ values for any element as function of wavelength) into a library.
• Example application Ecalc++ now done.

Point 3) Fitting into CCP4i:

This was taken to mean "fitting new programs and libraries into CCP4i". There was a great deal of discussion about the proposed changes to the architecture of CCP4(i), as represented by the two diagrams in the minutes from the meeting of 23^rd May.

Two concrete actions arising were:

1. Liz: update CCP4I to support running Python scripts in addition to Tcl scripts currently used, for interaction with Molecular Graphics (MG).
2. Pete: split off the database (db) handler from the main CCP4I code so that it can be accessed by other applications.

It was broadly agreed that the model architecture diagrammed in the minutes of the earlier meeting is a reasonable model for CCP4 to move towards over the next 3 years - it seems sufficiently flexible to support new applications running in Python scripts as well as legacy applications using Tcl scripts.

An annotated version of this diagram is shown in figure 1. Charles commented that this architecture seemed very similar to that used for the MG project.

Keith raised some issues:

• Will developers be convinced/persuaded to adopt the proposed new method of wrapping applications? (LHS block of diagram)
• Is Python sufficiently ubiquitous not to pose a barrier to people using the new architecture?

Martyn suggested prototyping the Python scripting component using his Ecalc++ application, as a starting point for discussion and development. Pryank suggested trying something similar with CLUSTALW (general multiple sequence alignment program), as an example using a non-CCP4 program.

More questions from Keith:

• What is a reasonable time scale to achieve this? – no-one was prepared to set one
• Are these developments reflected in the CCP4 grant renewal? – "only vaguely" (MDW)

Pete raised the question of how automation fits into this scheme. There was some discussion about what the term "automation" meant in this context, which concluded with the definition "running a procedure comprising several tasks with the minimum of user intervention." In spite of further discussion it was not clear precisely how automation would be facilitated by the proposed new architecture.

Timescales are needed for the two CCP4i-based actions from the previous meeting:

1. Separate db handler in CCP4i – Pete said this would be done before the end of the current CLRC reporting year (April 2003).
2. Liz – is there a timescale for enabling Python scripts to run from CCP4i?

Martyn then gave an outline of the current status of the new libraries:

New C components: symmetry; MTZ; map; coordinates (via MMDB); CCP4 "utility functions" (file handling, keyworded input etc). Fortran API provided to mimic functionality of existing library.

Components still in Fortran: html and xml writing, harvesting, FFT, and some "unsupported" libraries (e.g. plot84).

It is planned to replace the existing FFT libs with fftw – CCP4 can purchase a one-off licence for $2500 (correct as of June 01), which allows us to use and distribute. No further action has been taken on this yet. It was noted that Clipper currently requires fftw. There was also a comment that fftw works in P1 and lacks specialised functions for higher symmetries – is this is an issue speed-wise?

The plan is to test on different platforms by building and running the Fortran programs. Charles expressed concern regarding inconsistent error handling between different new library components, and over a possible performance implications (e.g. are the new libs significantly slower than the existing ones?). He would like some rationalisation of the new libs to be done.

Martyn is in the process of preparing two documents:

1. Strategy for the software library (overall scheme, aims, components, target uses, form of library, workplan)
2. Design document (includes more details e.g. error handling)

Charles is to provide feedback on these. Keith requested that versions of the documents be ready in time for the next meeting in York.

The meeting concluded by setting the agenda for the next meeting, at York University Thursday 25^th July 2002.

___________________________________________________________________________________