ATLAS muon software

David Adams
11apr02 1600 EDT

Introduction

ATLAS has decided to move away from the "RD event" and old identifier scheme and the muon group is using this as an opportunity to restructure its software. This document is a proposal for how the software might be structured. This is the third pass and comments are strongly encouraged.

Component structure

The following diagram shows the component structure of the system. It shows classes that would be shared by different fitting and algorithms. It is worthwhile to not that many of these could be common with any tracking detector, specifically the ATLAS inner detectors.

(sdr, pdf, jpg)

Each box represents one or more packages and the arrows show the physical dependencies. Each of the boxes is discussed below.

Package structure

The next figure shows how the above (and other) components could be organized into packages. Again the directed lines indicate physical dependencies.

(sdr, pdf, jpg)

Description of components

Generic Identifier

This package contains the generic Identifier class which is used to identify elements of the ATLAS detector as described in ATLAS note ATL-SOFT-2001-004.

Detector Description

The detector description specifies exactly which elements are present in the ATLAS detector and how they are related. For example, it might specify the number and types of MDT chambers, the number of planes in each chamber and the number of tubes in each plane. The detector description uses generic identifiers to label the different elements.

The detector description also includes detector geometry which allows users to determine the size, position and orientation of the detector elements. These could be either ideal or aligned values. It also provides a description of the material associated with detector elements.

It is an important requirement that we be able to use generic identifiers to retrieve these physical properties.

XIdentifier

These muon-specific identifiers provide a convenient interface to the description of the muon system. Each muon identifier corresponds to a particular generic identifier object. For details, see the documentation for the MuonIdentifiers package.

XDigit

A digit (or digitization) is the readout from a low-level detector element such as a wire or tube. A digit hold some readout data, e.g. a TDC count, and the identifier for element which was read out. For a description of muon digit container, see the documentation for the MuonDigitContainer package.

RecoHit

RecoHit defines a common interface for hits that provide the measurements used to fit tracks. Ideally this definition would be common to the central tracker and muon groups so that tracks could be fitted with hits from both systems.

(The dependency with XRecoHit could be inverted by providing an interpreter for each type of hit instead of forcing each hit to satisfy the AbsHit interface.)

XRecoHit

The muon system will likely define different hits for each detector type. Each hit is associated with a single digit and uses the detector location to construct a measurement from the digit. These might be combined to make more complex hits representing segments or space points.

Surface

This is the abstract interface for a 5D surface in 6D track parameter space.

XSurface

We will need to implement concrete surfaces at least for a plane and for the DCA (distance of closest approach).

TrackFit

This is the description of a track at one point along its trajectory. It might be a surface, five parameters and the associated error matrix.

Propagator

This is an abstract interface. A propagator propagates a track fit to a new surface.

XPropagator

This is the concrete realization of a Propagator. It may depend on detector geometry so that it can account for material. There might be multiple versions with different trade-offs between speed and precision.

TrackState

A track state describes a point along a track trajectory. It includes the signed path distance, a track fit, the chi-square for that fit, and a flag indicating the nature of the fit.

TrackSegment

This is describes a track over some finite range of its trajectory. It is able to return a TrackFit for any surface intersected by the segment. It is made up a collection of TrackStates.

Fitter

This is an abstract interface. A Fitter is used to build track segments from hits.

XFitter

Concrete realization of Fitter. There will likely be multiple versions using different fitting algorithms or trade-offs between speed and precision.

Finder

These assign hits to track segments. They will generally need a track fitter to distinguish real and fake tracks.

XFinder

Concrete realization of Finder. Again there will be multiple version to trade off speed and performance and so one can be compared against the other.