1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
2 "http://www.w3.org/TR/REC-html40/loose.dtd">
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">
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.
22 <hr><a NAME="definitions and objectives"></a>
24 Definitions and objectives</h1>
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>.
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:
44 <b>Clusterization</b></dt>
47 We group adjacent crystals (pads) with a signal over a given threshold
48 to form <i>clusters</i></dd>
51 <b>Sub-Tracking</b></dt>
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
59 <b>Identification</b> (Tracking)</dt>
62 Several (at least one) detector sub-tracks are combined and matched with
63 <i>particles</i>.</dd>
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.
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
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
81 <br><!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
85 The clusterization part of the reconstruction can be summarized by the
87 <center><img SRC="usecasereconstruction.gif" ALT="[Reconstruction Use Case]" height=355 width=599></center>
88 So, the basic functionalities we want here are :
91 <b>Storing/Retrieving data</b></dt>
94 We want to <i>read</i> digits from file, and want to be able to <i>write</i>
95 clusters on file,</dd>
98 <b>Clusterizing</b></dt>
101 A separate document will detail the clusterization method(s).</dd>
104 <b>Keeping track of what we did</b></dt>
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>
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
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
126 <dt><strong>Classname:</strong>
127 <dd><em class="classname">Ali</em>
128 <dt><strong>Superclasses :</strong>
130 <dt><strong>Subclasses :</strong>
132 <dt><strong>Responsabilities: </strong>
134 <dt><strong>Collaborators: </strong>
139 <hr class="small-separation">
143 <b>Classname:</b></dt>
146 <i>AliPHOSDigit</i></dd>
149 <b>Superclasses :</b></dt>
155 <b>Subclasses :</b></dt>
158 AliPHOSCrystalDigit, AliPHOSCPVDigit</dd>
161 <b>Responsabilities:</b></dt>
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>
168 <b>Collaborators:</b></dt>
175 <hr class="small-separation">
179 <b>Classname:</b></dt>
182 <i>AliPHOSCluster</i></dd>
185 <b>Superclasses :</b></dt>
191 <b>Subclasses :</b></dt>
194 AliPHOSCrystalCluster, AliPHOSCPVCluster</dd>
197 <b>Responsabilities:</b></dt>
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>
205 <b>Collaborators:</b></dt>
208 AliPHOSDigit, AliPHOSGeometry</dd>
212 <hr class="small-separation">
216 <b>Classname:</b></dt>
219 <i>AliPHOSGeometry</i></dd>
222 <b>Superclasses :</b></dt>
228 <b>Subclasses :</b></dt>
234 <b>Responsabilities:</b></dt>
237 Handles several PHOS Xtal/CPV geometrical characteristics (sizes, positions,
239 <br>This class is a <b>Singleton</b>.
242 <b>Collaborators:</b></dt>
245 AliPHOS*Cluster, AliPHOSClusterizer*</dd>
249 <hr class="small-separation">
253 <b>Classname:</b></dt>
256 <i>AliPHOSClusterizer*</i></dd>
259 <b>Superclasses :</b></dt>
265 <b>Subclasses :</b></dt>
271 <b>Responsabilities:</b></dt>
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>
278 <b>Collaborators:</b></dt>
281 AliPHOS*Digit, AliPHOS*Cluster</dd>
288 <b>Classname:</b></dt>
291 <i>AliParameter</i></dd>
294 <b>Superclasses :</b></dt>
300 <b>Subclasses :</b></dt>
303 (?) probably many of them</dd>
306 <b>Responsabilities:</b></dt>
309 pABC. Keep track of methods used and method parameters used. What should
310 be the basic interface for this ???</dd>
313 <b>Collaborators:</b></dt>
319 <!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
320 <hr><a NAME="sub_tracking"></a>
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
328 <center><img SRC="aliphossubtracking.gif" ALT="[SubTracking Class Diagram]"></center>
333 <b>Classname:</b></dt>
336 <i>AliPHOSSubTrack</i></dd>
339 <b>Superclasses :</b></dt>
345 <b>Subclasses :</b></dt>
351 <b>Responsabilities:</b></dt>
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>
358 <b>Collaborators:</b></dt>
361 AliPHOSSubTracker*</dd>
365 <hr class="small-separation">
369 <b>Classname:</b></dt>
372 <i>AliPHOSSubTracker*</i></dd>
375 <b>Superclasses :</b></dt>
381 <b>Subclasses :</b></dt>
387 <b>Responsabilities:</b></dt>
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>
394 <b>Collaborators:</b></dt>
397 AliPHOSCluster, AliPHOSSubTrack</dd>
400 <!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
401 <hr><a NAME="particle_identification"></a>
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
407 <pre class="code">for each detector in ALICE do {
408 detector->Reconstruction() ;
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>
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 aCPVClusterizer,
422 aPHOSSubTracker) ;
424 <i>// Create PHOS detector and associate
425 a reconstructioner with it
426 </i>AliPHOS* phos = new AliPHOSVxx("PHOS",
427 "PHOS Version xx",
428 &;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
436 <p>If we now turn to the particle identification problem, two cases must
440 <b>Standalone PHOS</b></dt>
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>
447 <b>PHOS + other ALICE sub-systems</b></dt>
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>
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(...) ;
460 <i>/* the UseDetector("ADET") method should "connect"
461 the ParticleHunter with the ADET subtrack branch so it can access
462 other detectors subtracks.
463 We assume that a subtrack knows in which detector she is, so we
464 can recover this information later (e.g. in the FindParticles method).
467 </i>aPhotonFinder->UseDetector("ITS") ;
468 aPhotonFinder->UseDetector("TPC") ;
469 aPhotonFinder->UseDetector("PHOS") ;
472 aPhotonFinder->FetchSubTracks(event) ;
473 <i>/* The FindParticle method can now plays
474 with all the ITS,TPC and PHOS subtracks... */
475 </i> aPhotonFinder->FindParticles() ;
478 <center><img SRC="classes_identification.gif" ALT="[Identification Class Diagram]" height=279 width=480></center>
483 <b>Classname:</b></dt>
486 <i>AliPHOSReconstructioner*</i></dd>
489 <b>Superclasses :</b></dt>
492 AliReconstructioner (?)</dd>
495 <b>Subclasses :</b></dt>
501 <b>Responsabilities:</b></dt>
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>
509 <b>Collaborators:</b></dt>
512 AliPHOSClusterizer, AliPHOSSubTracker, AliPHOS</dd>
519 <b>Classname:</b></dt>
522 <i>AliParticleHunter</i></dd>
525 <b>Superclasses :</b></dt>
531 <b>Subclasses :</b></dt>
537 <b>Responsabilities:</b></dt>
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>
545 <b>Collaborators:</b></dt>
548 AliSubTrack, AliParticle, AliDetector</dd>
551 <!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
554 Disk Storage Structure</h1>
555 We present in this section how the PHOS reconstructed data will be arranged
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
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>
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
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.
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. <!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
587 <hr><a NAME="parameters"></a>
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& 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><!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
621 To perform the PHOS reconstruction, we need/propose the following classes
628 <b>Ali(PHOS)Cluster</b></dt>
631 (pABC) Storage class for groups of digits (per detector)</dd>
634 <b>Ali(PHOS)SubTrack</b></dt>
637 (pABC) Storage class for groups of clusters (per detector)</dd>
640 <b>Ali(PHOS)Reconstructioner</b></dt>
643 (pABC) Control class for clusterization and subtracking.</dd>
646 <b>AliParticleHunter</b></dt>
649 (pABC) Working class to associate different subtracks into particles.</dd>
652 <b>AliParticle</b></dt>
655 (pABC?) Storage class for particles.</dd>
658 <b>AliParameter</b></dt>
661 (pABC!) Entropy minimizing class. Keeps track of methods/parameters used
662 to make clusters, subtracks and particles.</dd>
665 <b>Ali(Digit,Cluster,SubTrack)Identifier</b></dt>
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>
674 AliRoot classes impacted</h2>
681 Add Reconstruction method, which would delegate to the corresponding Reconstruction
682 methods of the different detectors.</dd>
685 <b>AliDetector</b></dt>
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>
694 <address class="left">
695 © <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>
698 <address class="right">
699 <!-- Created: Tue Oct 26 19:52:56 CEST 1999 -->
701 Last modified: Wed Dec 1 18:54:10 CET 1999
702 <!-- hhmts end --></address>
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>
git://git.uio.no / u / mrichter / AliRoot.git / blob