1 % ---------------------------------------------------------------------
5 % ---------------------------------------------------------------------
7 \documentclass{alicetdr}
8 %\documentclass[draft]{alicetdr}
15 \renewcommand{\rmdefault}{phv}
16 \renewcommand{\sfdefault}{phv}
18 \let\Otemize =\itemize
19 \let\Onumerate =\enumerate
20 \let\Oescription =\description
21 % Zero the vertical spacing parameters
22 \def\Nospacing{\itemsep=0pt\topsep=0pt\partopsep=0pt\parskip=0pt\parsep=0pt}
23 \def\Topspac{\vspace{-0.5\baselineskip}}
24 \def\Botspac{\vspace{-0.2\baselineskip}}
25 % Redefine the environments in terms of the original values
26 \newenvironment{Itemize}{\Topspac\Otemize\Nospacing}{\endlist\Botspac}
27 \newenvironment{Enumerate}{\Topspac\Onumerate\Nospacing}{\endlist\Botspac}
28 \newenvironment{Description}{\Topspac\Oescription\Nospacing}{\endlist\Botspac}
36 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
40 \font\HUGEA=phvr at 36mm % declare very big font
41 \font\HUGEB=phvr at 14mm % declare very big font
48 {\HUGEA T\hspace{5.mm}R\hspace{5.mm}D} \\
51 {\HUGEB Offline Software Writeup} \\
54 {\Large Version 1.0, \today}\\
64 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
66 % Empty page to adjust page numbering
75 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
77 \pagenumbering{arabic}
79 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
83 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
85 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
86 \setcounter{chapter}{0}
87 \setcounter{section}{0}
88 \Chapter{Introduction}
91 This document is supposed to provide a description of the offline
92 software components that are specific to the TRD. It is an attempt
93 to collect useful informations on the design and usage of the TRD
94 software, in order to facilitate newcomers the introduction to the
95 code. The most important classes and procedures are described and
96 several examples und use cases are given.
97 However, this writeup is not meant to be a basic AliRoot introduction.
98 For this purpose the reader is referred to the general AliRoot users
101 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
103 \setcounter{chapter}{1}
104 \setcounter{section}{0}
106 \thispagestyle{empty}
111 {\it Author: C.~Blume (blume@ikf.uni-frankfurt.de)}
115 The TRD geometry, as implemented in {\tt AliTRDgeometry}, consists of
116 several components: The readout chambers (ROC), the services, and the
117 supermodule frame. All these parts are placed inside the TRD mother
118 volumes, which in turn are part of the space frame geometry
119 ({\tt AliFRAMEv2}). Therefore, the space frame geometry has to be
120 present to build the TRD geometry. For each of the 18 supermodules
121 one single mothervolume is provided (BTRDxx). This allows to configure
122 the TRD geometry in {\tt Config.C} such that it only contains a subset
123 of supermodules in the total ALICE geometry via
124 {\tt AliTRDgeometry::SetSMstatus()}. An incomplete detector setup, as
125 it exists for first data taking, can thus be modelled. The class
126 {\tt AliTRDgeometry} also serves as the central place to collect all
127 geometry relevant numbers and the definitions of various numbering
128 schemes of detector components (e.g. sector numbers). However, all
129 geometric parameters that refer to the pad planes are compiled in
130 {\tt AliTRDpadPlane}.
132 \subsection{Readout Chambers}
137 \includegraphics[width=0.85\textwidth]{plots/geo_roc.eps}
140 A TRD read out chamber as implemented in the AliRoot geometry. The
141 various material layers are visible. Also, the MCMs on top of the
142 chamber, as well as the cooling pipes are shown.
144 \label{FIG_GEO:roc_geom}
147 All ROCs are modelled in the same way, only their dimensions vary.
148 They consist of an aluminum frame, which contains the material for
149 the radiator and the gas of the drift region, a Wacosit frame (whose
150 material is represented by carbon), that surrounds the amplification
151 region, and the support structure, consisting of its aluminum frame,
152 material for the read out pads, back panel, and readout boards). The
153 material inside the active parts of the chambers (radiator, gas, wire
154 planes, pad planes, glue, read out boards, etc.) is introduced by
155 uniform layers of the corresponding material, whose thicknesses were
156 chosen such to result in the correct radiation length. On top of the
157 individual ROCs the multi chip modules (MCM) as well as the cooling
158 pipes and cables are placed. One obvious simplification, already visible
159 in Fig.~\ref{FIG_GEO:roc_geom}, is that in the AliRoot geometry the pipes
160 run straight across the chambers instead of following the meandering path
163 \subsection{Supermodules}
168 \begin{minipage}[b]{0.49\textwidth}
170 \includegraphics[width=0.65\textwidth,angle=270]{plots/geo_smframe.eps}
173 \begin{minipage}[b]{0.49\textwidth}
175 \includegraphics[width=0.70\textwidth,angle=270]{plots/geo_sm.eps}
180 A TRD supermodule, as implemented in the AliRoot geometry. The left
181 panel shows only the support structures of the aluminum frame, together
182 with some service elements. The right panel shows a complete
183 supermodule including some surrounding parts of the space frame.
185 \label{FIG_GEO:sm_geom}
188 The supermodule frames consist of the aluminum sheets on the sides, top,
189 and bottom of a supermodule together with the traversing support structures.
190 The left panel of Fig.~\ref{FIG_GEO:sm_geom} shows the structures that are
191 implemented in the TRD geometry. Also, parts of the services like the LV
192 power bus bars and cooling arterias can be seen. Additional electronics
193 equipment (e.g. ``Sch\"utten-Box``) is represented by aluminum boxes that
194 contain corresponding copper layers to mimic the present material. The
195 services also include e.g. gas distribution boxes, cooling pipes, power and
196 readout cables, and power connection panels. Part of the services extend
197 into the baby and the back frame. Therefore, additional mother volumes
198 have been introduced in order to accomodate this material. All supermodules
199 have inserts of carbon fiber sheets in the bottom part of the aluminum
200 casing, for the ones in front of the PHOS detector (sectors 11--15) also
201 the top part includes carbon fiber inserts. The supermodules in the sectors
202 13--15 do not contain any ROCs in the middle stack in order to provide the
203 holes for the PHOS detector. Instead, gas tubes of stainless steel have
206 Generally, the TRD volumina start with the letter ``{\bf U}''. The geometry
207 is defined by the function {\tt AliTRDgeometry::CreateGeometry()}, which
208 generates the TRD mother volumes ({\bf UTI1}, {\bf UTI2}, {\bf UTI3}) and the
209 volumes that constitute a single ROC. This function in turn also calls
210 {\tt AliTRDgeometry::CreateFrame()} to create the TRD support frame,
211 {\tt AliTRDgeometry::CreateServices()} to create the services, and
212 {\tt AliTRDgeometry::GroupChambers()} which assembles the alignable
213 volumes for a single ROC ({\bf UTxx}, where {\bf xx} is the detector
214 number {\bf DET-SEC}, defined inside a single super module, see below). The
215 materials, together with their tracking parameters, that are assigned to
216 the volumina, are defined in {\tt AliTRD::CreateMaterials()}.
217 In the following table the most important TRD volumina are described
218 ({\bf xx} = {\bf DET-SEC} number):
222 Name & Description \\ \hline
223 {\bf UTR1} & TRD mothervolume for default supermodules \\
224 {\bf UTR2} & TRD mothervolume for supermodules in front of PHOS \\
225 {\bf UTR3} & As {\bf UTR2}, but w/o middle stack \\ \hline
226 {\bf UTxx} & Top volume of a single ROC \\
227 & Defines the alignable volume for a single ROC \\ \hline
228 {\bf UAxx} & Lower part of the ROCs, including drift volume and radiator \\
229 {\bf UDxx} & Amplification region \\
230 {\bf UFxx} & Back panel, including pad planes and PCB boards of readout electronics \\
231 {\bf UUxx} & Contains services on chambers (cooling, cables, DCS boards) and MCM chips \\
235 \subsection{Material Budget and Weight}
239 \includegraphics[width=0.75\textwidth]{plots/geo_material_budget.eps}
242 The radiation length map in units of $X/X_{0}$ in part of the active
243 detector area of super module 0 as a function of the pseudorapidity
244 $\eta$ and the azimuth angle $\phi$, calculated from the geometry in
245 AliRoot. Visible are the positions of the MCMs and the cooling pipes
248 \label{FIG_GEO:mat_budget}
251 The volumina defining a ROC contain several layers that represent the
252 different materials present inside a chamber and which therefore define
253 the material budget inside the sensitive areas:
255 \begin{tabular}{l|l|l|l|c|c|c}
256 Name & Mother & Material & Description & Thickness & Density & $X/X_{0}$ \\
257 & & & & [cm] & [g/cm$^{3}$] & [\%] \\ \hline
258 {\bf URMYxx} & UAxx & Mylar & Mylar layer on radiator (x2) & 0.0015 & 1.39 & 0.005 \\
259 {\bf URCBxx} & UAxx & Carbon & Carbon fiber mats (x2) & 0.0055 & 1.75 & 0.023 \\
260 {\bf URGLxx} & UAxx & Araldite & Glue on the fiber mats (x2) & 0.0065 & 1.12 & 0.018 \\
261 {\bf URRHxx} & UAxx & Rohacell & Sandwich structure (x2) & 0.8 & 0.075 & 0.149 \\
262 {\bf URFBxx} & UAxx & PP & Fiber mats inside radiator & 3.186 & 0.068 & 0.490 \\ \hline
263 {\bf UJxx} & UAxx & Xe/CO$_{2}$ & The drift region & 3.0 & 0.00495 & 0.167 \\
264 {\bf UKxx} & UDxx & Xe/CO$_{2}$ & The amplification region & 0.7 & 0.00495 & 0.039 \\
265 {\bf UWxx} & UKxx & Copper & Wire planes (x2) & 0.00011 & 8.96 & 0.008 \\ \hline
266 {\bf UPPDxx} & UFxx & Copper & Copper of pad plane & 0.0025 & 8.96 & 0.174 \\
267 {\bf UPPPxx} & UFxx & G10 & PCB of pad plane & 0.0356 & 2.0 & 0.239 \\
268 {\bf UPGLxx} & UFxx & Araldite & Glue on pad plane & 0.0923 & 1.12 & 0.249 \\
269 & & Araldite & + additional glue (leaks) & 0.0505 & 1.12 & 0.107 \\
270 {\bf UPCBxx} & UFxx & Carbon & Carbon fiber mats (x2) & 0.019 & 1.75 & 0.078 \\
271 {\bf UPHCxx} & UFxx & Aramide & Honeycomb structure & 2.0299 & 0.032 & 0.169 \\
272 {\bf UPPCxx} & UFxx & G10 & PCB of readout boards & 0.0486 & 2.0 & 0.326 \\
273 {\bf UPRDxx} & UFxx & Copper & Copper of readout boards & 0.0057 & 8.96 & 0.404 \\
274 {\bf UPELxx} & UFxx & Copper & Electronics and cables & 0.0029 & 8.96 & 0.202 \\
277 This material budget has been adjusted to match the estimate given
278 in~\cite{CLEMENS}, with the exception of the glue layer in the back panel
279 ({\bf UPGLxx}), which has been made thicker to include all the additional
280 glue that has been applied to fix the gas leaks. Figure~\ref{FIG_GEO:mat_budget}
281 shows the resulting radiation length map in the active detector area for
282 super module 0, which has only carbon fiber inserts at the bottom and is
283 thus one of the super modules with the largest material budget. It is
284 clearly visible that the MCMs and the cooling pipes introduce hots spots
285 in $X/X_{0}$. However, after averaging over the shown area, the mean
286 value is found to be $\langle X/X_{0}\rangle =$~24.7~\%. For a supermodule
287 with carbon fiber inserts at the top and the bottom one finds
288 $\langle X/X_{0}\rangle =$~23.8~\% and in the regions of the PHOS holes (i.e.
289 in the middle stack of supermodules 13--15) it is only
290 $\langle X/X_{0}\rangle =$~1.9~\%.
292 The total weight of a single TRD super module in the AliRoot geometry,
293 including all services, is currently 1595kg, which is ca. 5\% short of its
294 real weight. A single ROC of the type L0C1 with electronics and cooling
295 pipes weighs 21.82kg.
297 \subsection{Naming Conventions and Numbering Schemes}
300 \begin{minipage}[b]{0.49\textwidth}
302 \includegraphics[width=\textwidth]{plots/sector_numbering.eps}
305 \begin{minipage}[b]{0.49\textwidth}
307 \includegraphics[width=\textwidth]{plots/layer_numbering.eps}
312 \includegraphics[width=0.60\textwidth]{plots/stack_numbering.eps}
315 Illustration of the TRD numbering scheme for super modules, defined in
316 the global ALICE coordinate system: a) {\bf SECTOR} number, b)
317 {\bf LAYER} number, c) {\bf STACK} number.
319 \label{FIG_GEO:sm_numbering}
322 The numbering schemes and the orientations of coordinate systems generally
323 follow the official ALICE-TRD definition \cite{DAVID}. Therefore, the
324 whole geometry is defined in the global ALICE coordinate system.
326 Inside the code we use the following nomenclature (see
327 Fig.~\ref{FIG_GEO:sm_numbering}), which should be used consistently
328 throughout the TRD code:
331 \begin{tabular}{l|l|l}
332 Name & Definition & Range \\ \hline
333 {\bf SECTOR} & TRD sector in azimuth (i.e. one supermodule) & 0--17 \\
334 {\bf LAYER} & Layer inside a supermodule & 0--5 \\
335 {\bf STACK} & Division of a supermodule along z-direction & 0--4 \\
336 {\bf DET} & Single ROC in whole TRD & 0--539 \\
337 {\bf DET-SEC} & Single ROC in one super module & 0--29
341 Due to the holes in front of the PHOS detector, naturally not all {\bf DET}
342 numbers correspond to existing ROCs. A single ROC can thus be uniquely
343 addressed by either using the three numbers
344 ({\bf LAYER}, {\bf STACK}, {\bf SECTOR}) or the single {\bf DET} number.
345 The correspondence between the two possibilities is defined as:
347 \mbox{{\bf DET} = {\bf LAYER} + {\bf STACK}$\times$5 + {\bf SECTOR}$\times$5$\times$4}
349 Additionally, there is a number that is unique inside a given super module (i.e.
350 sector) and therefore has a range of 0~--~29:
352 \mbox{{\bf DET-SEC} = {\bf LAYER} + {\bf STACK}$\times$5}
354 The class {\tt AliTRDgeometry} provides a set of functions that could/should
355 be used to convert the one into the other:\\
356 \hspace*{1.5cm}{\tt AliTRDgeometry::GetDetector(layer,stack,sector)} \\
357 \hspace*{1.5cm}{\tt AliTRDgeometry::GetDetectorSec(layer,stack)} \\
358 \hspace*{1.5cm}{\tt AliTRDgeometry::GetLayer(det)} \\
359 \hspace*{1.5cm}{\tt AliTRDgeometry::GetStack(det)} \\
360 \hspace*{1.5cm}{\tt AliTRDgeometry::GetSector(det)} \\
362 \subsection{Pad Planes}
364 All geometric parameters relevant to the pad planes are handled via the
365 class {\tt AliTRDpadPlane}. This comprises the dimensions of the pad planes
366 and the pad themselves, the number of padrows, padcolumns, and their tilting angle.
367 The initialization of the needed {\tt AliTRDpadPlane} objects is done in
368 {\tt AliTRDgeometry::CreatePadPlaneArray()}. The number of padrows can be 12
369 (C0-type) or 16 (C1-type), the number of padcolumns is 144 in any case. Again,
370 the numbering convention follows the definition given in \cite{DAVID}. Thus,
371 the padrow numbers in a given pad plane increase from 0 to 11(15) with decreasing
372 $z$-position, while the padcolumn numbers increase from 0 to 144 with increasing
373 $\phi$ angle (i.e. counter clockwise). The tilting angle of the pads is 2~degrees,
374 with alternating signs at different layers, beginning with +2~degrees for layer~0.
375 The class {\tt AliTRDpadPlane} provides a variety of functions that allow to assign
376 a pad number (row/column) to signals generated at a given hit position and which
377 are used during the digitization process.
379 \section{Hit Generation}
381 {\it Author: C.~Blume (blume@ikf.uni-frankfurt.de)}
385 In the case of the TRD a single hit corresponds to a cluster of electrons
386 resulting from the ionization of the detector gas. This ionization can be due
387 to the normal energy loss process of a charged particle or due to the
388 absorption of a transition radiation (TR) photon. A single TRD hit, as
389 defined in {\tt AliTRDhit} therefore contains the following data members:
393 {\tt fTrack} & Index of MC particle in kine tree \\
394 {\tt fX} & X-position of the hit in global coordinates \\
395 {\tt fY} & Y-position of the hit in global coordinates \\
396 {\tt fZ} & Z-position of the hit in global coordinates \\
397 {\tt fDetector} & Number of the ROC ({\bf DET} number) \\
398 {\tt fQ} & Number of electrons created in the ionization step. Negative for TR hits \\
399 {\tt fTime} & Absolute time of the hit in $\mu$s. Needed for pile-up events \\
403 On top of this, it is also stored in the {\tt TObject} bit field status word
404 whether a hit is inside the drift or the amplification region
405 (see {\tt AliTRDhit::FromDrift()} and {\tt AliTRDhit::FromAmplification()}).
406 The creation of hits is steered by {\tt AliTRDv1::StepManager()}.
408 \subsection{Energy loss}
410 A charged particle, traversing the gas volume of the TRD chambers, will release
411 charge proportional to its specific energy loss. In the TRD code this process
412 is implemented in \\{\tt AliTRDv1::StepManager()}. This implementation used a
413 fixed step size. The standard value here is 0.1~cm, but other values can be
414 set via {\tt AliTRDv1::SetStepSize()}. The energy deposited in a given step is
415 then calculated by the chosen MC program (typically Geant3.21), which after
416 division by the ionization energy gives the number of electrons of the new hit.
417 The version 2) will also work for an Ar/CO$_{2}$ mixture, which can be selected
418 by \\{\tt AliTRDSimParam::SetArgon()}.
420 \subsection{Photons from transition radiation}
422 Additionally to the hits from energy loss, also hits from the absorbtion of
423 TR photons are generated. This is done in {\tt AliTRDv1::CreateTRhit()}, which
424 in turn is called by the chosen step manager for electrons and positrons
425 entering the entering the drift volume. The process consists of two steps:
426 first the number and energies of the TR photons have to be determined and then
427 their absorbtion position inside the gas volume has to be calculated. The
428 corresponding procedures, used by {\tt AliTRDv1::CreateTRhit()}, are
429 implemented in {\tt AliTRDsimTR()}. This class contains a parametrization
430 of TR photons generated by a regular foil stack radiator \cite{TRPHOT}. This
431 parametrization has been tuned such that the resulting spectrum matches the
432 one of the fiber radiator that used in reality. Since the TR production
433 depends also on the momentum of the electron, the parameters have been
434 adjusted in several momentum bins. After a TR photon has been generated and put
435 on the particle stack, it is assumed that it follows a straight trajectory
436 whose direction is determined by the momentum vector of the generating electron.
437 Since the emission angle for TR photons is very small ($\sim 1/\gamma$) this
438 is a valid approximation. The absorbtion length, which thus determines the
439 TR hit position, is randomly chosen according to the absorbtion cross sections
440 in the gas mixture. These energy dependent cross sections are also included
441 in {\tt AliTRDsimTR}.
443 \subsection{Track references}
445 The TRD simulation produces track references ({\tt AliTrackReference}) each time
446 a charged particle is entering the drift region and exiting the amplification
447 region. These track references thus provide information on the position where
448 the MC particle was entering and existing the sensitive region of a ROC, as well
449 as on its momentum components at this positions. Also, the index to the MC particle
450 in the kinematic tree is stored so that the full MC history can be retrieved.
452 \section{Digitization}
454 {\it Author: C.~Blume (blume@ikf.uni-frankfurt.de)}
458 The second step in the simulation chain is the translation of the hit information,
459 i.e. position and amount of deposited charge, into the final detector response
460 that can be stored in digits objects ({\tt AliTRDdigits}):
464 {\tt fAmp} & Signal amplitude \\
465 {\tt fId} & Number of the ROC ({\bf DET} number) \\
466 {\tt fIndexInList} & Track index \\
467 {\tt fRow} & Pad row number \\
468 {\tt fColumn} & Pad column number \\
469 {\tt fTime} & Time bin number \\
473 However, in practise {\tt AliTRDdigits} is not used to store the digits
474 information. Instead the data containers described in \ref{DIGITS:containers}
475 are used for this purpose. The digitization process includes as an
476 intermediate step between hit and digits the so-called summable digits, or
479 \mbox{{\bf HITS} $\Longrightarrow$ {\bf SDIGITS} $\Longrightarrow$ {\bf DIGITS}}
481 They sdigits contain the detector signals before discretization and the addition
482 of noise and are used to merge several events into a single one.
484 \subsection{Digitizer}
486 The class {\tt AliTRDdigitizer} contains all the necessary procedures to convert
487 hits into sdigits and subsequently sdigits into digits. The standard sequence to
488 produce sdigits, as would be initiated by {\tt AliSimulation}, is shown here:
492 \begin{picture}(10,9)
493 \put(2.5,8.0){\framebox(5.0,0.8){{\tt MakeDigits()}}}
494 \put(2.5,6.4){\framebox(5.0,0.8){{\tt SortHits()}}}
495 \put(2.5,4.8){\framebox(5.0,0.8){{\tt ConvertHits(det)}}}
496 \put(2.5,3.2){\framebox(5.0,0.8){{\tt ConvertSignals(det)}}}
497 \put(2.5,1.6){\framebox(5.0,0.8){{\tt Signal2SDigits(det)}}}
498 \put(2.5,0.0){\framebox(5.0,0.8){{\tt TRD.SDigits.root}}}
499 \put(5.0,8.0){\vector(0,-1){0.8}}
500 \put(5.0,6.4){\vector(0,-1){0.8}}
501 \put(5.0,4.8){\vector(0,-1){0.8}}
502 \put(5.0,3.2){\vector(0,-1){0.8}}
503 \put(5.0,1.6){\vector(0,-1){0.8}}
504 \put(5.0,1.2){\line(-1,0){4.0}}
505 \put(1.0,1.2){\line(0,1){4.8}}
506 \put(1.0,6.0){\vector(1,0){4.0}}
507 \put(0.2,6.1){{\tt det=0-539}}
511 The first function {\tt SortHits()} sorts the simulated hits according to
512 their {\bf DET} number, so that the digitization procedures can be called
513 for a single ROCs in the following loop. The function {\tt ConvertHits()}
514 does the conversion of the hit information into a detector signal. In this
515 procedure each electron of a given hit is in principle followed along its
516 path from the position of the primary ionization towards the anode wire.
517 The position of this electron can be modified by diffusion in the gas
518 ({\tt AliTRDdigitizer::Diffusion()}), ExB effect ({\tt AliTRDdigitizer::ExB()}),
519 and absorbtion ({\tt AliTRDdigitizer::Absorbtion()}, off per default).
520 The drift time of the electrons is also modified according to their distance
521 to the corresponding anode wire position ({\tt AliTRDdigitizer::TimeStruct()}),
522 since the electric field lines are not uniform inside the amplification region.
523 This results in a non-isochronity of the drift time, which has been
524 simulated with the GARFIELD program and the tabulated results of this
525 simulation are used in the digitizing process to adjust the drift times
526 accordingly. Once the position and the drift time of the electron at the
527 anode wire plane are know, the signal induced on the pads can be calculated.
528 This involves three effects: the pad response, which distributes the charge
529 on several pads ({\tt AliTRDdigitizer::PadResponse()}), the time reponse due
530 to the slow ion drift and the PASA response function, which distributes the
531 charge onto the following time bins, ({\tt AliTRDdigitizer::TimeResponse()}),
532 and the cross talk between neighbouring pads ({\tt AliTRDdigitizer::CrossTalk()}).
533 At the end of this procedure, the charge seen by each pad in each time bin
534 is available. Also, the indices of maximally three MC particles in the kine
535 tree contributing to a given pad signal are stored, so that in a later
536 analysis it can be tested which particle generated what signal.
537 As a next step the signals could either directly be converted into {\bf DIGITS},
538 or, which is the default procedure, they are stored as {\bf SDIGITIS}.
539 The correponding functions ({\tt AliTRDdigitizer::Signal2SDigits()} and
540 {\tt AliTRDdigitizer::Signal2ADC()}) are called from
541 {\tt AliTRDdigitizer::ConvertSignals()}, depending on the configuation.
542 The function {\tt AliTRDdigitizer::Signal2SDigits()} stores the signals as
543 {\bf SDIGITS} in data structures of the type {\tt AliTRDarraySignal} (see
544 section \ref{DIGITS:containers}).
546 If desired, the {\bf SDIGITS} can now be added to the {\bf SDIGITS} from other
547 simulated events, e.g. in order to embed a specific signal into a background
548 event ({\tt AliTRDdigitizer::MergeSDigits()}). After this optional step, the
549 {\bf SDIGITS} are finally being converted into {\bf DIGITS}. This process is
550 steered by the function ({\tt AliTRDdigitizer::ConvertSDigits()}).
554 \begin{picture}(10,9)
555 \put(2.5,8.0){\framebox(5.0,0.8){{\tt Exec()}}}
556 \put(2.5,6.4){\framebox(5.0,0.8){{\tt SDigits2Digits()}}}
557 \put(2.5,4.8){\framebox(5.0,0.8){{\tt MergeSDigits()}}}
558 \put(2.5,3.2){\framebox(5.0,0.8){{\tt ConvertSDigits()}}}
559 \put(2.5,1.6){\framebox(5.0,0.8){{\tt Signal2ADC(det)}}}
560 \put(2.5,0.0){\framebox(5.0,0.8){{\tt TRD.Digits.root}}}
561 \put(5.0,8.0){\vector(0,-1){0.8}}
562 \put(5.0,6.4){\vector(0,-1){0.8}}
563 \put(5.0,4.8){\vector(0,-1){0.8}}
564 \put(5.0,3.2){\vector(0,-1){0.8}}
565 \put(5.0,1.6){\vector(0,-1){0.8}}
566 \put(5.0,1.2){\line(-1,0){4.0}}
567 \put(1.0,1.2){\line(0,1){1.6}}
568 \put(1.0,2.8){\vector(1,0){4.0}}
569 \put(0.2,2.9){{\tt det=0-539}}
573 The essential step in the final {\bf SDIGITS} $\Longrightarrow$ {\bf DIGITS}
574 conversion is performed by the function {\tt AliTRDdigitizer::Signal2ADC()}.
575 Here pad signals, that are stored as floats, are finally translated into
576 integer ADC values. This conversion involves a number of parameters: the pad
577 coupling and time coupling factors, the gain of the PASA and of the
578 amplification at the anode wire, and the input range and baseline of the ADCs.
579 The coupling factors take into account that only a fraction of the incoming
580 signal is sampled in the digitization process. At this point also the relative
581 gain factors derived from the calibration procedures for a given dataset will
582 be used to distort the simulated data correspondingly. The noise is generated
583 according to a Gaussian distribution of a given width and added to the output.
584 Finally, the converted signals are discretized into the ADC values of the
585 defined resolution. At this stage also the zero suppression mechanism is applied
586 to the simulated ADC values ({\tt AliTRDdigitizer::ZS()}), in order to reduce
587 the output volume (see section \ref{DIGITS:zs}). These {\bf DIGITS} can then
588 serve as input to the raw data simulation (see section \ref{RAWSIM}).
590 \subsection{Simulation parameter}
592 The parameters that are needed to configure the digitization, are either
593 read from the OCDB (e.g. calibration gain factors) or are taken from the
594 parameter class {\tt AliTRDSimParam}. This class contains the default values
595 of these parameters, but it can be configured in order to test different
596 scenarios. The following table lists the available parameters:
600 Parameter & Description & Default value \\ \hline
601 {\tt fGasGain} & Gas gain at the anode wire & 4000 \\
602 {\tt fNoise} & Noise of the chamber readout & 1250 \\
603 {\tt fChipGain} & Gain of the PASA & 12.4 \\
604 {\tt fADCoutRange} & ADC output range (number of ADC channels) & 1023 (10bit) \\
605 {\tt fADCinRange} & ADC input range (input charge) & 2000 (2V) \\
606 {\tt fADCbaseline} & ADC intrinsic baseline in ADC channels & 0 \\
607 {\tt fElAttachProb} & Probability for electron attachment per meter & 0 \\
608 {\tt fPadCoupling} & Pad coupling factor & 0.46 \\
609 {\tt fTimeCoupling} & Time coupling factor & 0.4 \\ \hline
610 {\tt fDiffusionOn} & Switch for diffusion & kTRUE \\
611 {\tt fElAttachOn} & Switch for electron attachment & kFALSE \\
612 {\tt fTRFOn} & Switch for time response & kTRUE \\
613 {\tt fCTOn} & Switch for cross talk & kTRUE \\
614 {\tt fTimeStructOn} & Switch for time structure & kTRUE \\
615 {\tt fPRFOn} & Switch for pad response & kTRUE \\
616 {\tt fGasMixture} & Switch for gas mixture (0: Xe/CO2, 1: Ar/CO2) & 0 \\
620 \subsection{Digits manager}
621 \label{DIGITS:manager}
623 {\it Author: H.~Leon~Vargas (hleon@ikf.uni-frankfurt.de)}
627 The class {\tt AliTRDdigitsManager} handles arrays of data container
628 objects in the form of ROOT's {\tt TObjArray}. Its main functionality
629 is that it provides setters and getters for the information of each chamber.
633 \includegraphics[width=0.85\textwidth]{plots/digitsmanager_containers.eps}
636 Data containers used in the class {\tt AliTRDdigitsManager}.
638 \label{FIG_DIG:manager}
641 \subsection{Data containers}
642 \label{DIGITS:containers}
644 During simulation different kinds of information are created and stored
645 in various data containers depending on their characteristics.
646 These containers were designed with the idea of keeping the code as
647 simple as possible and to ease its maintenance.
648 The simulated signals or sdigits for a given row, column and time bin
649 of each detector, as generated by \\ {\tt AliTRDdigitizer::ConvertHits()},
650 are stored in an object of the class {\tt AliTRDarraySignal}. This
651 class stores the data in an array of floating point values. In this
652 case, the compression method takes as an argument a threshold. All the
653 values equal or below that threshold will be set to zero during
654 compression. The threshold can take any value greater or equal to zero.
655 The sdigits data is used during event merging.
657 In the simulation the information about the particles that generated the
658 hits (index in kine tree) is stored for each detector in an object
659 of the class {\tt AliTRDarrayDictionary}. In this case the information
660 is stored in an array of integer values, which is initialized to -1.
662 In the digitizer, the signals stored in the sdigits are converted
663 afterwards into ADC values and kept in objects of the class
664 {\tt AliTRDarrayADC}. This class saves the ADC values in an array of
665 short values. The ADC range uses only the first 9 bits, bits 10 to 12
666 are used to set the pad status. An uncompressed object of the class
667 {\tt AliTRDarrayADC} should only contain values that are equal or
668 greater than -1, because the compression algorithm of this class uses
669 all the other negative values in the range of the short data type. The
670 value -1 in the data array is used in the simulation to indicate where
671 an ADC value was ``zero suppressed''. This is done in this way so we
672 are be able to discriminate between real zeroes and suppressed zeroes.
673 For the details of the use of pad status refer to the method
674 {\tt AliTRDarrayADC::SetPadStatus()} in the implementation file of this class.
676 \subsection{Zero suppression}
679 {\it Author: H.~Leon~Vargas (hleon@ikf.uni-frankfurt.de)}
683 The zero suppression algorithm was applied at the end of digitization
684 in order to decrease the size of the digits file. The code is implemented
685 in the class {\tt AliTRDmcmSim}. This algorithm is based on testing
686 three conditions on the ADC values of three neighboring pads as seen
687 in Fig.~\ref{FIG_DIG:zs} (for more information see the Data Indication
688 subsection in the TRAP User Manual). The conditions are the following:\\
690 1) Peak center detection:\\
692 ADC-1(t) $\leq$ ADC(t) $\geq$ ADC+1(t)\\
696 ADC-1(t)+ADC(t)+ADC+1(t) $>$ Threshold\\
698 3) Absolute Large Peak:\\
700 ADC(t) $>$ Threshold\\
702 If a given combination of these conditions is not fulfilled, the value ADC(t)
703 is suppressed. The algorithm runs over all ADC values.
707 \includegraphics[width=0.60\textwidth]{plots/zsuppression.eps}
710 Zero suppression code.
715 \section{Raw Data Simulation}
718 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
720 \setcounter{chapter}{2}
721 \setcounter{section}{0}
722 \Chapter{Reconstruction}
723 \thispagestyle{empty}
725 \section{Raw Data Reading}
727 \section{Cluster Finding}
731 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
733 \setcounter{chapter}{3}
734 \setcounter{section}{0}
735 \Chapter{Calibration}
737 {\it Author: R.~Bailhache (rbailhache@ikf.uni-frankfurt.de)}
741 \section{Database Entries}
742 A local database with default parameters can be found in the AliRoot
743 installation directory. The official database is in Alien under the
745 {\tt /alice/data/$\langle$year$\rangle$/$\langle$LHCPeriod$\rangle$/OCDB}.
746 The calibration objects are stored in root files named according to their
747 run validity range, their version and subversion number. For the TRD they
748 are in the subdirectory {\tt \$AliRoot/OCDB/TRD/Calib} and correspond to
749 a perfect TRD detector. The parameters are listed in Tab.\ref{entriesdatabase}.\\
752 \begin{tabular}{|c|c|c|c|c|c|}
753 \hline Parameter & Description & Number of & Data type & Unit & Default value \\
754 & & channels & & & \\ \hline
755 ChamberGainFactor & Mean gas gain & 540 & Float & $-$ & 1.0 \\
756 $ $ & per chamber & & & & \\ \hline
757 LocalGainFactor & Gas gain & 1181952 & UShort & $-$ & 1.0 \\
758 & per pad & 1181952 & UShort & $-$ & 1.0 \\ \hline
759 ChamberVdrift & Mean drift velocity & 540 & Float & cm$/$$\mu$s & 1.5 \\
760 & per chamber & 540 & Float & cm$/$$\mu$s & 1.5 \\ \hline
761 LocalVdrift & Drift velocity & 1181952 & UShort & $-$ & 1.0 \\
762 & per pad & 1181952 & UShort & $-$ & 1.0 \\ \hline
763 ChamberT0 & Minimum timeoffset & 540 & Float & timebin & 0.0 \\
764 & in the chamber & 540 & Float & timebin & 0.0 \\ \hline
765 LocalT0 & Timeoffset & 1181952 & UShort & timebin & 0.0 \\
766 & per pad & & & & \\ \hline
767 PRFWidth & Width of the PRF & 1181952 & UShort & pad width & 0.515 ( layer 0) \\
768 $ $ & per pad & $ $ & $ $ & $ $ & 0.502 ( layer 1) \\
769 $ $ & $ $ & $ $ & $ $ & $ $ & 0.491 ( layer 2) \\
770 $ $ & $ $ & $ $ & $ $ & $ $ & 0.481 ( layer 3) \\
771 $ $ & $ $ & $ $ & $ $ & $ $ & 0.471 ( layer 4) \\
772 $ $ & $ $ & $ $ & $ $ & $ $ & 0.463 ( layer 5) \\ \hline
773 DetNoise & Scale factor & 540 & Float & $-$ & 0.1 \\ \hline
774 PadNoise & Noise & 1181952 & UShort & ADC & 12 \\
775 & per pad & & & counts & \\ \hline
776 PadStatus & Status & 1181952 & char & $-$ & $-$ \\
777 & per pad & & & & \\ \hline
780 \caption{\label{entriesdatabase}Entries in the database}
783 They are related to the calibration of:
785 \item the gas gain: {\tt ChamberGainFactor} and {\tt LocalGainFactor}
786 \item the electron drift velocity: {\tt ChamberVdrift} and {\tt LocalVdrift}
787 \item the timeoffset: {\tt ChamberT0} and {\tt LocalT0}
788 \item the width of the Pad Response Function: {\tt PRFWidth}
789 \item the noise per channel: {\tt DetNoise}, {\tt PadNoise} and {\tt PadStatus}.
791 To save disk space the values per pad are stored in UShort (2 Bytes)
792 format in AliTRDCalROC objects, one per chamber, that are members of
793 a general {\tt AliTRDCalPad} object. The final constants have a
794 numerical precision of 10$^{-4}$. They are computed by
795 multiplication (gain, drift velocity and noise) or addition (timeoffset)
796 of the detector and pad coefficients. From the pad noise level a status
797 is determined for each pad ( masked, bridgedleft, bridgedright, read by
798 the second MCM, not connected). One example macro ({\tt AliTRDCreate.C})
799 to produce a local database is given in the {\tt \$AliRoot/TRD/Macros}
801 During the simulation of the detector response and the reconstruction
802 of the events the parameters are used to compute the amplitude of the
803 signal and its position inside the detector. The database has to be
804 first choosen with the help of the {\tt AliCDBManager}. The parameters
805 are then called by an {\tt AliTRDcalibDB} instance. The macro
806 {\tt \$AliRoot/TRD/Macros/ReadCDD.C} shows how to read a local database
807 and plot the gas gain or drift velocity as function of the detector
808 number or pad number.
810 \section{DAQ Calibration}
811 Calibration procedures are performed online during data-taking on
812 different systems. The principal role of the Data AcQuisition System is
813 to build the events and archive the data to permanent storage tapes. In
814 addition it also provides an efficient access to the data. Nevertheless
815 the complete reconstruction of the events with tracks is not available.
816 Two algorithms are executed on DAQ for the TRD: a pedestal algorithm and
817 an algorithm for the drift velocity and timeoffset. They are implemented
818 as rpm packages, that can be easily built inside AliRoot compiled with
819 the DATE software \cite{DATE}. The outputs of the algorithms are stored
820 in root files and put on the DAQ File Exchange Server (FXS). At the end
821 of the run they are picked up by the so called SHUTTLE and further
822 processed in the Preprocessor to fill finally the OCDB.
824 \centering\mbox{\epsfig{file=plots/baselinenoisedet0run34510ex.eps,width=0.45\textwidth}}
825 \caption{\label{baselinenoisedet0run34510ex}2D histogram of the
826 detector 0 (SM 0, S0, L0) with the ADC value distributions around
827 the baseline (10 ADC counts) for each pad (PEDESTAL run 34510).}
829 \subsection{Pedestal algorithm}
830 During a pedestal run empty events without zero suppression are taken
831 with the TRD alone and a random trigger. They are used to determine
832 the noise in ADC counts of each pad. The algorithm can be found in the
833 {\tt TRDPEDESTALda.cxx} file of the AliRoot TRD directory. It is
834 executed on the Local Data Concentrators (LDCs), which are part of the
835 dataflow and gives access to sub-events. The TRD has three LDCs
836 corresponding to the following blocks of supermodules (SMs):
842 Three algorithms are therefore executed in parallel during a PEDESTAL
843 run for a full installed TRD. After about 100 events, the data-taking
844 stops automatically and a 2D histogram is filled for each chamber with
845 the ADC amplitude distributions around the baseline for each pad. Such
846 a histogram is shown in Fig.\ref{baselinenoisedet0run34510ex} for
847 chamber 0 (SM 0 Stack 0 Layer 0).
849 \centering\mbox{\epsfig{file=plots/run38125sm0nounfold.eps,width=0.88\textwidth,height=0.55\textwidth}}
850 \caption{\label{run38125sm0nounfold}Noise in the six planes of
851 SM 0 (PEDESTAL run 38125). The five stacks in each layer are in
852 the {\it{z}} direction.}
854 The chambers should be so configured that the data is without zero
855 suppression otherwise an error message appears on the DAQ online
856 Logbook. The container class is called {\tt AliTRDCalibPadStatus}
857 and allows to further fit the distributions with a Gaussian to
858 determine the baseline and noise of each pad. The function is called
859 {\tt AliTRDCalibPadStatus::AnalyseHisto()}. In
860 Fig.\ref{run38125sm0nounfold} the noise in SM 0 is plotted for the
861 PEDESTAL run 38125. It shows stripe patterns of higher noise in the
862 $z$-direction (beam direction) correlated to the static pad capacitance
863 of the pad plane. The noise distributions has to be first corrected
864 for the expected noise variations induced by the pad capacitance
865 before a status can be given to each pad. This is not done on the DAQ
866 but just before storing the parameters inside the Offline Condition
867 Database (OCDB) in the Preprocessor.
869 \subsection{Drift velocity and timeoffset algorithm}
870 The drift velocity and timeoffset are calibrated with physics events,
871 $pp$ or $PbPb$ collisions. The algorithm is called
872 {\tt TRDVDRIFTda.cxx} and can be found in the AliRoot TRD directory.
873 It is executed on a dedicated monitoring server, which is not part
874 of the dataflow and gives access to full events of the TRD. The
875 physics events are used to fill continuously during data-taking an
876 average pulse height for each detector. They are stored in a
877 {\tt TProfile2D}, which is a member of a { \tt AliTRDCalibraFillHisto}
878 object. The {\tt TProfile2D} is written at the end of the run in a
879 root file put on the DAQ FXS.\\
881 \centering\mbox{\epsfig{file=plots/referenceph2d.eps,width=0.6\textwidth,,height=0.5\textwidth}}
882 \caption{\label{referenceph2d}2D histogram containing the average
883 pulse height distributions of each calibration group (here detector),
884 produced with decalibrated simulated $pp$ events.}
887 Fig.\ref{referenceph2d} shows an output {\tt TProfile2D} obtained
888 from simulated decalibrated $pp$ collisions at 14\,TeV. The first
889 peak in time corresponds to the amplification region, where the
890 contributions of ionization electrons, which come from both sides
891 of the anode wire plane, are overlapping. The flat plateau results
892 from the electrons in the drift region. The tail is caused by the
893 Time Response Function. From this average signal as function of time
894 the drift velocity and timeoffset can be extracted by fit procedures.
895 This last step is performed in the Preprocessor.\\
896 Since no tracking is available on DAQ, a simple tracklet finder is
897 used. It was optimized for a low charged particle multiplicity
898 environment. The algorithm looks for a maximum of the signal
899 amplitudes in the chamber after integration over all timebins. The
900 average pulse height is then filled for a spot of two pad rows
901 ($z$ direction) and four pad columns ($r\phi$ direction) around the
902 maximum. Further details can be found in the function
903 {\tt AliTRDCalibraFillHisto::ProcessEventDAQ}.
905 \section{HLT Calibration}
906 The High Level Trigger has the big advantage to provide an online
907 reconstruction of the events. The idea is then to run the calibration
908 procedures in a transparent way, independent whether online or
909 offline. The same function
910 \\{\tt AliTRDCalibraFillHisto::UpdateHistogramsV1(AliTRDtrackV1 *t)}
911 is used to fill the $dE/dx$ distributions (gain), the average pulse
912 height (drift velocity and timeoffset) and the Pad Response Function
913 for each detector in respectively one {\tt TH2I} and two
914 {\tt TProfile2Ds}. The calibration is nevertheless done per chamber,
915 whereas by integrating statistics it will be possible to get the gain,
916 drift velocity and timeoffset distributions inside the chambers offline.
917 Therefore the class {\tt AliTRDCalibraFillHisto} contains a flag
918 ({\tt fIsHLT}) to avoid extra calculations not needed at the detector
921 \centering\mbox{\epsfig{file=plots/referencech2d.eps,width=0.55\textwidth,,height=0.45\textwidth}}
922 \caption{\label{referencech2d}A 2D histogram containing the
923 $dE$$/$$dx$ distributions of each detector. These were produced
924 with decalibrated simulated $pp$ events.}
927 Fig.\ref{referencech2d} shows one example of a {\tt TH2I} histogram,
928 where the $dE/dx$ distributions of each detector is stored for $pp$
929 collisions at 14\,TeV. No minimal $p_{T}$ cut was applied on the
930 TRD tracks. Assuming that the charged particles are uniformy
931 distributed over the TRD chambers, the position of the Most Probable
932 Value of the $dE/dx$ distribution is used to calibrate the gain.\\
933 At the beginning of each run, a local copy of the OCDB is updated
934 on the HLT cluster: the HCDB (HLT Condition Database). The last set
935 of calibration objects are used to reconstruct the events. The gain
936 correction preformed during the tracking has to be taken into account
937 when filling the $dE/dx$ distributions. That is why the calibration
938 algorithm has to know which database was used during the
939 reconstruction. The TRD HLT code can be found in the {\tt HLT/TRD}
940 subdirectory of the AliRoot installation. The calibration is
941 implemented as an {\tt AliHLTTRDCalibrationComponent}, whose members
942 are an {\tt AliCDBManager} together with the path for the current
943 database used, and an {\tt AliTRDCalibraFillHisto} object. The main
946 \item {\tt AliHLTCalibrationComponent::InitCalibration}, where the
947 {\tt TH2I} and {\tt TProfile2Ds} are created.
948 \item {\tt AliHLTCalibrationComponent::ProcessCalibration}, where
950 {\tt AliTRDCalibraFillHisto::UpdateHistogramsV1(AliTRDtrackV1 *t)}
951 is called to fill the histograms.
952 \item {\tt AliHLTCalibrationComponent::FormOutput}, which returns
953 a {\tt TObjArray} with the histograms.
955 The histograms are shipped at the end of each run to the HLT File
956 Exchange Server to be picked up by the SHUTTLE and further processed
957 by the Preprocessor, exactly as the data from the calibration on DAQ.
959 \section{Preprocessor}
961 The online systems, like the Detector Control System (DCS), the DAQ
962 and the HLT, are protected from outside by a firewall. A special
963 framework, called the SHUTTLE, has been developped to retrieve offline
964 data in the online systems or store relevant information from the
965 online systems in the OCDB. The SHUTTLE has access to the DCS, DAQ
966 and HLT FXS. At the end of each run the reference data, outputs of
967 the calibration algorithms on DAQ and HLT, are retrieved and further
968 processed to determine the calibration constants (gain, drift velocity,
969 timeoffset and width of the Pad Response Function). The reference
970 data are finally stored in the Grid reference Data Base, whereas the
971 results of the fit procedures are stored in the OCDB.\\
972 The code is contained in the {\tt AliTRDPreprocessor} class. The
973 Process function is executed for the run types: PEDESTAL, STANDALONE,
976 \item The PEDESTAL run are dedicated to the calibration of the noise
977 on DAQ. Only the output of the DAQ pedestal algorithm is retrieved at
978 the SHUTTLE. From the noise and baseline of each pad, a pad status is
979 determined. Disconnected pads are recognizable by a small noise.
980 Bridged pads have the same noise and baseline. The noise and
981 padstatus of the previous pedestal run in the OCDB are taken for half
982 chambers, which were not On. Finally the database entries
983 {\tt DetNoise}, {\tt PadNoise} and {\tt PadStatus} are populated in
984 the OCDB. More informations can be found in the function
985 \\{\tt AliTRDPreprocessor::ExtractPedestals}.
986 \item The STANDALONE runs are used to check the data integrity or the
987 correlated noise. The data are taken with the TRD alone and a random
988 trigger. Only the DCS data are retrieved.
989 \item The DAQ run are test runs for the DAQ people. Only the DCS data
991 \item The PHYSICS run are global runs including more than one detector
992 and different trigger clusters. They are used for the calibration of
993 the gain, driftvelocity and timeoffset, and width of the PRF. Therefore
994 the output of the calibration algorihms running on HLT are retrieved.
995 If the procedure is not successful the output of the
996 driftvelocity$/$timeoffset algorithm on DAQ is also retrieved. The
997 reference data, the histograms, are fitted using an
998 {\tt ALiTRDCalibraFit} instance:
1000 \item {\tt AliTRDCalibraFit::AnalyseCH(const TH2I *ch)} determines
1001 the MPVs of the $dE/dx$ distributions and compares them to a reference
1003 \item {\tt AliTRDCalibraFit::AnalysePH(const TProfile2D *ph)} fits
1004 the average pulse height and determines the position of the amplification
1005 region peak and the end of the drift region for each chamber. Knowing
1006 the length of the drift region one can deduce the drift velocity. The
1007 amplification peak gives also information on the timeoffset.
1008 \item {\tt AliTRDCalibraFit::AnalysePRFMarianFit(const TProfile2D *prf)}
1009 determines the spread of the clusters as function of azimuthal angle of
1010 the track. The minimum gives the width of the PRF.
1012 The results of each fit procedure are stored in a {\tt TObjArray} of
1013 \\{\tt AliTRDCalibraFit::AliTRDFitInfo} objects, one per chamber, which
1014 is a member of the {\tt AliTRDCalibraFit} instance. The functions
1015 {\tt AliTRDCalibratFit::CreateDetObject*} and {\tt ::CreatePadObject*}
1016 allow to create from the {\tt TObjArray} the final calibration objects,
1017 that have to be put in the OCDB.
1019 Tab.\ref{taskruntype} summarizes the tasks executed by the prepocessor
1023 \begin{tabular} {|c|c|c|c|c|}
1024 \hline run type & DCS data points & DCS FXS & DAQ FXS & HLT FXS \\
1025 & temperatures & electronic & calibration DA & calibration DA \\
1026 & voltages, etc $\cdots$ & configuration & noise/($v_{dE}$$/$$t_{0}$)
1027 & $g$/($v_{dE}$$/$$t_{0}$)/$\sigma_{PRF}$ \\
1028 \hline DAQ & yes & yes & no & no \\\hline
1029 \hline PEDESTAL & no & no & yes (noise) & no \\\hline
1030 \hline STANDALONE & yes & yes & no & no \\\hline
1031 \hline PHYSICS & yes & yes & yes ($v_{dE}$$/$$t_{0}$) & yes \\\hline
1033 \caption{\label{taskruntype} Tasks performed by the TRD preprocessor
1034 for every run type.}
1037 The DCS data points are measurements of the currents, voltages,
1038 temperatures and other variables of the chambers as function of time.
1039 They are saved in the DCS Archive DB during the run and made available
1040 at the SHUTTLE by AMANDA.
1042 \section{Offline Calibration}
1043 The offline calibration of the gain, driftvelocity$/$timeoffset and
1044 width of the PRF is meant to improve the first calibration online.
1045 It follows the following steps:
1047 \item Fill reference data (the $dE/dx$ distributions, the average
1048 pulse heights $\cdots$) during the reconstruction of the events offline.
1049 \item Store the reference data in root files in AliEn.
1050 \item Merge the reference data of different runs and$/$or calibration groups.
1051 \item Fit the reference data to extract the calibration constants and
1052 create the calibration objects.
1053 \item Store the calibration objects according to their run validity in
1056 The calibration procedure is not performed per detector anymore but per
1057 pad, at least for the first step, the filling of the reference data.
1058 Depending on the available statics the reference data of different pads
1059 (calibration groups) can be merged together to determine a mean
1060 calibration coefficient over these pads.
1061 \subsection{AliTRDCalibraVector container}
1062 The high granularity of the calibration, with a total number of 1181952
1063 pads, implies that the size of the reference data has to be reduced to
1064 the strict minimum needed.
1067 \begin{tabular} {|c|c|c|}
1068 \hline reference data & Number of & size \\
1069 for & calibration groups & in MB \\\hline
1070 gain & 1181952 & 225 \\\hline
1071 driftvelocity$/$timeoffset & 1181952 & 271 \\\hline
1072 PRF & 131328 & 200 \\\hline
1073 All together & & 696 \\\hline
1075 \caption{\label{sizeofAliTRDCalibraVector} Size of the
1076 {\tt AliTRDCalibraVector} object for a given granularity.}
1080 The {\tt TH2I} and {\tt TProfile2D} objects are not a good option
1081 anymore. Therefore a container class, {\tt AliTRDCalibraVector}, was
1082 developped. The {\tt TH2I} corresponds to an array of UShort (2 Bytes)
1083 for the number of entries in each bin, the {\tt TProfile2D} to an array
1084 of UShort for the number of entries in each bin and two arrays of Float
1085 for the sum of the weights and the sum of the squared weights in each
1086 bin. The mean value and its error are computed per hand in the functions
1087 {\tt AliTRDCalibraVector::UpdateVector*}, where the object is filled
1088 with new data. The size of the {\tt AliTRDCalibraVector} object is
1089 summarized in Tab.\ref{sizeofAliTRDCalibraVector}.\\
1091 \subsection{Additional method to calibrate the drift velocity}
1092 In addition an other method is available for the calibration of the
1093 drift velocity. It is based on the comparison of the slope of the TRD
1094 tracklet in the azimuthal plane $xy$ with the $\phi$ angle of the
1095 global track. It can be shown that the slope $dy/dt$ of a TRD tracklet
1096 depends linearly on its global track parameters,
1097 $\tan(\phi)+(dz/dx)\tan(\beta_{tilt})$ \cite{THESISR}. The slope
1098 parameter is the drift velocity in the electric field direction,
1099 whereas the constant gives the tangent of the Lorentz angle. If the
1100 TRD tracklet crosses two different pads in the $z$ direction (the
1101 beam direction), the relation is not true anymore. Therefore such
1102 tracklets are rejected in the calibration procedure. The reference
1103 data are a {\tt TObjArray} of one {\tt TH2F} histogram for each
1106 \centering\mbox{\epsfig{file=plots/crossrow.eps,width=0.5\textwidth,height=0.45\textwidth}}
1107 \caption{\label{crossrow}The correlation between $dy/dt$ and
1108 $\tan(\phi)+(dz/dx)\tan(\beta_{tilt})$ for the reconstructed track
1109 in one chamber. The tracks crossing at least two pad rows are in
1110 red crosses and those crossing one pad row in blue points.}
1113 Fig.\ref{crossrow} shows one example of such a histogram. They are
1114 filled in the function
1115 \\{\tt AliTRDCalibraFillHisto: :UpdateHistogramsV1(AliTRDtrackV1 *t)},
1116 like the reference data for other calibration constants, if the
1117 flag {\tt fLinearFitterDebugOn} is true.\\
1118 The histograms are stored in the container class,
1119 \\{\tt AliTRDCalibraVdriftLinearFit}, for which a {\tt Merge} and
1120 {\tt Add} function have been implemented. In a second step, the
1121 {\tt AliTRDCalibraVdriftLinearFit} objects can be merged together
1122 for different runs. In a third step, the {\tt TH2F} histograms are
1123 fitted in the function \\{\tt AliTRDCalibraVdriftLinearFit::FillPEArray}.
1124 The result parameters are members of the
1125 {\tt AliTRDCalibraVdriftLinearFit} object, as well as their error
1126 coming from the fit procedures. Finally the
1127 {\tt AliTRDCalibraVdriftLinearFit} object is passed to an
1128 {\tt AliTRDCalibraFit} instance through the function
1129 {\tt AliTRDCalibraFit::AnalyseLinearFitters}, in which the Lorentz
1130 angle is computed from the fit parameters and stored together with
1131 the drift velocity in a {\tt TObjArray}, member of the
1132 {\tt AliTRDCalibraFit} instance. As for the other calibration
1133 constants the functions {\tt AliTRDCalibratFit::CreateDetObject*}
1134 and {\tt ::CreatePadObject*} allows to create the final calibration
1135 objects, that have to be put in the OCDB. Since the Lorentz angle
1136 is not a OCDB entries, it is only used for debugging.
1138 \subsection{The calibration AliAnalysisTask}
1139 The reference data of the calibration are filled in an AliAnalysisTask
1140 during the reconstruction or after the reconstruction. Since it needs
1141 some informations only stored in the AliESDfriends, they have to be
1142 written if one wants to run the calibration. This will be the case
1143 only for TRD track above a given $p_{T}$ since the size of the events
1144 is otherwise to big.
1146 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
1148 \setcounter{chapter}{4}
1149 \setcounter{section}{0}
1151 \thispagestyle{empty}
1155 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
1157 \setcounter{chapter}{5}
1158 \setcounter{section}{0}
1159 \Chapter{Quality Assurance (QA)}
1160 \thispagestyle{empty}
1164 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
1166 \setcounter{chapter}{6}
1167 \setcounter{section}{0}
1168 \Chapter{High Level Trigger (HLT)}
1169 \thispagestyle{empty}
1173 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
1175 \setcounter{chapter}{7}
1176 \setcounter{section}{0}
1177 \Chapter{References}
1178 \thispagestyle{empty}
1180 \begin{thebibliography}{99}
1182 \bibitem{ALIROOT} {\it The ALICE Offline Bible}\\
1183 http://aliceinfo.cern.ch/export/sites/AlicePortal/Offline/galleries/Download/OfflineDownload/ \\
1186 \bibitem{CLEMENS} C.~Adler,
1187 {\it Radiation length of the ALICE TRD}
1189 \bibitem{DAVID} D.~Emschermann,
1190 {\it Numbering Convention for the ALICE TRD Detector.},
1191 http://www.physi.uni-heidelberg.de/\~demscher/alice/numbering/more/TRD\_numbering\_v04.pdf.
1193 \bibitem{TRPHOT} M.~Castellano et al.,
1194 Comp. Phys. Comm. {\bf 55}, 431 (1988),
1195 Comp. Phys. Comm. {\bf 61}, 395 (1990),
1197 \bibitem{DATE} K.~Schossmaier et al.,
1198 {\it The Alice Data Acquisition and Test Environment DATE V5},
1201 \bibitem{THESISR} R.~Bailhache,
1202 {\it Calibration of the ALICE Transition Radiation Detector
1203 and a study of $Z^{0}$ and heavy quark production in $pp$
1204 collisions at the LHC},
1205 PhD thesis, University of Darmstadt (Germany), 2009.
1207 \end{thebibliography}
1209 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
1212 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%