This page contains a brief description of the muon system event model.


Introduction

Before entering into details of the muon event model let’us remind briefly the hardware structure of the muon system The muon system is composed of 5 stations of four regions each. Each station is formed by 296 chambers (1380 in the whole system), the chambers in the first station are made of 2 gas gaps while the rest of the system is build by 4 gas gaps chambers. Each gas gap is a sensitive volume so in total there are about 5000 sensitive volumes. Each chamber is segmented in strips or pads; each of them is connected to a front-end channel named physical channel. The trigger and DAQ receive appropriate OR of the physical channels which is named logical channel. The number and scheme of physical channels OR's is different for each region. For a reference of the muon system simulation see the notes 2004-063 and 2003-057.

The simulation uses objects of the class MCMuonHit as input, while the output are objects of MuonDigit and MCMuonDigit classes. The MuonDigit are then converted to RawBuffer. The reconstruction follows the path RawBuffer -> MuonDigit ->MuonCoord->MuonID The connection between the reconstructed data and the MC truth is obtained by the associator MuonCoord->MCParticle. At the Boole output only objects of type MCMuonHit, MCMuonDigit and RawBuffer are stored. The Brunel output is constituted by RawBuffer, MuonCoord and the relation table. At DaVinci output the MuonID objects are added to the Brunel output.

MCMuonHit: it is derived from the MCHit base class. Two sensitive volume identification numbers are added: chamber number (0-1379) gas gap number (0-3). They are packed together in one integer. Such information is stored during the Geant4 tracking where it is available for free. During the digitization, this information is very useful to speed up the code since the identification of the sensitive volume to which the hit belongs is time consuming (5k sensitive volumes exist in the muon system). Hits of four different natures are used in the muon system digitization: "Geant", "chamber noise", "low energy background", "flat spillover". Only hits of Geant nature are permanently stored, the others are created in Boole and not saved on DST. For each type of hit there are 20 TES containers one for each region. The requirement to keep separate hits from different regions is due to save cpu time during the digitization when various loops on hits are needed to collect the ones belonging to the same physical channel. There is a request to compact the 20 containers in only one using a structure similar to the one proposed by Needham for the TSA.

MuonDigit: there is a MuonDigit object for each fired logical channel. The addressing of the channels is obtained by the MuonTileID class used as the key of the digits container. For each digit an integer is stored. It contains the TDC data for the channel (4 bits). All the digits are stored in one container in the TES.

MCMuonDigit: it is the link between real world and MC. There is no one-to-one correspondence between MuonDigit and MCMuonDigit. The MCMuonDigit objects consist in a larger sample. A MCMuonDigit is created even if the MuonDigit is absent to trace back mainly inefficiency and deadtime. The MCMuonDigit contains the list of all MCMuonHits of Geant nature belonging to that channel. The links are kept as a vector of SmartRef. For each hits a integer word is stored to study the hit history i.e. dead or alive, killed by inefficiency or by deadtime and so on. Since not all hits are linked to the MCMuonDigit, like for instance background or chamber noise hits, to fully understand the digit fate an integer word is stored. It contains questions to answers like "Is such digit be produced by Xtalk? Or background ? Or noise? In which BX the particle firing it is originated?" , and so on. Both the hit word information and the digit summary information are kept in simple class named MCMuonHitHistory and MCMuonDigitInfo, with just one unsigned integer using bit packing. Both classes are defined in XML.

MuonCoord: crossing vertical and horizontal logical channels (MuonDigit) the pads (MuonCoord) are identified. MuonCoord is the base class used in the reconstruction. It contains mainly the information of the digits used to get the pad. The key of the object is the MuonTileID which serves as the address of the pad. The coords are stored in 5 different containers one for each station. Similarly to the comment for the MuonHit it is possible to compact the five containers into one, if required.

MuonID: it is the result of the offline muon identification algorithm. There is an object for each long track. It contains the track probability of being a muon and the list of pads used in the identification algorithm. Note that multiple pads per station are allowed if inside the matching window. The probability stored in the object is the output of the simple ID procedure. Further refinements of the ID exist (see L. de Paula presentation of 07/july for details) but their outputs are not stored in the MuonID class. They are contained in separate tools and the relative output is not stored.

Relations: a Relation1D between MuonCoords and MCParticle exists. It is based on the MuonCoords2MCParticle algorithm. There is no weight associated to a relation. Multiple MCpartcile can be associated to a MuonCoord. The association is allowed only to MCParticles belonging to the current event. Please note that many MCParticles can be associated to the coords. Our idea is that such relation should be replaced by a relation between MCParticles and Digits. In the present implementation many ambiguous associations are defined. For instance when a pad is obtained crossing two strips, one due to real particle and the other to Xtalk, the association returns a real particle so the Xtalk information is definitely lost. Since the digits can be recreated from the raw buffer such change does not imply a change from coords to digit in the DST content. It is not obvious how many changes in monitor algorithms and user code would be implied by such change.

-- Main.cesaria - 01 Aug 2005

Edit | Attach | Watch | Print version | History: r3 < r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r3 - 2006-11-17 - unknown
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LHCb All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback