Notes
from DNA developers meeting held at the ESRF,
Present:
· Steve Kinder (SK)
· Dave Love (DL)
· Olof Svensson (OS)
· Darren Spruce (DS)
· Graeme Winter (GW)
· Takashi Tomizaki (TT) came as an observer.
Agenda:
Test the latest server and expert with ProDC on ID14 EH2 with real crystals and review the results.
Notes:
As discussed at the last full meeting the intention was to have a value for the mosaicity reported back along with a suggested strategy. GW made available just before the meeting version 1.00.20 of the MOSFLM server which includes single image integration. OS and DS prepared the expert, server and data collection code to run on the beamline. This involved arranging a convenient way of shutting down and restarting the server. ProDC is now programmed to collect both images 90 degrees apart with one request from the expert server (by setting the oscillation overlap to -89 degrees). Testing was carried out on Wednesday using a Mar CCD (165mm) detector (the usual ADSC Q4 was under repair).
Results:
The system was able to successfully provide a strategy when two reasonable diffraction images were obtained. Sean McSweeney was not convinced if the proposed strategies were adapted to the experimental conditions but this is where the expert should be developed to take account of this. It was also noted that the system was not adequately robust for user operation for the following different reasons.
1. The aborting of the MOSFLM server has been implemented but has not been integrated yet into the expert and this currently prevents the user or expert from stopping the processing if it has gone wrong. The following observations were made during the test:-
- the user can see that the images collected were not correct but is unable to intervene while the whole sequence is in progress. A brief attempt was made to send an abort from ProDC to the expert but the expert does not yet propagate this to the server. The current MOSFLM server implementation supports aborting a client task by first obtaining an identity for a particular client and then sending a kill command with the identity reference.
- It is not clear to a user that MOSFLM, the server or the expert have died in the general interface. It was necessary to look at the MOSFLM server or expert system log file to detect these errors.
2. The expert does not take account of erroneous images as there is no decision making yet implemented. The MOSFLM server still tries to process these images which often results in MOSFLM crashing or hanging. Some questions were raised about the response of the expert in different cases;
- what happens if the diffraction images are too weak?
- How can it detect blank images?
More general points were raised:-
- How should the system adapt the theoretical strategy to correspond to the experimental conditions?
- How can the user decide on a different space group and recalculate the strategy?
3. A few bugs were encountered which caused the death of the expert due to unexpected XML being returned from the expert server.
- Strategies with only one line of information. This was fixed on the fly.
- The MOSFLM server returned a phi start containing asterisks.
Discussion
The second day consisted of a detailed discussion of how to deal with the previous day's experiences. The robustness question can be addressed in two ways;
Improving the usability
The system aborts needs to be implemented and more tests using the existing test image data are needed. It was also felt that by mixing the different functionality of the expert with that of the data collection interface was leading to confusion for the user. It was discussed that perhaps the characterize button and messages should be moved to a new expert interface. It was agreed that since SK had already started working on a separate window to handle the new functionality of the expert that this could be further separated to form a new common expert graphical interface
The second step for better behavior would be to start to build some expert knowledge into the expert so that it can avoid trying to ask the MOSFLM server to process invalid data. This would mean trying to set some boundary conditions for the different steps and comparing the results before continuing. Since this implies a much larger focus on effort in the expert system it seemed reasonable to look for self contained tasks to allocate to various members of the developers group. See below for the list of tasks.
TT was asked of his opinion of the system. He was interested in automating the input to MOSFLM in order to create the optimized input parameters. He stated that MOSFLM was not very tolerant of approximate experimental condition parameters and needed these to be correct before it was able to give good results (as compared with other data processing packages).
XML
Finally the XML used was (re-)reviewed. Currently there are two documents describing the XML which are intended to be the points of reference for the implementation of the system. These are not consistent with the current implementation as the feedback of experience gained in the implementation has not been put in the documents. The naming convention was also discussed. It was felt that the naming of some of the tags was not always easy to understand and that their meaning was different depending on which element they appeared in. Also there appears to be some discrepancy between equivalent terms of the MOSFLM-Expert System XML and the expert-data collection XML. It was agreed that OS become the editor of only one common document and would receive information about inconsistencies and updates from the various developers and this would form the new reference to be made available on the web. This would include previously non-existent XML documents such as the characterize_crystal.
Actions
1. DL to investigate/develop an auto-indexing module for the Expert System which will take some input boundary conditions and then indicates if they are met. This will depend on advice from crystallographers and may set some requirements for the expert interface.
2. GW to work through the MOSFLM server, notably making it capable of recognizing empty images, and improve the tag naming.
3. All, comment on the inconsistencies (to OS) in the implemented XML versus the reference one. OS will take all information and form a new common document (first draft by the end of May).
4. SK to prepare the new Expert System interface and pass the source code to DS (to work on integrating it).
5. OS to work on the Expert System specification, first draft by the end of May.