| 65163b68 |
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> |
| 20 | <br> |
| 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 | 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 | aCPVClusterizer, |
| 422 | aPHOSSubTracker) ; |
| 423 | |
| 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 |
| 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 | 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). |
| 465 | */ |
| 466 | |
| 467 | </i>aPhotonFinder->UseDetector("ITS") ; |
| 468 | aPhotonFinder->UseDetector("TPC") ; |
| 469 | aPhotonFinder->UseDetector("PHOS") ; |
| 470 | |
| 471 | for each event do { |
| 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() ; |
| 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. <!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> |
| 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& 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 | © <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> |
git://git.uio.no / u / mrichter / AliRoot.git / blame