CMS Tracker Visualization

cms tracker

What we have now:

tracker layout

Tracker Atlas

Tracker Layout The tracker is a 6 m. long and 2.5 m diameter instrument based on silicon sensor technology. It has a complex spatial structure consisting of around 17000 silicon modules organized in 13 barrel layers and 14+14 end cap disks.
The tracker is in fact three detectors one inside the other all built with similar technology and geometry. Starting from the center we have:
  1. Pixel Detector based on silicon pixels.
  2. Inner Tracker based on silicon microstrips.
  3. Outer Tracker based on silicon microstrips.
The two outer parts form together the Silicon Strip Tracker and have a sensitive area of 206m2 with about 9.3 million channels.Each channel is a strip.Instead the Pixel Detector is based on square pixels 150x150 micrometers .Their total number is around 45 millions.
Each subdetector is divided in three parts : a cylindrical barrel( Pixel Barrel, TIB and TOB) and two disk shaped end caps(Pixel Forfard,TID and TEC). For each part we have many layers. Here is a detailed description of pixel , innner and outer tracker
You can imagine the whole detector like a russian doll with around 13 cylindrical boxes , one inside the other. In fact we have 13 open cylinders for the barrel and 14+14 disks that form the end caps of the cylinders. The two end caps can be also considered as a set of rings: 3 rings in the Inner Tracker (TID1-3) and seven in the Outer Tracker (TEC1-7). Here is a map of all the 17000 modules .

Silicon pixels are diodes implanted on semiconductor wafers that offer high spatial resolution in a plane giving the position where the particle has passed to within few microns. Silicon microstrip modules use instead strips as detecting elements. Concerning these, we have thin and thick modules, single and double sided modules . Each module consists of 1 or 2 6'' silicon wafers and is read by many readout chips called APV. Single sided modules measure only one coordinate , double sided modules give instead stereo coordinates. Double sided modules consist of two single sided modules mounted back to back sligtly tilted.

Tracker Barrel
Layer #Layer nameAvg. radiusModules in zModules in phiTotal # of modules Annotations
1PIX barrel41.05818128cylinder divided in half with half modules at the borders
2PIX barrel70.16830224 ''
3PIX barrel98.88842320 ''
4TIB1255.1226-30336+336=672tilted double sided modules
5TIB2340.1234-38432 ' '
6TIB3430.1244-46540 tilted modules
7TIB4520.1252-56648 ' '
8TOB16101242504+504=1008double sided modules
9TOB26961248576+576=1152 ' '

Tracker Endcaps
Disc #Disk nameAvg. z positionModules in phiN of rings Total # of modules Annotations
1FPIX34247In fact the disk is built like a "turbine disk" with 24 "blades"
2FPIX46247 ' '
3TID24-24-403Rings 1 and 2 double sided
4TID24-24-403Rings 1 and 2 double sided
5TID24-24-403Rings 1 and 2 double sided
6TEC24-24-40-56-40-56-807Rings 1, 2 and 5 double sided
7TEC24-24-40-56-40-56-807Rings 1,2 and 5 double sided
8TEC24-24-40-56-40-56-807Rings 1,2 and 5 double sided
9TEC24-40-56-40-56-806Rings 2 and 5 double sided
10TEC24-40-56-40-56-806Rings 2 and 5 double sided
11TEC24-40-56-40-56-806Rings 2 and 5 double sided
12TEC40-56-40-56-805Ring 5 double sided
13TEC40-56-40-56-805Ring 5 double sided
14TEC56-40-56-804Ring 5 double sided

The TOB system consists of the following main components:

Each rod is half of the length of the complete TOB. Thus, functionally the TOB is divided into two symmetrical parts, one on the Z+ side and one on the Z- side. These two sides are connected mechanically, rigidly, together to form one wheel structure.


The TIB is made-out of two independent units (Forward and Backward TIB) each one containing four layers of silicon modules arranged in a tilted, cylindrical geometry.Single-(double)-sided detector modules carry one(two) silicon sensor(s) with an active area of about 61.5x116.9mm 2 . In each layer the modules are organized in longitudinal strings of 3 elements on both sides of the supporting structure. The position of the modules in such strings is optimized to assure full coverage from tracks coming from the interaction point. The supporting structure for each layer is made by two half cylinders.


Modules are mounted on a disk organized in petals. We have 8 inner petals and 8 outer petals for each disk. Sensors are mounted on both sides of a petal: so we have 4 positions of the sensors in z:these are named A,B,C,D in order of increasing z.Ring 1,3,5,7 are mounted on sides A and C; the other rings on sides B and D.

Detector Description Database

DDD is the CMS project that is in charge of the detector database. Waiting for the final database (in XML) to be ready we have now at least two descriptions of the tracker:one as tz files for CMSIM and ORCA and the other for OSCAR. There is also this first approximation of XML description.
The OSCAR description uses Geant4 and can be visualized with Iguana.

Tracker construction database

This is the reference page for tracker construction. There is a database ready to collect all information about the detector pieces. It is a Oracle relational database in Lyon and can be accessed through a Java program. It is necessary to install a stand-alone program on your computer. There is also the Tracker EDMS : a site that collects all mechanical drawings.

Tracker Detector Control System(DCS) Tracker DCS is already operational on the test beam: it controls classical "slow control"operating conditions(power supplies voltages, temperatures, humidities,leakage currents) and also Front End electronics configuration data and laser calibration data. It is based on a Oracle Database plus a control system called SCADA.
The Tracker is self-calibrating and regular electronic calibration should take place in dedicated runs.

The tools

Objectives To build a set of graphics objects to help the visualisation of :

These objects should be used:
  1. Inside the reconstruction program Orca (integrated in Iguana).
  2. In a stand-alone program (possibly integrated in Iguana) that will process events created by Orca and ready to be displayed.
  3. In a Web interface

3D vs 2D : up to the level of the module, the structure is 3D. So the idea is to use 3D up to this level and then use 2D for further detail. Since single modules are planar in structure, this should not be a problem.

full display of tracker

Not a replacement of what we still have but an addition to make what we still have really useful. Now the main problems inside Orca/Iguana are:

  1. Too many 3D details:the display of everything is impossible unless you have a powerful video card. (For example the full display of the tracker seen in the previous picture requires around 500M of memory in OpenInventor!). On the other end, if you can select what you need , it can be used without problems on any computer.
  2. There are no events "ready to be displayed", you have to wait for Orca to process the event and this means a lot of time for "normal" events.
  3. You can't do a detailed selection (at the level of the single module) of elements to be displayed.

Why and when use a Web interface : in some cases you don't need to do complex manipulation (for example rotating a part of the detector in space), instead you just want to visualize some quantity. In this case a simple Web interface would be easier to develop and use. For example : display of data in the Construction Database. prototype

Why a stand-alone program? I some cases, it is absolutely necessary to work inside Orca, although difficult and slow this can be. Instead there is also the possibility that you want to process a lot of events (for example to sum the signal from many events) and you don't want to run Orca one week to get a single picture. In this case the idea is to run Orca in batch for one week, writing events ready to be displayed on disk and then use a fast stand-alone visualisation program to do the visual analysis. This program will get the detector and event description via XML files. DDD already has XML description of the detector; a similar description will be implemented/used to allow program indipendent transmission of events data between ORCA/Oscar and this visualisation stand-alone program. This format will be used for the "ready to be displayed events".

Tentative list of graphical objects to be developed:


Some open problems


Available Software

Giuseppe Zito:
Last modified .