Progress report on Muon Reconstruction based on Kalman filter 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 don’t 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 Corba 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 ( ). 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 GEANT’s 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 ( –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.