# Presentation: 659140

## Muon Software Structure

- David Adams
- BNL
- April 17, 2002

- ATLAS Muon Software Meeting

## Contents

- Component structure
- Detector description
- Digits
- Surfaces
- Hits
- Tracks
- Propagators
- Fitters
- Finders

- Package structure
- ATLAS package
- Muon packages
- Tracking packages
- Inner detector
- Plan of action

- Event Data History           David Adams   BNL

- December 2001

## Component structure

- Figure
- The figure on the following page shows some of the major components that could be shared by the various fitter and finders
- Physical dependencies are shown
- A box may correspond to multiple components (classes)
- The following text describes each of the components

- Event Data History           David Adams   BNL

- December 2001

## Component structure (cont)

- Event Data History           David Adams   BNL

- December 2001

## Detector description

- Generic identifier
- Readout identifiers described in ATLAS note ATL-SOFT-2001-004
- e.g. /7/BOL/1/2/MDT/1.
- ATLAS software that describes the detector
- Includes means to obtain physical properties corresponding to objects specified by readout and other identifiers

- Event Data History           David Adams   BNL

- December 2001

## Detector Description (cont)

- XIdentifier
- Layer over generic identifiers for selected muon components (tube, chamber, ...).
- Carry structure:
- Tube knows its chamber
- Can discover the tubes in a chamber
- Uses detector description to define structure
- Should we add dead material?

- Event Data History           David Adams   BNL

- December 2001

## Digits

- XDigit
- X = Mdt, Csc, Rpc and Tgc
- A digit is the event data for one detector element
- Identifier for the element
- Datum (e.g. TDC count)
- Digit container holds the collection of these for one subdetector in one event

- Event Data History           David Adams   BNL

- December 2001

## Surfaces

- Surface
- Base class to describe a 5D surface in 6D track parameter space
- Often correspond to a 2D surface in 3D space
- Gives meaning to the 5 track parameters
- XSurface
- Concrete surface classes: X =
- Cylinder
- Plane
- Dca (distance of closest approach)

- Event Data History           David Adams   BNL

- December 2001

## Hits

- RecoHit
- Generic interface for fitting
- Define a measurement and error
- Predict these from a track fit
- XRecoHit
- Concrete implementation of RecoHit interface
- X = Mdt, Csc, Rpc, Tgc
- Corresponds to one or more digits

- Event Data History           David Adams   BNL

- December 2001

## Tracks

- TrackFit
- Specifies one point along a track
- Includes
- surface
- 5 track parameters
- error matrix

- Event Data History           David Adams   BNL

- December 2001

## Tracks (cont)

- TrackState
- Adds data to a TrackFit:
- Path distance s
- Flag indicating fit quality (from INVALID to OPTIMAL)
- Chi-square for the fit
- RecoHit
- Should add miss (active detector crossed without adding a hit)
- May add kink (e.g. for brem)

- Event Data History           David Adams   BNL

- December 2001

## Tracks (cont)

- TrackSegment
- Describes a track over a finite path length
- Collection of TrackState objects ordered by s
- Is able to return the TrackFit at any surface intercepted by the track
- This will generally require a propagator
- Quality of these track parameters depends on the completeness and quality of track fits
- This is the transient representation of the persistent track class (output of tracking)

- Event Data History           David Adams   BNL

- December 2001

## Propagators

- Propagator
- Abstract interface for an algorithmic class that propagates a TrackFit to a new surface
- In general this will have to handle:
-  coordinate transformations,
- magnetic field and
- material interactions

- Event Data History           David Adams   BNL

- December 2001

## Propagators (cont)

- PropStat
- Status returned after propagation to indicate
- failure or success and
- distance of propagation (s)
- XPropagator
- Concrete implementation of Propagator
- May be many implementations
- Material description
- Tradeoff between speed and precision
- Different surface types

- Event Data History           David Adams   BNL

- December 2001

## Fitters

- Fitter
- Abstract interface for fitting a track
- Input is a TrackSegment and output is the same with updated track fits
- Might want to store this instead of track fits in a persistent track
- XFitter
- Concrete implementation
- Expect at least one Kalman implementation
- Also non-Kalman?

- Event Data History           David Adams   BNL

- December 2001

## Finders

- Finder
- Abstract interface for track finding
- Input is collections of hits (class RecoHit)
- Might also input collections of existing tracks (class TrackSegment)
- Output is a collection of found tracks (class TrackSegment)
- Muon finding Athena algorithm reads data (from StoreGate), runs one or more finders and then writes data.

- Event Data History           David Adams   BNL

- December 2001

## Finders (cont)

- XFinder
- Concrete implementation of Finder
- Expect many of these corresponding to present and future algorithms

- Event Data History           David Adams   BNL

- December 2001

## Package organization

- Figure
- The figure on the following page shows how the preceding components can be organized into packages
- In ATLAS a package corresponds to a CVS module
- The figure distinguishes between packages that are specific to the muon detectors and those that might be shared with other tracking detectors
- The muon and tracking packages and are discussed in the following pages

- Event Data History           David Adams   BNL

- December 2001

## Package organization (cont)

- Event Data History           David Adams   BNL

- December 2001

## Muon-specific packages

- MuonIdentifiers
- This package is in CVS
- Only MDT is implemented
- Awaiting the implementation of the “new” readout identifier scheme to provide a source for the structure of the identifiers
- See _[http://www.usatlas.bnl.gov/~dladams/muid](http://www.usatlas.bnl.gov/~dladams/muid)_

- Event Data History           David Adams   BNL

- December 2001

## Muon-specific packages (cont)

- MuonDigitContainer
- This package is in CVS
- Only MDT is implemented
- MDT digit is a placeholder
- We may want a separate package for these
- See _[http://www.usatlas.bnl.gov/~dladams/mudigi](http://www.usatlas.bnl.gov/~dladams/mudigi)_

- Event Data History           David Adams   BNL

- December 2001

## Muon-specific packages (cont)

- MuonRecoHit
- This package does not exist
- Will include at least one RecoHit subclass for each of the four muon subdetectors

- Event Data History           David Adams   BNL

- December 2001

## Tracking classes

- MuonPtr
- Smart pointer classes to help with memory management
- There is a simple implementation of this package
- It is not in CVS
- At present only ClonePtr is provided
- See _[http://www.usatlas.bnl.gov/~dladams/musys/pkgs/MuonPtr](http://www.usatlas.bnl.gov/~dladams/musys/pkgs/MuonPtr)_

- Event Data History           David Adams   BNL

- December 2001

## Tracking classes (cont)

- MuonLinearAlgebra
- Simple interface for linear algebra (vector, matrix and symmetric matrix) classes
- There is a simple implementation of this package (no manipulations)
- It is not in CVS
- We need to choose at least one implementation to put behind this façade
- See _[http://www.usatlas.bnl.gov/~dladams/musys/pkgs/MuonLinearAlgebra](http://www.usatlas.bnl.gov/~dladams/musys/pkgs/MuonLinearAlgebra)_

- Event Data History           David Adams   BNL

- December 2001

## Tracking classes (cont)

- MuonBase
- Holds the track and abstract classes shown in the component structure diagram
- There is a simple implementation of this package
- It is not yet in CVS
- See _[http://www.usatlas.bnl.gov/~dladams/musys/pkgs/MuonBase](http://www.usatlas.bnl.gov/~dladams/musys/pkgs/MuonBase)_
- We need a policy for managing surface references

- Event Data History           David Adams   BNL

- December 2001

## Tracking classes (cont)

- MuonSurface
- There is no implementation of this
- It will implement the required surface classes
- Are plane and DCA sufficient?
- Propagator1, Propagator2
- Fitting requires good precision and accuracy while finding requires speed
- Likely will need multiple versions to satisfy these conflicting requirements

- Event Data History           David Adams   BNL

- December 2001

## Tracking classes (cont)

- Fitter1, Fitter2, Finder1, Finder2
- We already have multiple fitting and finding algorithms
- Wrapping these in common interfaces will allow us to share some of the effort required to integrate into Athena/StoreGate
- Also facilitates mix and match, e.g.:
- find with one algorithm and fit with another or
- Use different approaches in different detector regions

- Event Data History           David Adams   BNL

- December 2001

## Inner detector

- Sharing
- The requirements leading to the muon tracking packages are shared with the inner detector
- Muon and inner detector can benefit from sharing the development effort
- A common output track class would facilitate the exchange of data between these groups and to other groups
- We should strive to find common solutions

- Event Data History           David Adams   BNL

- December 2001

## Plan of action

- Decisions
- Settle on a component structure
- I.e. the shared classes described in this talk
- Decide on package organization
- I.e. where do we put these classes?
- Decide if the above is common for muon and inner detector

- Event Data History           David Adams   BNL

- December 2001

## Plan of action (cont)

- Implementation
- Linear algebra (choose/implement something)
- Detector description as needed
- Base tracking classes
- Muon identifiers, digits and digit containers
- Muon RecoHit classes
- Propagator(s)
- Wrap existing algorithms in Fitter or Finder interface
- Muon  (tracking?) Athena algorithm

- Event Data History           David Adams   BNL

- December 2001