The following issues came out during the discussion. They complement the slides that were shown by Dietrich. They have been produced from my notes and those of Niko Neufeld.

• Use Case (John): Roger asked whether the approach taken was specifically geared to the particular algorithm described (and used in the FORTRAN version). It was agreed that the structure of the design should be flexible to accommodate other types of algorithms. Pere suggested that another family of use cases i.e. different algorithms should be studied to test the design.

• Algorithms (Niko): Is the framework biased against the "global-likelihood" algorithm used in the TP? What about for example "ring-scanning-type" algorithms? It is true that the OO analysis of the problem domain (i.e. rich reconstruction) has been somewhat track oriented, but it is intended to provide all functionality to implement any algorithm based on track momentum, track lengths and photon detector hits. The ring scan use case has not been considered - it would probably require some new things

• Connection to MC truth (John): Marco asked if there is a need for objects to know about MC truth e.g. to preserve association between pixel and true track. Answer was yes. An associator is called to establish connection with the track in the datastore. Markus suggested that there should be seperate Monitors for real data and for simulated data. Dietrich agreed to this.

• Geometry (John): At present geometry and algorithm are in the same object. Geometry could be delegated to another object. The GAUDI approach is to keep the detector description seperate, to inherit from DetElem and specialise. Niko pointed out that the choice on the approach is a compromise between modularity and efficiency.

• Naming (John): Pere suggested tochange the name of the Pixel object to HitPixel. Dietrich agreed.

• RICH Track (John): represents how the RICH "thinks" about a track. It organises information in a convenient form. Roger was surprised that the Track object is asked to reconstruct a photon with a given pixel. This doesn't sound correct. Dietrich agreed that the Track object could become to complex, compromising modularity. This approach had been taken for convenience. It probably needs to be rethought.

• Communication between sub-algorithms (John): Approach taken has been to pass context between sub-algorithms via message e.g. Evaluate (my_event, my_detector). If this approach is correct could be generalised as a design pattern used by all sub-detectors. However the natural approach adopted in GAUDI would be to pass information using the transient event store. NB that using transient store doesnt imply object has to become persistent! The advantage of this approach is that sub-algorithms are not closely coupled and can be run independently of one another. This could be interesting, for example for studying different types of algorithms.

• GAUDI integration (Niko): The package as it is now (r1v1) still reflects much of the former standalone program It doesn’t use the event store, which is why it tightly couples the sub-algorithms. This will be changed in a future release.

• Simulation (Niko): Why are there some simulation routines in the reconstruction code? Shouldn't this be separated? Simulation of photons is needed (e.g. for calculation of efficiencies).

• Next steps (John): Roger said that the priority should be to reproduce the existing algorithm before studying new algorithms. For Pere a priority would be to connect to the detector description component in GAUDI. It was mentioned that we should start to think about getting experience with GEANT4 soon in view of preparing the TDR at end 2001. LHCb and BaBar are experiments that have RICH detectors and are planning to use GEANT4.

• Priorities for next release (Niko): There seemed to be a slight disagreement between the RICH group which want's a more realistic photon detector implementation, to catch up with the existing Fortran program, and the computing group which would probably like to have more Gaudi integration and especially an XML description of the RICHes