c5be3b6e2408f95cc423b974c380dacac70f6b4f
[u/mrichter/AliRoot.git] / PHOS / PHOS-HTML / reconstruction.html
1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
2                "http://www.w3.org/TR/REC-html40/loose.dtd">
3 <html>
4 <head>
5    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
6    <meta name="GENERATOR" content="Mozilla/4.51 [en] (X11; I; Linux 2.2.5-15 i686) [Netscape]">
7    <title>PHOS Reconstruction Proposal</title>
8 <link REL="stylesheet" href="http://www-subatech.in2p3.fr/~photons/gps_alice.css" type="text/css">
9 </head>
10 <body>
11
12
13 <h1>
14 PHOS Reconstruction Proposal</h1>
15 At the Offline meeting held during the September ALICE week, it was decided
16 to make a major step in the design of the overall reconstruction framework.
17 This document presents the results of our early brainstorming about the
18 design of the reconstruction of the Photon Spectrometer PHOS.
19 <br>&nbsp;
20 <br>&nbsp;
21 <p>
22 <hr><a NAME="definitions and objectives"></a>
23 <h1>
24 Definitions and objectives</h1>
25
26 <h2>
27 What is PHOS ?</h2>
28 We hereby consider that the PHOS detector is the <i>union</i> of two sub-detectors
29 : the lead tungstate crystals and the Charged Particle Veto (CPV). Both
30 sub-detectors are physically organized in <i>modules</i>. A separate document
31 is dedicated to the <a href="PHOS_Proposal.html">PHOS geometry</a>.
32 <h2>
33 What is the reconstruction ?</h2>
34 Using the AliRoot framework, we would like to be able to compare several
35 CPV alternatives. The main focus will be on the photon identification capabilities
36 of PHOS, i.e. on the hadron rejection capabilities.
37 <p>This document describes the reconstruction software we intend to write/have
38 written to achieve this objective. <i>Reconstruction</i> is meant as the
39 full path from the PHOS digits to physical particles. The PHOS digits are
40 obtained by the simulation part of AliRoot.
41 <p>The PHOS reconstruction can be divided in three passes:
42 <dl>
43 <dt>
44 <b>Clusterization</b></dt>
45
46 <dd>
47 We group adjacent crystals (pads) with a signal over a given threshold
48 to form <i>clusters</i></dd>
49
50 <dt>
51 <b>Sub-Tracking</b></dt>
52
53 <dd>
54 Crystals and CPV clusters are associated to form PHOS <i>sub-tracks</i>.
55 Loosely speaking, a PHOS sub-track is just a crystal cluster with an information
56 on its charge.</dd>
57
58 <dt>
59 <b>Identification</b> (Tracking)</dt>
60
61 <dd>
62 Several (at least one) detector sub-tracks are combined and matched with
63 <i>particles</i>.</dd>
64 </dl>
65 The two first passes are detector specific, i.e. do not require any information
66 about other detectors. The last part may (and probably will) depend on
67 other detector reconstructions.
68
69 <p class="right">The key point in the following presented design is that
70 we want to be able to experiment several alternatives in each of the three
71 passes.
72 <h2>
73 Generalization</h2>
74 We often tried to generalized our design 'one step up', i.e. up to the
75 AliRoot framework itself, by defining pABC (pure Abstract Base Classes)
76 which we derive from. This is by no mean of way of saying that this is
77 the way to go. It's just a proposal, i.e. <i>a call for discussion</i>.
78 Also, we tried to make an effort on the class names, but you might find
79 our names strange or badly chosen. If this is the case, please <a href="mailto:aphecetc@in2p3.fr">tell
80 us</a> !
81 <br><!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
82 <hr>
83 <h1>
84 Clusterization</h1>
85 The clusterization part of the reconstruction can be summarized by the
86 following Use Case :
87 <center><img SRC="usecasereconstruction.gif" ALT="[Reconstruction Use Case]" height=355 width=599></center>
88 So, the basic functionalities we want here are :
89 <dl>
90 <dt>
91 <b>Storing/Retrieving data</b></dt>
92
93 <dd>
94 We want to <i>read</i> digits from file, and want to be able to <i>write</i>
95 clusters on file,</dd>
96
97 <dt>
98 <b>Clusterizing</b></dt>
99
100 <dd>
101 A separate document will detail the clusterization method(s).</dd>
102
103 <dt>
104 <b>Keeping track of what we did</b></dt>
105
106 <dd>
107 We would like to be able afterwards to answer questions like "I have a
108 cluster in hand, with which method has it been constructed ? With which
109 method parameters ?".</dd>
110 </dl>
111 We would like to insist on the last point. It is far more general than
112 a particular PHOS issue, and must be addressed in some way by the AliRoot
113 framework itself.
114 <p>The following class diagram outlines the clusterization part of the
115 PHOS reconstruction : a Clusterizer object groups some Digits into Clusters.
116 <center><img SRC="aliphosclusterization.gif" ALT="[Clusterization Class Diagram]" ></center>
117 The key point here is the possibility to actually change of clusterization
118 method (Clusterizer class) at runtime. The idea is to use the <a href="http://hillside.net/patterns/">Strategy
119 Design Pattern</a> (see <a href="#particle_identification">Particle Identification</a>
120 for a class diagram).
121 <p>The following tables presents a trial CRC study of the PHOS classes
122 related to the clusterization that lead to the above class diagram.
123 <br><!-- crc template 
124 <div class="crc">
125 <dl>
126 <dt><strong>Classname:</strong>
127 <dd><em class="classname">Ali</em>
128 <dt><strong>Superclasses :</strong>
129 <dd>Ali
130 <dt><strong>Subclasses :</strong>
131 <dd>Ali
132 <dt><strong>Responsabilities: </strong>
133 <dd>
134 <dt><strong>Collaborators: </strong>
135 <dd>Ali
136 </dl>
137 </div>
138 -->
139 <hr class="small-separation">
140 <div class="crc">
141 <dl>
142 <dt>
143 <b>Classname:</b></dt>
144
145 <dd>
146 <i>AliPHOSDigit</i></dd>
147
148 <dt>
149 <b>Superclasses :</b></dt>
150
151 <dd>
152 AliDigit</dd>
153
154 <dt>
155 <b>Subclasses :</b></dt>
156
157 <dd>
158 AliPHOSCrystalDigit, AliPHOSCPVDigit</dd>
159
160 <dt>
161 <b>Responsabilities:</b></dt>
162
163 <dd>
164 Base class for the storage of PHOS digits. Must identify digits (module,row,column)
165 and give access to the corresponding signal (energy).
166 <br>It can be added to an AliPHOSCluster.</dd>
167 <dt>
168 <b>Collaborators:</b></dt>
169
170 <dd>
171 AliPHOSCluster</dd>
172 </dl>
173 </div>
174
175 <hr class="small-separation">
176 <div class="crc">
177 <dl>
178 <dt>
179 <b>Classname:</b></dt>
180
181 <dd>
182 <i>AliPHOSCluster</i></dd>
183
184 <dt>
185 <b>Superclasses :</b></dt>
186
187 <dd>
188 AliCluster (?)</dd>
189
190 <dt>
191 <b>Subclasses :</b></dt>
192
193 <dd>
194 AliPHOSCrystalCluster, AliPHOSCPVCluster</dd>
195
196 <dt>
197 <b>Responsabilities:</b></dt>
198
199 <dd>
200 Base class for PHOS Xtal/CPV clusters. A cluster must know its module,
201 its spatial position, must be able to add digits to itself and to give
202 access to (/iterates on) its digits.</dd>
203
204 <dt>
205 <b>Collaborators:</b></dt>
206
207 <dd>
208 AliPHOSDigit, AliPHOSGeometry</dd>
209 </dl>
210 </div>
211
212 <hr class="small-separation">
213 <div class="crc">
214 <dl>
215 <dt>
216 <b>Classname:</b></dt>
217
218 <dd>
219 <i>AliPHOSGeometry</i></dd>
220
221 <dt>
222 <b>Superclasses :</b></dt>
223
224 <dd>
225 none</dd>
226
227 <dt>
228 <b>Subclasses :</b></dt>
229
230 <dd>
231 none</dd>
232
233 <dt>
234 <b>Responsabilities:</b></dt>
235
236 <dd>
237 Handles several PHOS Xtal/CPV geometrical characteristics (sizes, positions,
238 etc...).
239 <br>This class is a <b>Singleton</b>.
240 </dd>
241 <dt>
242 <b>Collaborators:</b></dt>
243
244 <dd>
245 AliPHOS*Cluster, AliPHOSClusterizer*</dd>
246 </dl>
247 </div>
248
249 <hr class="small-separation">
250 <div class="crc">
251 <dl>
252 <dt>
253 <b>Classname:</b></dt>
254
255 <dd>
256 <i>AliPHOSClusterizer*</i></dd>
257
258 <dt>
259 <b>Superclasses :</b></dt>
260
261 <dd>
262 AliClusterizer</dd>
263
264 <dt>
265 <b>Subclasses :</b></dt>
266
267 <dd>
268 none</dd>
269
270 <dt>
271 <b>Responsabilities:</b></dt>
272
273 <dd>
274 Concrete class(es) which implements the makeClusters method. From a list
275 of Ali(PHOS)Digit, this method must compute a list of Ali(PHOS)Cluster.</dd>
276
277 <dt>
278 <b>Collaborators:</b></dt>
279
280 <dd>
281 AliPHOS*Digit, AliPHOS*Cluster</dd>
282 </dl>
283 </div>
284
285 <div class="crc">
286 <dl>
287 <dt>
288 <b>Classname:</b></dt>
289
290 <dd>
291 <i>AliParameter</i></dd>
292
293 <dt>
294 <b>Superclasses :</b></dt>
295
296 <dd>
297 none</dd>
298
299 <dt>
300 <b>Subclasses :</b></dt>
301
302 <dd>
303 (?) probably many of them</dd>
304
305 <dt>
306 <b>Responsabilities:</b></dt>
307
308 <dd>
309 pABC. Keep track of methods used and method parameters used. What should
310 be the basic interface for this ???</dd>
311
312 <dt>
313 <b>Collaborators:</b></dt>
314
315 <dd>
316 Many classes...</dd>
317 </dl>
318 </div>
319 <!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
320 <hr><a NAME="sub_tracking"></a>
321 <h1>
322 Sub-Tracking</h1>
323 Once we have crystal and CPV clusters, we must associate them to make what
324 we would like to call SubTracks. Doing sub-tracks from clusters is, from
325 the design point of view, much like going from digits to clusters. We should
326 be able to easily change the class which actually do the sub-tracking job
327 :
328 <center><img SRC="aliphossubtracking.gif" ALT="[SubTracking Class Diagram]"></center>
329
330 <div class="crc">
331 <dl>
332 <dt>
333 <b>Classname:</b></dt>
334
335 <dd>
336 <i>AliPHOSSubTrack</i></dd>
337
338 <dt>
339 <b>Superclasses :</b></dt>
340
341 <dd>
342 AliSubTrack (?)</dd>
343
344 <dt>
345 <b>Subclasses :</b></dt>
346
347 <dd>
348 none</dd>
349
350 <dt>
351 <b>Responsabilities:</b></dt>
352
353 <dd>
354 Concrete storage class for a PHOS subtrack. It must be able to give access
355 to its clusters, and to identify itself as being part of PHOS.</dd>
356
357 <dt>
358 <b>Collaborators:</b></dt>
359
360 <dd>
361 AliPHOSSubTracker*</dd>
362 </dl>
363 </div>
364
365 <hr class="small-separation">
366 <div class="crc">
367 <dl>
368 <dt>
369 <b>Classname:</b></dt>
370
371 <dd>
372 <i>AliPHOSSubTracker*</i></dd>
373
374 <dt>
375 <b>Superclasses :</b></dt>
376
377 <dd>
378 AliSubTracker</dd>
379
380 <dt>
381 <b>Subclasses :</b></dt>
382
383 <dd>
384 none</dd>
385
386 <dt>
387 <b>Responsabilities:</b></dt>
388
389 <dd>
390 Concrete class(es) which implements the makeSubTracks method. From a list
391 of Ali(PHOS)Cluster, this method must compute a list of Ali(PHOS)SubTrack.</dd>
392
393 <dt>
394 <b>Collaborators:</b></dt>
395
396 <dd>
397 AliPHOSCluster, AliPHOSSubTrack</dd>
398 </dl>
399 </div>
400 <!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
401 <hr><a NAME="particle_identification"></a>
402 <h1>
403 Particle Identification</h1>
404 Clusterization and subtracking are two activities that are <i>detector-driven</i>.
405 We can indeed imagine that the full ALICE reconstruction could be (pseudo-)coded
406 in AliRoot like :
407 <pre class="code">for each detector in ALICE do {
408 &nbsp; detector->Reconstruction() ;
409 }</pre>
410 assuming that each detector provides a Reconstruction method, and that
411 there's a way to parametrize each detector's behavior. The latter could
412 be done in the initialization phase of AliRoot, e.g. in the <tt>Config.C</tt>
413 file :
414 <pre class="code"><i>// Create PHOS clusterizers
415 </i>AliPHOSCrystalClusterizerV1 aXtalClusterizer(...) ;
416 AliPHOSCPVClusterizerV3 aCPVClusterizer(...) ;
417 <i>// Create PHOS SubTracker
418 </i>AliPHOSSubTrackerV0 aPHOSSubTracker(...) ;
419 <i>// Create a PHOS Reconstructioner
420 </i>AliPHOSReconstructioner aPHOSReconstructioner(aXtalClusterizer,
421 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; aCPVClusterizer,
422 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; aPHOSSubTracker) ;
423
424 <i>// Create PHOS detector and associate
425 &nbsp;a reconstructioner with it
426 </i>AliPHOS* phos = new AliPHOSVxx("PHOS",
427 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "PHOS Version xx",
428 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &amp;;aPHOSReconstructioner) ;</pre>
429 In the above code, the clusterization strategies (for Xtals and CPV) and
430 the sub-tracking strategy are managed by a control class AliPHOSReconstrutioner
431 which would derive from a pABC AliReconstructioner.
432 <center><img SRC="aliphosreconstructioner.gif" ALT="[Reconstruction Class Diagram]" height=312 width=484></center>
433 The <tt>detector->Reconstruction()</tt> method would then only delegate
434 its job to the selected Reconstructioner (aPHOSReconstructioner in the
435 above example).
436 <p>If we now turn to the particle identification problem, two cases must
437 be considered :
438 <dl>
439 <dt>
440 <b>Standalone PHOS</b></dt>
441
442 <dd>
443 The particle identification is just a refinement (e.g. computation of some
444 new values to cut upon) of subtracking. We only need to access PHOS SubTracks.</dd>
445
446 <dt>
447 <b>PHOS + other ALICE sub-systems</b></dt>
448
449 <dd>
450 In this case, we must associate several subtracks, coming from different
451 sub-systems, in order to identify particles. One problem to solve is how
452 to access other sub-systems SubTracks.</dd>
453 </dl>
454 For this stage of the analysis, the AliRoot activity can not be detector-driven
455 anymore. Instead we would like to propose this activity to be <i>particle
456 hunting driven</i>. For example :
457 <pre class="code"><i>// we assume that all detectors have produced their subtracks in the event event_number
458 </i>AliParticleHunter* aPhotonFinder = new AliPhotonFinder(...) ;
459
460 <i>/* the UseDetector("ADET") method should "connect"
461 &nbsp;the ParticleHunter with the ADET subtrack branch so it can access
462 &nbsp;other detectors subtracks.
463 &nbsp;We assume that a subtrack knows in which detector she is, so we
464 &nbsp;can recover this information later (e.g. in the FindParticles method).
465 */
466
467 </i>aPhotonFinder->UseDetector("ITS") ;
468 aPhotonFinder->UseDetector("TPC") ;
469 aPhotonFinder->UseDetector("PHOS") ;
470
471 for each event do {
472 &nbsp; aPhotonFinder->FetchSubTracks(event) ;
473 &nbsp; <i>/* The FindParticle method can now plays
474 &nbsp;&nbsp; with all the ITS,TPC and PHOS subtracks... */
475 </i>&nbsp; aPhotonFinder->FindParticles() ;
476 }</pre>
477
478 <center><img SRC="classes_identification.gif" ALT="[Identification Class Diagram]" height=279 width=480></center>
479
480 <div class="crc">
481 <dl>
482 <dt>
483 <b>Classname:</b></dt>
484
485 <dd>
486 <i>AliPHOSReconstructioner*</i></dd>
487
488 <dt>
489 <b>Superclasses :</b></dt>
490
491 <dd>
492 AliReconstructioner (?)</dd>
493
494 <dt>
495 <b>Subclasses :</b></dt>
496
497 <dd>
498 none</dd>
499
500 <dt>
501 <b>Responsabilities:</b></dt>
502
503 <dd>
504 This class is control class for the clusterizations and the subtracking.
505 It must handles the clusters and subtracks IO. It can be "added" to the
506 AliPHOS detector.</dd>
507
508 <dt>
509 <b>Collaborators:</b></dt>
510
511 <dd>
512 AliPHOSClusterizer, AliPHOSSubTracker, AliPHOS</dd>
513 </dl>
514 </div>
515
516 <div class="crc">
517 <dl>
518 <dt>
519 <b>Classname:</b></dt>
520
521 <dd>
522 <i>AliParticleHunter</i></dd>
523
524 <dt>
525 <b>Superclasses :</b></dt>
526
527 <dd>
528 non</dd>
529
530 <dt>
531 <b>Subclasses :</b></dt>
532
533 <dd>
534 AliPhotonFinder</dd>
535
536 <dt>
537 <b>Responsabilities:</b></dt>
538
539 <dd>
540 Associate a number (1..n) different detector subtracks to identify particles.
541 It must be able to fetch subtracks for a number of different detectors.
542 It handle IO of produced particles.</dd>
543
544 <dt>
545 <b>Collaborators:</b></dt>
546
547 <dd>
548 AliSubTrack, AliParticle, AliDetector</dd>
549 </dl>
550 </div>
551 <!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
552 <hr>
553 <h1>
554 Disk Storage Structure</h1>
555 We present in this section how the PHOS reconstructed data will be arranged
556 on disk.
557 <p>We suppose that there is one TreeR (Reconstruction Tree) per event,
558 and we store different kinds of objects in differents branches, i.e. the
559 <b>PHOSCPVClusters
560 branch</b> contains CPV clusters the <b>PHOSCrystalClusters branch</b>
561 contains Crystal clusters, the <b>PHOSSubTracks branch</b> contains PHOS
562 SubTracks, and the <b>PHOSParameters branch</b> contains several information
563 related to the way Clusters and SubTracks were made. The following figure
564 indicates the inter-relation(s) between those branches and the relation
565 between those branches and the PHOS branch in the Digit Tree.
566 <center><img SRC="TreeR.gif" ALT="[Reconstruction Tree Structure]" height=425 width=483></center>
567
568 <h2>
569 How are the links implemented ?</h2>
570 If we assume that all the above branches are implemented using <a href="http://root.cern.ch/root/html/TClonesArray.html">TClonesArray</a>,
571 we could index things using simple integers refering to positions in the
572 TClonesArray. For example, a cluster will keep track of its digits by recording
573 the list of the digits position in the TClonesArray of the PHOS branch
574 in the digit tree. These positions are of course only valid within a given
575 event.
576 <p>If we want to be less implementation dependant we could probably have
577 classes such as <i>AliDigitIdentifier</i> (which could then be anything
578 we like, e.g. a simple integer wrapper or a set {event_number, index position}).
579 This solution could be more disk-space consuming, but would have the tremendous
580 advantage to isolate "logical" references from implementation.
581 <h2>
582 What should we save ?</h2>
583 At least in the beginning of the analysis, we should be able to perform
584 the reconstruction step by step, i.e. be able to save clusters, subtracks
585 and particles. It would be nice to include a switching mechanism to e.g.
586 disconnect the cluster output if we want to save disk space for instance.&nbsp;<!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
587 <hr><a NAME="parameters"></a>
588 <h1>
589 Keeping the entropy small</h1>
590 We come back to the problem stated in the clusterization section about
591 'keeping track of what we did'. We don't want to loose too much information
592 along our way from the raw data to the particles so we can have some checkpoints.
593 <p>We proposed in the above class diagrams to use a generic <tt>AliParameter</tt>
594 class which could answer question such as 'what was the sub-tracker method
595 and version used to do this sub-track ?' or 'what was the Xtal clustering
596 low threshold ?'. This 'AliParameter' could be accessible through methods
597 like <tt>AliParameter&amp; AliCluster::GetMakerInformation</tt>. That's
598 all nice, but we say nothing about what this AliParameter class is.
599 <p>We could imagine a very simple AliParameter implementation using e.g.
600 (parameter_name, parameter_value) pairs encapsulated in such an AliParameter
601 class. Or, entering fully the Alice Wonderland, we could dream of a much
602 more ambitious generic parameter class, in which the actual storage of
603 the parameters in done using <a href="http://www.w3.org">XML</a> (the W3
604 eXtensible Markup Language). The base AliParameter would then only provide
605 basic interface to code/decode XML tags, and each subsystems would provide
606 DTD to describes their parameters, which would then ressemble 'parameters
607 sheets'. We can imagine DTDs per detector or per domain (geometry, reconstruction,
608 physics analysis...).
609 <br>The strenght of this approach is the use of a (new) <b>standard</b>
610 in which data are represented in structured ASCII files. ASCII files are
611 human readable/produceable, easy to exchange between computers, and many
612 tools already exists, in a wide variety of languages (C/C++, Java, Perl,
613 Python...), to handles XML compliant files.
614 <p>But, well, may be this is only a dream... and too much work for our
615 purposes. Anyway, comments on this idea are welcome ! More information
616 can be found at <a href="http://www.oasis-open.org/cover/">http://www.oasis-open.org/cover/</a>
617 <br><!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
618 <hr>
619 <h1>
620 Summary</h1>
621 To perform the PHOS reconstruction, we need/propose the following classes
622 :
623 <h2>
624 New classes</h2>
625
626 <dl>
627 <dt>
628 <b>Ali(PHOS)Cluster</b></dt>
629
630 <dd>
631 (pABC) Storage class for groups of digits (per detector)</dd>
632
633 <dt>
634 <b>Ali(PHOS)SubTrack</b></dt>
635
636 <dd>
637 (pABC) Storage class for groups of clusters (per detector)</dd>
638
639 <dt>
640 <b>Ali(PHOS)Reconstructioner</b></dt>
641
642 <dd>
643 (pABC) Control class for clusterization and subtracking.</dd>
644
645 <dt>
646 <b>AliParticleHunter</b></dt>
647
648 <dd>
649 (pABC) Working class to associate different subtracks into particles.</dd>
650
651 <dt>
652 <b>AliParticle</b></dt>
653
654 <dd>
655 (pABC?) Storage class for particles.</dd>
656
657 <dt>
658 <b>AliParameter</b></dt>
659
660 <dd>
661 (pABC!) Entropy minimizing class. Keeps track of methods/parameters used
662 to make clusters, subtracks and particles.</dd>
663
664 <dt>
665 <b>Ali(Digit,Cluster,SubTrack)Identifier</b></dt>
666
667 <dd>
668 A simple integer wrapper or a more elaborated way of indexing reconstruction
669 objects, so we can go one step back at every analysis step (e.g. access
670 the list of clusters a subtrack is made of).</dd>
671 </dl>
672
673 <h2>
674 AliRoot classes impacted</h2>
675
676 <dl>
677 <dt>
678 <b>AliRun</b></dt>
679
680 <dd>
681 Add Reconstruction method, which would delegate to the corresponding Reconstruction
682 methods of the different detectors.</dd>
683
684 <dt>
685 <b>AliDetector</b></dt>
686
687 <dd>
688 Add GetSubTracks method (returning a list of subtracks for a given event),
689 and Reconstruction method (which delegates its jobs to an AliReconstructioner
690 object, selectable at runtime).</dd>
691 </dl>
692
693 <hr>
694 <address class="left">
695 &copy; <a href="mailto:aphecetc@in2p3.fr">Groupe Photons Subatech</a> <a href="http://www-subatech.in2p3.fr/~photons/subatech/en_index.shtml">[Go
696 to the GPS Home Page]</a></address>
697
698 <address class="right"> 
699 <!-- Created: Tue Oct 26 19:52:56 CEST 1999 -->
700 <!-- hhmts start -->
701 Last modified: Wed Dec  1 18:54:10 CET 1999
702 <!-- hhmts end --></address>
703
704 <div align=right><a href="http://validator.w3.org/check/referer"><img SRC="vh40.gif" ALT="Valid HTML 4.0!" BORDER=0 height=31 width=88></a><a href="http://jigsaw.w3.org/css-validator"><img SRC="vcss.gif" ALT="Valid CSS!" BORDER=0 height=31 width=88></a></div>
705
706 </body>
707 </html>