Cms Tracker Visualisation Tools

M.S.Mennea, G. Zito, A. Regano, UNIVERSITY & INFN , Bari, Italy
I. Osborne, NORTHEASTERN University, Boston, USA

Abstract

This document will review the design considerations, implementations and performance of the CMS Tracker Visualization tools. In view of the great complexity of this subdetector (more than 50 millions channels organized in 17000 modules each one of these being a complete detector), the standard CMS visualisation tools (IGUANA and IGUANACMS) that provide basic 3D capabilities and integration within CMS framework respectfully have been complemented with additional 2D graphics objects and a detailed object model of the tracker. Based on the experience acquired by using this software to debug and understand both hardware and software during the construction phase, we will propose possible future improvements to cope with online monitoring and event analysis during data taking.

Introduction

We present a visualisation system which is designed to debug and monitor the CMS tracker sub-detector hardware, event simulation and reconstruction algorithms. It is also used for the test-beams, physics analysis, and also addresses presentation issues for publications and talks.
The CMS tracking system is a very complex sub-detector. The designed goal of the central tracker system is to reconstruct isolated high Pt tracks with an efficiency of better than 95%, and high Pt tracks within jets with an efficiency of better than 90% over the rapidity range |η| < 2.6. Important discoveries may depend on the ability of the tracking system to perform efficient b-tagging even at the highest luminosity.
3D View of CMS Tracker.One of the two endcaps and part of the barrel have been cut away , in order to show better the structure of the apparatus.Each single "sheet" is a module. The central part is the pixel detector.
The visualisation tools for the tracker are implemented in C++ within IGUANACMS framework based on the IGUANA generic toolkit for graphics which provides an MDI (multi-document interface) GUI (graphical user interface) with:
  1. 3D representation of both detector and event objects.
  2. Standard projections of 3D
  3. Layered 2D projections
1) provides good overall pictures and 2) 3) are useful for event analysis where one wants to do precise measurements. The first chapter in this summary shows how these representations are used for the tracker. Detector monitoring has required the development of an additional representation. In fact in this application it is important for the user to see the whole detector in a single image with each module clearly visible. This schematic planar view of the tracker , which has required a detailed object model of the detector for its implementation,is described in the second chapter of this summary and is fully integrated with the other representations.

3D and 2D Visualisation Tools

The user of the CMS tracker visualisation tools has a possibility to choose whether he wants to work with the tracker geometry only, or in addition to it with simulated or test-beam data, or in addition to the above with the reconstructed data and DSTs. Such an option is given at the start-up of iguana as a configuration file to optimize the use of computer resources (memory) and also to speed up the initialization by loading the minimum number of plug-ins (shared libraries). This configuration file is passed either as an argument in the command line or it is placed in a default location usually in the current working directory and has a default name.

Tracker Geometry Visualisation

The CMS tracker geometry is fully described in DDD (detector description database) in XML format. The description is quite detailed and not every user would like to work with the full tree which has numerous branches each almost fifteen layers deep and every mother-daughter volume has a four letter name which is not easy to remember. The use case to work with full tree is quite specific and not many users exploit this possibility even though the information about volumes is very detailed such as materials, sensitive detectors and support structure as well as cables is available. The possibility to visualize volumes by material and other filters.
Oscar visualisation of tracker geometry

Simulated Event Visualisation

The purpose of the simulated event visualisation is to verify whether the data cards given to production produced correct results from the physicist point of view. It is also possible to verify the correctness of described tracker geometry by matching simulated data (sim hits) and sensitive detector units. Simulated data can either be read from a POOL database or simulated at run-time from specified in configuration generator, Pythia, for example.

We visualize tracker sim hits as points. The sim hit is a point in the 3D space produced by a simulated track crossing the detector unit. The product of the crossing has two points - the entry point and the exit point. The 3D representation of a sim hit is the middle point between those two.

Simulated tracks are shown as straight lines connecting the sim hits (shown as dots) belonging to the simulated track. Straight lines representation is good enough for the tracks with Pt higher then 1GeV. The simulated tracks contain color-coded information about particle type: muons are shown red, electrons - green, pions - blue, the rest of charged particles - cyan. This information comes from the first sim hit which knows about the particle id.

Reconstructed Event Visualisation

Visualisation of the reconstructed tracker event for ORCA - CMS reconstruction project - is used for verification of the digitization and reconstruction algorithms. A user has a possibility to check that simulated data (sim hits) belong to the detector units and all detector units are active, e.g. all detector units have sim hits. In addition he can match the simulated data to digis (signal) and reconstructed data. For example, the reconstructed tracks can be shown with corresponding simulated tracks.

The rec hit is a reconstructed signal which is a point in space and for the stereo detector units it has a precise position in 3D. The rec hits from the rest of the detector units have a point with an error equal to the silicon channel length. We visualize the rec hit as a 3D point for the stereo detector units and a strip is shown for the rec hist which are not matched to the stereo detector units. During visualisation a user can zoom closely to see both a sim hit and a rec hit. A recent user request is to have the tools to measure the distance between those two.

Reconstructed tracks are shown as straight lines connecting the measurements produced by reconstruction algorithms. The measurements have also a direction which can be shown optionally.

The events with high luminosity 10 to 34 (signal event plus pileup) show the complexity of the problem for reconstruction. Simulated tracks and simulated hits can be filtered, the parameters of the filters are given interactively. Both sim tracks and sim hits selected for visualisation use the same filters. Such an approach is used in verification of the reconstruction algorithms to visualize correlated sim hits and reconstructed tracks. By association of reconstructed tracks with simulated tracks from the signal event we can show the particle type by color coding. Reconstructed muons are shown with red color, electrons are reconstructed but not associated with sim tracks since radiated electron tracks change the track ID. Future implementation will include association with such tracks. The rest of reconstructed tracks are shown with cyan. Those tracks are reconstructed from both signal and pile up event. The sim hits from signal event are shown with red.
2D projection of event
Layered projection of event
Event with high luminosity 10 to 34 (signal event plus pileup)
Same event filtered
Event with display of modules hit by selected tracks

Schematic tracker representation

Need for a specialized representation for monitoring

Discussion about visualisation needs with people on charge for tracker monitoring has brought up the following two use cases:
  1. Easy selection of each detector part down to the single module.
  2. Development of a representation that would show all modules at once in a single computer screen with single modules information coded in some way.
Both these two use cases have been solved with the development of specialized 2D representations of the tracker.Their implementation has also required a detailed object model of the tracker. This model is described elsewhere[1].

Selection of tracker parts and single modules

The way selection is implemented in IGUANACMS , i.e. with a tree, is not easy to use for the tracker, due to the fact that the tree should have five levels of branching and 17000 leafs. For this reason we have simplified the interface for the user , by introducing a 2D schematic representation of the tracker parts. The user select each part (subdetector,layer,ring) by clicking on its representation on the image. If the user needs to select instead a single module in a layer, this can be done by opening a new window with a planar representation of all the modules in a layer , and clicking on the module representation.
Selection of tracker parts.
Check with other detector's signal

Schematic representation for tracker monitoring

The basic idea behind this representation is to have a kind of map of the whole tracker where one can see each part down to the single module and channel. For this we use the following technique: since the single module is flat , we imagine to disassemble the whole tracker and to assemble it again on a flat surface putting the single modules in positions which are connected to their spatial position. The result is a kind of map of the whole tracker with each one of the 41 layers in a different position.
In this map each layer can be represented in two ways: This is the basic map on which we can represent simulated hits , reconstructed hits and other informations concerning each module. In the overlayed mode the simulated and reconstructed hits are represented by single points in red and green respectively.In the separated mode we represent them by using a color code proportional to the number of hits in the module.
Another possible use of the separated mode map for monitoring can be seen in this picture of the whole tracker obtained by accumulating the signal from one hundred events and coloring each module according the total number of hits in the module.Such a map can show quickly during data taking if there are problems by the presence of holes or increased activity.The same technique is used to monitor other detector running conditions, like temperature or voltages.

Going to the level of the single channel

The tracker map can be thought as a scatter plot with an entry for each module. Up to now we have not implemented a zoom of this map (and we don't know if this is necessary). Instead if you want to go to the level of the single channel(there are a few hundred channels for each module corresponding to strips or pixel), you have to select a single layer of the 41 that form the tracker. The layer will be zoomable in future and can represent the information down to the level of the single channel. At this level it should be possible to check for example the position of the signal with the position of faulty channels. At this level of detail we can introduce many different representations of informations: for example drawing fired strips ,writing the value of the information represented,... A popup menu' (not yet available) should allow the user to tailor the representation to his needs.
Endcap and barrel with rechits and simhits.
Representing fired strips in a layer
Writing the number of fired strips on the module

References

  1. Mennea,M.S; Regano,A; Zito,G. "CMS Tracker Visualisation" , CMS-NOTE-2004-00 9; Geneva : CERN,08Jun2004

Other materials

  1. http://iguana.web.cern.ch/iguana/docs/ : starting from this directory you can find images produced by IGUANACMS.
  2. Paper : in postscript and in pdf.
  3. poster in ppt format