Present: M.Cattaneo, A.Tsaregorodtsev, E. van Herwijnen, J.Harvey, P.Maley, P.Colrain, F.Ranjard, P.Binko, N. Zaitsev, P. Mato, A. Jacholkowska, G.Gracia, Radovan Chytracek

Minutes: G. Gracia

Agenda:

  1. News
  2. Pile-up detector Use Cases (N.Zaitsev)
  3. Architecture group status report (P.Mato)
  4. MC data checking procedure (A.Jacholkowska)

1. News
A new doctoral student, Radovan Chytracek, was introduced. He will start working in the detector description for the new OO simulation program.

2.Pile-up detector Use Cases (Nikolai Zaitsev)
Nikolai presented his ideas (slides ps) on the class structure for the OO implementation of the pile-up trigger. The proposed implementation aims to be used for the vertex detector test-beam data analysis and also in the LHCb future simulation program. Models for the detector description and the algorithm were presented. Nikolai made his design using Rational Rose, the class diagram can be seen in his slides)

From a general detector description there will be two inherited detectors for test-beam and (the substitute of) SICB. The detector class will have detector modules, the hits produced are the input for the coincidence matrix.

The algorithm is steered by the PileUp object which includes the PUCoinMatrix (Pile up coincidence matrix). The input for the PUCoinMatrix are the hits and the output are histograms stored in PUHistAccumulator. The PeakFinder looks for peaks in the accumulated histograms to make the trigger decision. Nikolai proposed the BeamMonitor and the LuminosityMonitor will be inherited algorithms of the PileUp. The present global architecture does not foreseen inherited algorithms, Pere and Pavel said a different structure would be preferred, nested algorithms instead of inherited algorithms.

Finally Nikolai commented that part of the algorithms are common to the L0 Trigger, Luminosity and Beam monitor. The first of these algorithms called will produce the histograms which will be used later by the others without reprocessing and independently of the order in which they are called.

3.Architecture group status report (P.Mato)

Pere reported the progress made in the last two weeks in the architecture design (slides pdf). The overall design is fixed and the efforts are now to document the design, check it and study some practical problems as the organization of the packages. John Harvey presented a book by John Lakos about how to face those practical issues in the design (slides ppt). A note describing the present design must be ready for November 20th. In november 26 there will be an architecture review meeting with some experts from outside LHCb. We expect to get some feedback on the work already done from the experts. An internal evaluation of the architecture using some selected "use cases" will be done before (next week). Some code was already written.

4.MC data checking procedure (A.Jacholkowska)

We plan to increase the existing statistics in the different physics channels by a large factor. The priorities in the production will be defined by the physics group.
To monitor this massive production Agnieszka is preparing two set of histograms. The first set of histograms will be produced for every run to monitor some basic quantities, for instance the number of generated and reconstructed tracks. A second set of histograms will include more specific detector information provided by detector experts. The checking procedure must still be defined. The histograms might be compared with a set of reference histograms with some sort of automatic tool, but checking them "by eye" sometimes will be unavoidable.
Histogram numbering convention was agreed and some code was already provided by the detector experts, but the contact person for few subdetectors are still missing. Detector specific histograms will be activated by the IOPA and HIST cards for each subdetector.
The MC data base is also being updated by Andrei. It will include some extra information: The person who required the production of the particular channel, fraction of events produced and some others. The proposal was that the status and progress of the production will be written in a web page which will be updated daily.
A document describing all the MC production related topics is being prepared. It will describe the monitoring histograms and also how to run the production, access to the data base and so on. Any suggestion about the production, the information the data base should include or how to access it will be welcome.