Minutes of the Computing meeting held on 11 September 2000

Present: M.Cattaneo, K.Harrison, R.Hierck, J.Closier, P.Mato, O.Callot, B.Hay, G.Gracia, G.Corti, I.Korolko, A.Jacholkowska (plus apologies to anyone I have forgotten!)

Minutes : Florence Ranjard

   1. Status of Brunel verification

• DST1 output has been verified by data quality checking tool and is found to be identical with SICB
• DST2 output has been similarly checked, and is consistent with SICB within the limited statistics. It was suggested to switch off the RICH extended tracking in order to produce larger test samples without job crashes.
• Ivan is making detailed checks of the calirimeter output. About 30% done, and OK.
• Eric is getting ready to do a test production run with Brunel on PCSF
• Marco will present the status of Brunel in Milano. Any contributions should be sent to him by Friday this week, as he will not be at CERN the week prior to Milano.

     2. Design and example implementation of Gaudi associator tools (G.Corti)

• Gloria presented some slides (.ppt, .pdf) showing the design and implementation of associator tools, with a working example to associate CaloDigit to MCCaloSummed Deposit. Associators will be available in the next release of Gaudi.
• There was a long (re)discussion of what can or should be stored on permanent storage to facilitate the association. There is general agreement that the only link between real data classes and MC classes to appear explicitly in the data model should be at the level of the digitisings, where the MCDigit classes inherit from the real data Digit base classes. There was much discussion as to whether classes further downstream in the reconstruction should be allowed to contain smart pointers to allow direct navigation to MonteCarlo classes, bypassing the MCDigits. In the end (after continuing the discussion over coffee...) it was agreed that smart references are NOT necessary, but that it should be permitted to save to permanent storage the AssociationTables created by Associators if this optimises the analysis.
• There was also some discussion on the design details
  • How can one tell the difference between an association that fails because the there is no mechanism to associate two given classes, and one that fails simply because there are no objects to be associated to a given instance of a class.
  • Is it reasonable to have different interfaces for one-to-one and one-to-many relationships? Isn't one-to-one just a special case of one-to-many?
  • When storing an AssociationTable, how can the configuration of the Associator be saved with it? (This is the same problem that exists when saving data created by an algorithm).
• Conclusion:
  • The only explicit links between reconstructed data and MonteCarlo truth occur in the data model at the level of the digitizings, using the inheritance mechanism
  • It is forbidden to use smart references to MC objects in any of the reconstruction classes downstream of the digitizings.
  • Associators must be used whenever navigating between reconstructed or raw data and MC truth.
  • Associators may save their AssociationTables to persistent storage to optimise subsequent analyses.

    3. Brunel convention proposals

• The only controversial point from Marco's original proposal concerned the presence of pointers to MC truth in places other than the digitization classes. Following the discussion at the previous point, and the existing proof of concept for Associators, it was agreed that Marco could go ahead and present his proposals for approval in Milano.

     4. Implementration of spillover in Gaudi/Brunel

• Marco presented (.ppt, .pdf) a proposal for implementing spillover events in Gaudi. The mechanics for reading in additional events are very easy to implement and could be part of the next Gaudi release. The real work has to be done inside the sub-detector digitisation code, which would have to be significantly modified to handle the out of time events. It was generally agreed that it does not make much sense to modify the SICB digitisation code, and that handling of spillover should be built into the C++ digitisation code from the beginning. Since the most urgent physics requirement for spillover studies comes from the tracking optimisation, it was suggested that the first client for spillover in Gaudi would be the tracking group.

===============================================================

next meeting :  17 September 2000 at 14:00