Cms Tracker Visualisation Tools
M.S.Mennea, G. Zito, A. Regano, UNIVERSITY & INFN , Bari, Italy
I. Osborne, NORTHEASTERN University, Boston, USA
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.
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 |<![if lt IE 3]>η<![endif]>| < 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) 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 representation of both detector and event objects.
- Standard projections of 3D
- Layered 2D projections
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
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
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
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
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:
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.
- Easy selection of each detector part down to the single module.
- Development of a representation that would show all modules at once in a
single computer screen with single modules information coded in some way.
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
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
- Mennea,M.S; Regano,A; Zito,G. "CMS Tracker Visualisation" , CMS-NOTE-2004-00
9; Geneva : CERN,08Jun2004
- http://iguana.web.cern.ch/iguana/docs/ : starting from this directory you can find images produced by
- Paper :
in postscript and
- poster in ppt format