Muon Reconstruction based on

Kalman filter
in the MOORE framework
(progress report )
Y. Fisyak, BNL

Outline
Kalman filter
Geometry
Design of Muon reconstruction based on
Kalman filter
Digits and Digitization parameters
New packages
Integration into Athena

Kalman Filter
The Kalman filter is a recursive technique of obtaining the solution
by a least squares fit. This recursive method has the advantage of
computational efficiency.
In addition, the quality of hit to be included in the fit is known prior to
the fit. It could be very useful in sense of offline detector element
alignment.
In addition, the Kalman filter is able to extrapolate the fit track to the
next hit point at which time actual hits may be searched for in some
window of the extrapolation.
An advantage of Kalman filter is natural accounting multiple
scattering and energy loss. But this requires a complete description
of geometry including dead materials.
It was natural to try xKalman codes developed for Inner Tracker.
Unfortunately to speed up reconstruction I.Gavrilenko built a lot
knowledge about Inner Tracker geometry into the codes. From other
side the Inner Tracker geometry is much more regular and simpler
than the Muon System one. Thus this attempt has failed.

Geometry and geometry description.

To reconstruct track in the Muon system we need geometry i.e. a
way to find out the answers on the questions:
Where am I ?
What is distance to next boundary ?
In ATLAS the concepts "Geometry" and "Geometry description"
often are mixed up. Talking about "Geometry description" like Joe
(Geo) Model it is assumed that this is the "Geometry". This is not.
A "Geometry description" contains information (positions, rotation
matrices, materials) enough to build "Geometry".
Geometry is the system which provides answers on the above two
questions.
There are only 3 "Geometry" packages:

GEANT3,
GEANT4, and
new ROOT Geo package.
One more package called "Material Service" is being developed in
ATLAS which will hopefully answer the questions.

Geometry (cont.)

GEANT4:
The main issue of GEANT4 usage is to keep consistency between hits produced
in GEANT3 and detector geometry description in GEANT4. There is no tool to
create a one to one copy of GEANT3 geometry description in GEANT4
I dont have experience with track propagation in GEANT4 a `la GEANE. But I am
afraid that GEANT4 usage in reconstruction would be difficult because of
memory consumption (and speed).
ROOT Geo package:
practically direct copy of GEANT3 structures and it is good candidate.
There is a tool to populate the ROOT geometry description from GEANT3
(g2root).
But the package is ~8 months old and it is not mature enough to jump on it right
away.
My guess is that the new ROOT Geo package becomes stable in ~6 months. I
hope to see an update on this package status during CHEP03.
GEANT3:
For now this is only one geometry package which can be used in reconstruction.
The usage of GEANT3 for reconstruction in ATLAS Muon System has been
demonstrated with Cobra package (GEANE approach).
The idea is to use GEANT3 as tracking engine only in order to replace it in future.
This assumes that: we for now have to have two geometry descriptions:
One to do tracking (GEANT3) and
One to organize digit/hit geometry relation ( TVolume/TVolumeView), and
problem to keep consistency between these two geometry descriptions and
between geometry description and digits/hits.

Geometry Description based on

TVolume/TVolumeView
The approach have been reported during Lecce Moore meeting
(http://www.usatlas.bnl.gov/~fisyak/atlas/lecce.ppt ).
The main ideas are:
TVolume structure (compact geometry description i.e. with
multiple reuse) contains copy of full GEANT3 geometry
description with one to one correspondence to GEANT3. This
structure provides navigation from top to bottom.
TVolumeView structure (developed geometry description)
contains description for detector elements. This structure is
suitable for calibration constants, digits, etc.. This structure
provides both navigation from top to bottom and from bottom to
top.
TVolume/TVolumeView classes are in root/table package. These
classes use ``so called old ROOT geometry (root/g3d package)/

Digits and digitization parameters access

As it was mentioned above digits and hits are organized in
TVolumeView-like structure with navigation a `la GEANT3.

For the moment

there is a tool to obtain Atlas Identifier from GEANT3
geometry path, but
there is no tool to obtain GEANT3 geometry path from
Atlas Identifier in order to connect the Geometry
description with DigitContainers

This blocks a possibility to use MuonDigitContainer.

The solutions of this problem could be:

1. to keep Atlas Identifier in the TVolume structure, or

2. to have a map Atlas Identifier to GEANTs one in MySQL.
Ketevi is working on the first solution.
Digitization parameters used in reconstruction are obtained from
MySQL via Nova interface (thank to A.Vaniachine and S.Baranov)
and kept in TVolumeView structure.

New packages

MuonG3Model package (in MuonSpectrometer container package)

The package provides conversion of GEANT3 geometry, hits and

digits into ROOT TVolume/TVolumeView structures.

The package is in ATLAS CVS repository.

MooxKal package (in MuonSpectrometer/Moore container package)

It is not in repository yet and I would like to have it there.

The design of Kalman approach in Muon Spectrometer

reconstruction has been presented by David Adams
(http://www.usatlas.bnl.gov/~dladams/musys/structure.html)

The package contains the following components:

Classes describing Surfaces, Hits, Track fit parameters and

Tracks,
Steering,
Propagator, and
Fitter.

MooxKal (steering)
Steering includes reconstruction in the following steps:
rough approximation for track segments in each
station,
refit track segments with full information,
fit tracks from track segments, and
refit tracks using full (digits) information
The steps are the same as in MooiPat.
Thus as soon as the above tool for converting Atlas
Identifier to GEANT3 one will be available then
MooxKal can used complementary to MooiPat i.e.
To use tracks or/and track segments from
MooiPat and refit them using dead material
information

MooxKal (cont.)
Propagator:
The Propagator is based on GEANT3.
Access to GEANT3 is done via C++ wrapper (TGeant3, borrowed
from ALICE).
The propagator provides:
transport of track parameters from one detector element to
an other,
calculate transport matrix,
calculate covariance matrix due to Multiple Scattering and
Energy Loss Straggling.
Fitter:
The original codes were written in FORTRAN for the CMS Muon
system and now they are ported in C++.
TR: Linear algebra package for semi positive symmetric matrices:
It is based on CERNLIB tr-package.
Temporarily the package is in Database/AthenaRoot/ RootKernel.
The package is working within atlsim. The next step is to integrate it into
athena.

Integration into Athena

In order to access Atlsim from athena it is necessary to load ZERBA common blocks
into executable (otherwise it will be multiple instances of common blocks in the
different shared libraries which do not know about each other).
Srini has created the package Application/AtlsimAthena which contains:
Creation of Atlsim.exe which is obtained by linking together athena and whole
Atlsim except its main program.
To do this it is only needed to create archive library of atlsim which is linked as
whole with athena.
AtlsimSvc which is the main atlsim program and provides GEANT3 initialization,
and
AtlsimAlg which provide event processing
It is needed to obtain approval:
of modification of AtlsimMain requirement file from Pavel Nevski in order to
create the archive library, and
of new package from A-team.

Conclusion
Different pieces of Muon reconstruction based on
Kalman filter are coming together.
Of course it will require tuning and adjustments in the
direction of the ATLAS Event Data Model.
The main issue right now is the integration of MooxKal
package into athena framework. There is a way how to
do this with minimum modifications. The way has to be
approved.