Tracking Review Report (Revised)


This review was held between 2 May (kickoff meeting) and 19 May 2005 (second closeout meeting). The detailed review page can be found at TrackingReview.


The common goals for all reviews are:

  • Encourage some self-analysis - what did the developers think that they were required to do, and did they deliver?
  • Get some client/user feedback on :
    • Ease of use (documentation, examples, user support,...)
    • Performance ( Did it work? Did it work well enough? What is the testing policy ?)
    • Requirements (what was thought to be missing?)
  • What were the lessons learned from DC2 and from CTB?
  • Trigger some forward planning. In the light of the review, enable the sub-system coordinateurs to formulate a plan for future developement.

Focus for the Tracking Review

It was agreed by the review committee and the software coordinators of the Inner Detector and Muon Spectrometer that the scope of the Tracking Review would include the union of the Inner Detector and Muon Spectrometer offline software, not only the common Tracking software. It was also agreed that such a scope was enormous and could not possibly be covered in the allotted time. During the Kickoff Meeting of 2 May, the coordinators suggested that the focus of the review include the following:

  • Completion of Necessary Functionality for LHC Physics
    • From the existing software and its documentation, identify missing components deemed necessary for LHC start-up;
    • From the planning documents of the two projects, evaluate if the missing components are properly covered in a manner that is timely and consistent with the overall Atlas plans;
    • Provide suggestions for implementing the missing components and/or correcting plans, if necessary.

  • Common Tracking
    • Review the existing common Tracking software and documentation;
    • Provide feedback on the architecture, design, and overall plans.

  • User Environment
    • Evaluate the current user environment, including documentation, examples, tutorials, etc.
    • Identify areas that need improvement.

Specific Muon Focus

The Muon Software coordinator requested that, concerning the missing functionality (point 1 above), he would like specific feedback on the plans for DC3. In particular, he would like to know if he is correct in focusing development efforts on supporting simulation and reconstruction of data for the Muon Cosmics program, starting this summer. He pointed out that this would exercise all of the mechanisms being put in place for conditions data (COOL database, IOVSvc, calibration, alignment, ...) in a realistic environment and that he has been emphasizing this as a high priority. He would like guidance as to whether this is acceptable, in that it might mean that some of the overall Atlas mis-calibration, mis-alignment tests would be less extensive (although the schedule would be respected).

Specific Inner Detector Focus

The Inner Detector Software Coordinator asked for specific feedback on the design and implementation of the RTF prototype. (contact Markus for more words, if he wants).

Findings, Comments and Recommendations

Rather than being organized according to the high level goals of the review, these are organized by topic, where particular issues or problems had been identified.

Common Tracking Software


  • Good documentation is available.

  • The current detector descriptions for both the Inner Detector and Muon Spectrometer, based on GeoModel, do not include corrections for chamber deformations, sags and other features beyond simple displacements and rotations for mis-alignment. It is generally agreed that this functionality is needed for reconstruction, possibly as part of a calibration service, and by the digitization, but probably not for the simulation. It is thus not necessary to implement this in GeoModel, itself, although that might be possible. Deformations are currently in use by the Muonboy reconstruction program, implemented in Amdcsimrec, a geometry model independent of GeoModel, and the Muon Group is looking into generalizing these methods. Development of a common service to handle wire sag for calibration and digitization is also underway.

  • Both the Inner Detector and Muon Spectrometer groups have made significant contributions to the common tracking effort. The Muon group began several years ago by basing the Moore reconstruction program on shared components of iPatRec, an Inner Detector reconstruction program and by the development of MuID, a cross-detector muon reconstruction program. More recently, the Inner Detector group has made significant contributions to the common Tracking package utilities and EDM, following the recommendations of the RTF. The Muon group has recently stepped up its contributions to this effort, as well.

  • The reconstruction view of the geometry (the so called Trk::Surfaces and Trk::Volumes) is now heavily used in combined reconstruction (via the TrackToCalo tool) and calorimeters have started to join. Both Moore and MuID are migrating to use Trk::Surfaces.

  • Combined reconstruction uses custom surfaces which do not necessarily match a physical volume. For example, in MuID, two surfaces are generated at run-time, corresponding to a parametrisation of the observed Coulomb scattering in the calorimetry.

  • Modularity of the reconstruction software is desirable, when possible, to optimize maintainability of the software. It should not, however, be allowed to seriously compromise physics performance or violate computing constraints, such as timing. The level of modularity proposed by the RTF is being implemented as a prototype, for investigation.

  • The successful modularization of the tracking software will result in multiple combinations of components. To become feasible, decisions will need to be made in a timely manner to establish a baseline for the default reconstruction. Such decisions will depend on physics performance and computing constraints. In the early stages, it will be possible and desirable to maintain several possible software chains and data containers for comparison and validation.


  • The common TrackingSoftwareOverview document is a laudable effort to present a uniform portal for information on the Inner Detector, Muon Spectrometer, and common Tracking software. This documentation needs completion (mainly introductions) and should be targeted for publication as an ATLAS note.

  • There is everything to be gained from making the common tracking area as large as feasible. The specific differences between the ID and muon systems are mostly concentrated in domains such as the creation of RIOs, the purely pattern-recognition part of the tracking, and the treatment of alignment and calibration. In addition, there is a significant difference in scale, in that the occupancy of the Inner Detector is much higher than that of the Muon Spectrometer. This can be an important factor for determining the content of the tracking output and analysis EDM (ESD and AOD).

  • The committee views the recent increased involvement from the muon community as a very positive sign and encourages further such activity.

  • It is important to keep in mind that this work is often directly connected with work on the Detector Description side.

  • The committee strongly supports the wrapping of the Muonboy backtracking into the common tools, if possible, so that the whole combined reconstruction sees a uniform interface for geometry and extrapolation. This should be compared and tested against other methods currently in use, if they conform to the common interfaces and EDM.

  • Establishing a well defined baseline set of components will become important, and will require the setting up of metrics and performance tests. While it is recognized that having several reconstruction chains can be beneficial, difficult decisions will need to be made which must be based on good physics requirements and feedback.

  • Both the Inner Detector and Muon Spectrometer appear to be on the path towards design and implementation of an EDM that matches the HLT requirements. Improvement to the Muon documentation on the usage of offline algorithms for HLT is needed. Currently, one needs to study the Moore documentation, for example, to learn of the usage of its various algorithms in the package TrigMoore. In addition -- although this is beyond the scope of this review -- it is highly desirable for the Muon Level 2 trigger to comply by the software requirements of the Trigger community (removal of F90 dependency, for example).

  • Current efforts to migrate MuID and STACO (combined muon reconstruction software) to use Trk::Track as the internal (and external) EDM should be supported and continue to target Release 11 as an initial implementation. Efforts to migrate to the usage of Trk::Track or Trk::TrackSegment as part of the internal EDM to xKalman, iPatRec, MOORE and/or Muonboy should be supported and targetted for a later release date, possibly Release 12. It is noted that Trk:Track and Trk::TrackSegment have been optimized as persistent objects and that internal representations will most likely vary, for optimisation reasons, depending on the algorithm.

  • Investigations into the creation of an HLT version of Muonboy are useful to the extent that they drive time optimisation studies and can lead to improvements in the software. However, it should be recalled that the HLT group has stated clearly that F90 will not be accepted, so only minimal manpower should be diverted to this effort.

  • Considerable effort has gone into providing good documentation for the common tracking software. However, a high level overview would simplify life for newcomers.


  • (C1) Follow the RTF recommendations. The reconstruction programs should work towards increased modularity. The minimal first step is to share a common input and a common output EDM. Further modularity and internal usage of a common EDM is to be encouraged, when feasible, as a logical second step of migration.

  • (C2) ESD content should be revisited with the goal of being able to redo track reconstruction from ESD for the initial phase of ATLAS operation. Initiatives such as the recent one to include track segments in the overall EDM at the ESD level should be extended to SpacePoints, PrepRawData, and RiOonTrack (from which TrackSegments inherit) etc., subject to size constraints.

  • (C3) There should be a strong drive to have all the structural changes in place before the cosmic running starts (i.e. Spring 2006), together with at least one version for a full chain of components, even if some functionality is missing. It is recognized that the Muon system will be taking cosmic data from the Atlas Pit possibly as early as July, 2005. So, compromises will be required in the final plans, to ensure support. However, the effort to migrate should continue, even if developed in parallel.

  • (C4) Establish metrics and performance tests for the reconstruction software in support of the decision making process for establishing a baseline set of components.

  • (C5) GeoModel should be adopted throughout in a unified way. Priority (if needed) should be given to the treatment of the active volumes and to specifying the nodes where the critical transforms lie (including the top-level ones).

  • (C6) The relationship between the tracking surfaces and GeoModel geometry should be clarified and a coherent strategy should be established, documented and propagated across all detector subsystems.

  • (C7) Deciding on the optimal treatment of passive material should be kept at a low priority if the resources are not sufficient. Current methods include a GeoModel material description (being developed by ID experts), custom hard-coded models (used by iPatRec, xKalman, and Moore), an Amdcsimrec material description (used by Muonboy), or a Geantino Material Map based on GeoModel (alternatively used by Moore). The functionality of the current implementations are sufficient for performance studies and for use as a reference. The pros and cons of the various approaches should be examined at a later stage. Usage of a common interface, allowing for the interchange of methods, is desirable (see C1 and C4, etc.).

  • (C8) The ESRAT coordinator (Andrea Dell'Acqua) should organize a workshop during Summer 2005 with GeoModel users from different communities to discuss what needs to be done about GeoModel deficiencies (e.g. deformations).

  • (C9) Wherever the current GeoModel description does not go down to the readout granularity sufficiently, this should be corrected.

  • (C10) The EDM for Release 11 should be reviewed based on experience from the Rome Workshop in terms of design and implementation with respect to the HLT requirements.

  • (C11) The common software packages shared by Moore and iPatRec should be moved into a common area, such as Tracking, and evolved to satsify the criteria of the RTF and the common Tracking plans, as soon as feasible. Current efforts to migrate the software to using a common input EDM should be supported and an initial implementation completed by Release 11. Further migration to usage of common TrackSegments and Tracks internally should proceed as a natural second step, perhaps slated for Release 12, if possible. It is recognized that such migration must occur simultaneous to the support of major detector efforts, such as Muon Cosmics (Summer 2005), so it must be done "in the background", minimizing major code breaks.

  • (C12) Backward navigation to MCTruth has to be correctly implemented for ID and Muons. At the first level, it should be possible to retrieve information pertaining to all MC tracks contributing to each RIO (Reconstruction Input Object) written to ESD. This is currently possible for the Muons, but requires navigation from digits back to the MC Hits and some information might be missing. It is not yet possible for ID, since PrepRawData is not included in the ESD for the Inner Detector. Suggestions for implementing a common method were provided during the review. A common solution should be sought for Release 11, if possible.

  • (C13) A dedicated “Truth Task Force” should be set up immediately after the Rome Workshop to consider all aspects of the MCTruth (action item on Computing Management). In addition to handling the RIO's, as described in C12, truth association for common Tracks should be implemented, using an example algorithm to make decisions based on the associated RIO's.

Inner Detector Software


  • Good documentation is available

  • Understanding alignments in the context of the CTB is not progressing as fast as hoped for.

  • Currently validation testing at the RTT is inadequate.


  • The committee comments the ID software developers for their comprehensive documentation, noting that they have been particularly active in providing extensive Doxygen documentation.

  • The committee strongly supports the strong emphasis on analysing the CTB data in order to understand the detector alignment.

  • The committee welcome the recent addition of new manpower for improving the RTT test coverage


  • (I1) Put highest priority on RTF prototype for release 11. This milestone cannot be missed and if it is perceived to be at risk, work e.g. on passive material treatment within GeoModel should be redirected.

  • (I2) Alignment experts should exercise their proposed algorithms on CTB data..

  • (I3) More effort is needed on the general validation for the software validation group.

Muon Spectrometer Software


  • Good documentation is available.

  • The Detector Description of the Muon Spectrometer is the largest and most complex of any of the Atlas Detector components. The following steps are currently implemented to handle this complexity and to provide geometry models and services for simulation and reconstruction:
    • A minimal set of geometry parameters called AMDB is prepared from technical drawings and tables. It exists in a variety of formats, including a structured ASCII text file.
    • The ASCII file is validated using the visualisation and consistency-checking tool Persint.
    • The AMDB data is transfered to relational tables in the Oracle Detector Description Database. In addition, a string of the text file is also stored.
    • The Oracle tables are read into Storegate and a GeoModel description is built for usage by simulation (via the G4 converter) or by reconstruction, calibration, alignment and visualisation algorithms in Athena. The Moore and MuID reconstruction programs are based on this geometry model.
    • The AMDB string is read into Storegate and an Amdcsimrec (F90) description is built for usage by the Muonboy reconstruction program and the Persint visualisation program.

  • Two primary tracking codes exist - Muonboy (written in F90) and Moore. Both run in Athena and share common input and output EDM. The output EDM is also shared with the Inner Detector reconstruction (Trk::Track). Muonboy is the more mature of the two, as it was developed over the course of 10-15 years (estimate). It works well in test beam and on Atlas simulation, and handles complex geometrical problems, such as chamber deformations, but uses the Amdcsimrec geometry model, rather than GeoModel. Moore is younger (3-4 years), but is starting to reach a similar level of maturity. It represents an effort to develop common software, as it shares several utilities with iPatRec, and its internal track has been based on efforts to come up with a common EDM for iPatRec and xKalman. It was one of the first major Athena applications, following the pre-RTF guidelines for data/algorithm separation.

  • The Muonboy and Moore programs handle tracking through material differently. Muonboy integrates material using Amdcsimrec and creates scattering surfaces for reconstruction. Moore also uses scattering surfaces, as well, but its results are currently less realistic than Muonboy, and a method using Geantino maps is being investigated.

  • Combined Muon Reconstruction is handled by the MuID and STACO programs. These programs are currently migrating to input Trk:Tracks and to output TrackParticles and CombinedMuons. This migration is nearly complete and will allow the programs to receive input from any ID and any Muon reconstruction program. Currently, MuID works only with input from iPatRec and Moore.

  • Calibration data for CTB exist as ASCII files on AFS, which are not easy to access for remote development and analysis. Data models are currently being developed in Athena and work is underway to store the conditions data in COOL. The Muon group is leading development in order to use COOL effectively for Muon Cosmic data taking in July 2005.

  • Alignment data for CTB is stored in ASCII files, using the format of AMDB. This data has successfully been stored in CondDB and accessed via IOVSvc. Alignment parameters calculated from straight tracks in CTB have been successfully written back to the DB. Alignment Data for Muon Cosmics is also targeted to use COOL and IOVSvc.


  • The committee commends the muon software developers for their comprehensive documentation. Some work is still needed to complete the migration to the Wiki pages and to provide a clear view of the software chain for new developers.

  • The geometry model Amdcsimrec is more mature and better tested than the relatively new GeoModel description. Its interpretation of the geometry parameters is the same as that used by the validation software, so it is currently the reference. An algorithm AmdcMGM can be used to validate the GeoModel description against Amdcsimrec. A few minor descrepencies exist and are being worked out. In addition, there is functionality in Amdcsimrec, mainly pertaining to the description of chamber deformations, that are not implemented in GeoModel.

  • Both Moore and Muonboy have taken steps to comply by common input/output EDM and are investigating the possibility of sharing internal modules, such as fitters and track interpolaters/extrapolaters for handling material. For this to work, common internal EDM and common interfaces will need to be developed. Neither yet comply completely with the RTF recommendations.

  • The committee is concerned about the complexity of the treatment of material in the Muon Spectrometer. Current GEANTINO maps are very large (order 100 MB) and might be impractical. Methods being developed by the common tracking group are not yet complete and might require too much processing time to work for the Muons. The Muonboy method has dependencies on Amdcsimrec (F90) that would need to be removed to be used as a common tool.

  • The Muons should continue to lead the COOL DB development with Muon Cosmics as the primary test bed. It is recognized that this work is essential for detector support and will provide important feedback on the conditions data mechanisms. Support of Muon Cosmics as a testbed for DC3 development is acceptable, provided the timelines for general Atlas milestones are respected.


  • (M1) The complete validation of GeoModel should be a top priority for the detector description. Following that, the handling of chamber deformations should be implemented. Most likely, these deformations are not needed by simulation, but by digitization, calibration, and reconstruction, so they will become a common service outside of GeoModel. If possible, that software should be made common to all detectors, so coordination with the ID group is desirable.

  • (M2) Following the successful validation of GeoModel and the implementation of deformations, a clear plan to migrate Muonboy and any other applications dependent on Amdcsimrec to GeoModel.

  • (M3) Moore and Muonboy should continue their migration to the common EDM, including the following steps:
    • Usage of PrepRawData for input to reconstruction, allowing reconstruction from ESD;
    • Separation of clustering algorithms from reconstruction, as possible;
    • Development of a common Track Segment as an output object to ESD, and as a possible "seed" for input;

  • (M4) Investigations into the modularisation of Moore and Muonboy should continue, through active participation in the common tracking efforts being led by the ID group. An evaluation of the RTF prototype, including effects on physics and computing performance, should be made upon its completion, in order to determine which aspects are desirable for the Muon reconstruction programs.

  • (M5) Investigation into the creation of a common material service for all reconstruction should continue at a rapid pace. Methods, such as GEANTINO maps or the common surface/volume handling being developed, should be made to conform to a common interface and then evaluated for physics and computing performance. Close cooperation between ID and Muons is required. (C7 is the corresponding common tracking recommendation).

  • (M6) Staco and MuID should aim to complete their migration for the input/output EDM by Release 11, if possible, allowing any combination of ID/Muon reconstruction algorithms for input and providing the same output.

  • (M7) In line with M4, both MuID and STACO should remove any dependencies on ID or Muon reconstruction software packages (if they exist), similar to the current clean up of the egamma, eflow, and taurec packages.

  • (M8) Completion of the MDT calibration data model in Athena should be targeted for Release 11, if possible. Test beds for validation of this model should include CTB and Muon Cosmics, as well as the full Atlas simulation.

Appendix A: The Review Committee




-- DavidQuarrie - 04 Jul 2005

Edit | Attach | Watch | Print version | History: r11 < r10 < r9 < r8 < r7 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r11 - 2005-07-04 - DavidQuarrie
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Sandbox All webs login

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