Minutes of the offline meeting held on 5 January 1999

Present: P.Mato, M.Cattaneo, P.Maley, P.Colrain, F.Harris,   J.Harvey, I.Videau, G.Corti,
            J.Saborido, G.Gracia, J.Closier, A.Jacholkowska, E.van Herwijnen, T.Cass, I.Korolko,
            F.Filthaut, R.Chytracek, M.Alemi, F.Ranjard

Minutes : Florence Ranjard

1. Status of things (F.Ranjard)

1. R.Van Eijk will present the package he has written within the ROOT framework for the Outer Tracker Testbeam on Tuesday 19 January 1999.
2. Joel Closier will present (Tuesday 12 January 1999) a proposal to improve:

• the LHCb data pool $LHCBHOME/data,
• the stage pool,
• the tape data base

3. Marco Cattaneo will present (Tuesday 12 January 1999) a list of recommendations " what to do what to |NOT do" he has learnt during the OO analysis and design course.

2. What have we learnt from the Architecture Review (P.Mato)

           Main points of the discussion were:

persistent / transient data store

• the transient representation of an object is unique: may be not the best suited for all algorithms.
• the transient representation should fit more than one algorithm.
• the transient representation should be as stable as possible.
• isolate the transient representation from the persistent one.

methods / data

• algorithm objects contain data such as cuts or parameters but require data objects from the Event store.
• data objects contain methods to convert one view of the object into another view (xyz-> rphy) but no algorithm.
• hit objects do not know how to combine themselves to make a track.
• hit objects do not know by whom they are required.
• the advantage of such separation is that the algorithm can be modified without changing the objects produced by this algorithm.
• but objects relationships are a problem : since a hit object knows only about itself how can it know its relationship with digits which can be required by some algorithms in some cases.
  • we can use "smart pointers" to get what we need at run time if not frequent cases (i.e. hits and digits).
  • an algorithm can required everything it expects to need (i.e. hits and tracks)

global knowledge

this implies some global knowledge: the compiler and/or the linker cannot recognise all problems:

• the event data store is organized as a file system: the compiler has no knowledge of this structure,
• since algorithm and data are different objects the compiler cannot check the existence of the data needed by the algorithm.

Architecture constraints

• the Architecture must fit different groups and ease code integration, so it implies constaints and limitations
• Some examples should be described thoroughly to help a group to start properly.
• These examples should be part of the documentation.