[1208] | 1 | <HTML> |
---|
| 2 | <TITLE> |
---|
| 3 | </TITLE> |
---|
| 4 | <!-- Changed by: Katsuya Amako, 21-Sep-1998 --> |
---|
| 5 | <!-- Proof read by: Joe Chuma, 30-Jun-1999 --> |
---|
| 6 | <!-- Changed by: Dennis Wright, 29-Nov-2001 --> |
---|
| 7 | <!-- Changed by: Makoto Asai, 30-Nov-2005 --> |
---|
| 8 | |
---|
| 9 | <BODY> |
---|
| 10 | <TABLE WIDTH="100%"><TR> |
---|
| 11 | <TD> |
---|
| 12 | |
---|
| 13 | |
---|
| 14 | <A HREF="index.html"> |
---|
| 15 | <IMG SRC="../../../../resources/html/IconsGIF/Contents.gif" ALT="Contents"></A> |
---|
| 16 | <A HREF="electroMagneticField.html"> |
---|
| 17 | <IMG SRC="../../../../resources/html/IconsGIF/Previous.gif" ALT="Previous"></A> |
---|
| 18 | <A HREF="digitization.html"> |
---|
| 19 | <IMG SRC="../../../../resources/html/IconsGIF/Next.gif" ALT="Next"></A> |
---|
| 20 | </TD> |
---|
| 21 | <TD ALIGN="Right"> |
---|
| 22 | <FONT SIZE="-1" COLOR="#238E23"> |
---|
| 23 | <B>Geant4 User's Guide</B> |
---|
| 24 | <BR> |
---|
| 25 | <B>For Application Developers</B> |
---|
| 26 | <BR> |
---|
| 27 | <B>Detector Definition and Response</B> |
---|
| 28 | </FONT> |
---|
| 29 | </TD> |
---|
| 30 | </TR></TABLE> |
---|
| 31 | <BR><BR> |
---|
| 32 | |
---|
| 33 | <P ALIGN="Center"> |
---|
| 34 | <FONT SIZE="+3" COLOR="#238E23"> |
---|
| 35 | <B>4.4 Hits</B> |
---|
| 36 | </FONT> |
---|
| 37 | <BR><BR> |
---|
| 38 | |
---|
| 39 | <HR ALIGN="Center" SIZE="7%"> |
---|
| 40 | <p> |
---|
| 41 | |
---|
| 42 | <a name="4.4.1"> |
---|
| 43 | <H2>4.4.1 Hit</H2></a> |
---|
| 44 | |
---|
| 45 | A hit is a snapshot of the physical interaction of a track in the sensitive |
---|
| 46 | region of a detector. In it you can store information associated with a |
---|
| 47 | <i>G4Step</i> object. This information can be |
---|
| 48 | <ul> |
---|
| 49 | <li>the position and time of the step, |
---|
| 50 | <li>the momentum and energy of the track, |
---|
| 51 | <li>the energy deposition of the step, |
---|
| 52 | <li>geometrical information, |
---|
| 53 | </ul> |
---|
| 54 | or any combination of the above. |
---|
| 55 | <p> |
---|
| 56 | |
---|
| 57 | <b><i>G4VHit</i></b> |
---|
| 58 | <p> |
---|
| 59 | <i>G4VHit</i> is an abstract base class which represents a hit. You must |
---|
| 60 | inherit this base class and derive your own concrete hit class(es). The |
---|
| 61 | member data of your concrete hit class can be, and should be, your choice. |
---|
| 62 | </p> |
---|
| 63 | <p> |
---|
| 64 | <i>G4VHit</i> has two virtual methods, <tt>Draw()</tt> and <tt>Print()</tt>. |
---|
| 65 | To draw or print out your concrete hits, these methods should be implemented. |
---|
| 66 | How to define the drawing method is described in |
---|
| 67 | <a href="../Visualization/markertext.html">Section 8.9</a>. |
---|
| 68 | </p> |
---|
| 69 | |
---|
| 70 | <br> |
---|
| 71 | <b><i>G4THitsCollection</i></b> |
---|
| 72 | <p> |
---|
| 73 | <i>G4VHit</i> is an abstract class from which you derive your own concrete |
---|
| 74 | classes. During the processing of a given event, represented by a |
---|
| 75 | <i>G4Event</i> object, many objects of the hit class will be produced, |
---|
| 76 | collected and associated with the event. Therefore, for each concrete hit |
---|
| 77 | class you must also prepare a concrete class derived from |
---|
| 78 | <i>G4VHitsCollection</i>, an abstract class which represents a vector |
---|
| 79 | collection of user defined hits. |
---|
| 80 | </p> |
---|
| 81 | <p> |
---|
| 82 | <i>G4THitsCollection</i> is a template class derived from |
---|
| 83 | <i>G4VHitsCollection</i>, and the concrete hit collection class of a |
---|
| 84 | particular <i>G4VHit</i> concrete class can be instantiated from this template |
---|
| 85 | class. Each object of a hit collection must have a unique name for each |
---|
| 86 | event. |
---|
| 87 | </p> |
---|
| 88 | <p> |
---|
| 89 | <i>G4Event</i> has a <i>G4HCofThisEvent</i> class object, that is a container |
---|
| 90 | class of collections of hits. Hit collections are stored by their pointers, |
---|
| 91 | whose type is that of the base class. |
---|
| 92 | <p> |
---|
| 93 | |
---|
| 94 | <b>An example of a concrete hit class</b> |
---|
| 95 | <p> |
---|
| 96 | Source listing 4.4.1 shows an example of a concrete hit class. |
---|
| 97 | <p> |
---|
| 98 | <center> |
---|
| 99 | <table border=2 cellpadding=10> |
---|
| 100 | <tr> |
---|
| 101 | <td> |
---|
| 102 | <pre> |
---|
| 103 | #ifndef ExN04TrackerHit_h |
---|
| 104 | #define ExN04TrackerHit_h 1 |
---|
| 105 | |
---|
| 106 | #include "G4VHit.hh" |
---|
| 107 | #include "G4THitsCollection.hh" |
---|
| 108 | #include "G4Allocator.hh" |
---|
| 109 | #include "G4ThreeVector.hh" |
---|
| 110 | |
---|
| 111 | class ExN04TrackerHit : public G4VHit |
---|
| 112 | { |
---|
| 113 | public: |
---|
| 114 | |
---|
| 115 | ExN04TrackerHit(); |
---|
| 116 | ~ExN04TrackerHit(); |
---|
| 117 | ExN04TrackerHit(const ExN04TrackerHit &right); |
---|
| 118 | const ExN04TrackerHit& operator=(const ExN04TrackerHit &right); |
---|
| 119 | int operator==(const ExN04TrackerHit &right) const; |
---|
| 120 | |
---|
| 121 | inline void * operator new(size_t); |
---|
| 122 | inline void operator delete(void *aHit); |
---|
| 123 | |
---|
| 124 | void Draw() const; |
---|
| 125 | void Print() const; |
---|
| 126 | |
---|
| 127 | private: |
---|
| 128 | G4double edep; |
---|
| 129 | G4ThreeVector pos; |
---|
| 130 | |
---|
| 131 | public: |
---|
| 132 | inline void SetEdep(G4double de) |
---|
| 133 | { edep = de; } |
---|
| 134 | inline G4double GetEdep() const |
---|
| 135 | { return edep; } |
---|
| 136 | inline void SetPos(G4ThreeVector xyz) |
---|
| 137 | { pos = xyz; } |
---|
| 138 | inline G4ThreeVector GetPos() const |
---|
| 139 | { return pos; } |
---|
| 140 | |
---|
| 141 | }; |
---|
| 142 | |
---|
| 143 | typedef G4THitsCollection<ExN04TrackerHit> ExN04TrackerHitsCollection; |
---|
| 144 | |
---|
| 145 | extern G4Allocator<ExN04TrackerHit> ExN04TrackerHitAllocator; |
---|
| 146 | |
---|
| 147 | inline void* ExN04TrackerHit::operator new(size_t) |
---|
| 148 | { |
---|
| 149 | void *aHit; |
---|
| 150 | aHit = (void *) ExN04TrackerHitAllocator.MallocSingle(); |
---|
| 151 | return aHit; |
---|
| 152 | } |
---|
| 153 | |
---|
| 154 | inline void ExN04TrackerHit::operator delete(void *aHit) |
---|
| 155 | { |
---|
| 156 | ExN04TrackerHitAllocator.FreeSingle((ExN04TrackerHit*) aHit); |
---|
| 157 | } |
---|
| 158 | |
---|
| 159 | #endif |
---|
| 160 | |
---|
| 161 | </pre> |
---|
| 162 | </td> |
---|
| 163 | </tr> |
---|
| 164 | <tr> |
---|
| 165 | <td align=center> |
---|
| 166 | Source listing 4.4.1<BR> |
---|
| 167 | An example of a concrete hit class. |
---|
| 168 | </td> |
---|
| 169 | </tr> |
---|
| 170 | </table></center> |
---|
| 171 | <p> |
---|
| 172 | <i>G4Allocator</i> is a class for fast allocation of objects to the heap |
---|
| 173 | through the paging mechanism. For details of <i>G4Allocator</i>, |
---|
| 174 | refer to <a href="../Fundamentals/global.html">3.2.4</a>. Use of |
---|
| 175 | <i>G4Allocator</i> is not mandatory, but it is recommended, especially for |
---|
| 176 | users who are not familiar with the C++ memory allocation |
---|
| 177 | mechanism or alternative tools of memory allocation. On the other hand, |
---|
| 178 | note that <i>G4Allocator</i> is to be used <b>only</b> for the concrete class |
---|
| 179 | that is <b>not</b> used as a base class of any other classes. For example, |
---|
| 180 | do <b>not</b> use the <i>G4Trajectory</i> class as a base class for a |
---|
| 181 | customized trajectory class, since <i>G4Trajectory</i> uses <i>G4Allocator</i>. |
---|
| 182 | </p> |
---|
| 183 | <p> |
---|
| 184 | |
---|
| 185 | <b>G4THitsMap</b> |
---|
| 186 | <p> |
---|
| 187 | <i>G4THitsMap</i> is an alternative to <i>G4THitsCollection</i>. |
---|
| 188 | <i>G4THitsMap</i> does not demand <i>G4VHit</i>, but instead any variable |
---|
| 189 | which can be mapped with an integer key. Typically the key is a copy number |
---|
| 190 | of the volume, and the mapped value could for example be a double, such as |
---|
| 191 | the energy deposition in a volume. <i>G4THitsMap</i> is convenient for |
---|
| 192 | applications which do not need to output event-by-event data but instead just |
---|
| 193 | accumulate them. All the <i>G4VPrimitiveScorer</i> classes discussed in |
---|
| 194 | <a href="#4.4.5">section 4.4.5</a> use <i>G4THitsMap</i>. |
---|
| 195 | </p> |
---|
| 196 | <p> |
---|
| 197 | <i>G4THitsMap</i> is derived from the <i>G4VHitsCollection</i> abstract base |
---|
| 198 | class and all objects of this class are also stored in <i>G4HCofThisEvent</i> |
---|
| 199 | at the end of an event. How to access a <i>G4THitsMap</i> object |
---|
| 200 | is discussed in the <a href="#4.4.5">following section</a>. |
---|
| 201 | |
---|
| 202 | <hr> |
---|
| 203 | <a name="4.4.2"> |
---|
| 204 | <H2>4.4.2 Sensitive detector</H2></a> |
---|
| 205 | |
---|
| 206 | <b><i>G4VSensitiveDetector</i></b> |
---|
| 207 | <p> |
---|
| 208 | <i>G4VSensitiveDetector</i> is an abstract base class which represents |
---|
| 209 | a detector. The principal mandate of a sensitive detector is the |
---|
| 210 | construction of hit objects using information from steps along a particle |
---|
| 211 | track. The <tt>ProcessHits()</tt> method of <i>G4VSensitiveDetector</i> |
---|
| 212 | performs this task using <i>G4Step</i> objects as input. In the case of a |
---|
| 213 | "Readout" geometry (see <a href="#4.4.3">Section 4.4.3</a>), objects of |
---|
| 214 | the <i>G4TouchableHistory</i> class may be used as an optional input. |
---|
| 215 | |
---|
| 216 | <p> |
---|
| 217 | Your concrete detector class should be instantiated with the unique name of |
---|
| 218 | your detector. The name can be associated with one or more global |
---|
| 219 | names with "/" as a delimiter for categorizing your detectors. For example |
---|
| 220 | <pre> |
---|
| 221 | myEMcal = new MyEMcal("/myDet/myCal/myEMcal"); |
---|
| 222 | </pre> |
---|
| 223 | where <tt>myEMcal</tt> is the name of your detector. The pointer to your |
---|
| 224 | sensitive detector must be set to one or more <i>G4LogicalVolume</i> |
---|
| 225 | objects to set the sensitivity of these volumes. The pointer should |
---|
| 226 | also be registered to <i>G4SDManager</i>, as described in |
---|
| 227 | <a href="#4.4.4">Section 4.4.4</a>. |
---|
| 228 | <p> |
---|
| 229 | <i>G4VSensitiveDetector</i> has three major virtual methods. |
---|
| 230 | <p> |
---|
| 231 | <dl> |
---|
| 232 | <dt><tt>ProcessHits()</tt> |
---|
| 233 | <dd>This method is invoked by <i>G4SteppingManager</i> when a step is |
---|
| 234 | composed in the <i>G4LogicalVolume</i> which has the pointer to this |
---|
| 235 | sensitive detector. The first argument of this method is a <i>G4Step</i> |
---|
| 236 | object of the current step. The second argument is a |
---|
| 237 | <i>G4TouchableHistory</i> object for the ``Readout geometry'' described |
---|
| 238 | in the next section. The second argument is <tt>NULL</tt> if |
---|
| 239 | ``Readout geometry'' is not assigned to this sensitive detector. |
---|
| 240 | In this method, one or more <i>G4VHit</i> objects should be |
---|
| 241 | constructed if the current step is meaningful for your detector.<p> |
---|
| 242 | <dt><tt>Initialize()</tt> |
---|
| 243 | <dd>This method is invoked at the beginning of each event. The argument |
---|
| 244 | of this method is an object of the <i>G4HCofThisEvent</i> class. Hit |
---|
| 245 | collections, where hits produced in this particular event are stored, |
---|
| 246 | can be associated with the <i>G4HCofThisEvent</i> object in this |
---|
| 247 | method. The hit collections associated with the <i>G4HCofThisEvent</i> |
---|
| 248 | object during this method can be used for ``during the event processing'' |
---|
| 249 | digitization.<p> |
---|
| 250 | <dt><tt>EndOfEvent()</tt> |
---|
| 251 | <dd>This method is invoked at the end of each event. The argument of |
---|
| 252 | this method is the same object as the previous method. Hit collections |
---|
| 253 | occasionally created in your sensitive detector can be associated with |
---|
| 254 | the <i>G4HCofThisEvent</i> object. |
---|
| 255 | </dl> |
---|
| 256 | <p> |
---|
| 257 | |
---|
| 258 | <HR> |
---|
| 259 | <a name="4.4.3"> |
---|
| 260 | <H2>4.4.3 Readout geometry</H2></a> |
---|
| 261 | |
---|
| 262 | This section describes how a ``Readout geometry'' can be defined. |
---|
| 263 | A Readout geometry is a virtual, parallel geometry for obtaining the |
---|
| 264 | channel number. |
---|
| 265 | <p> |
---|
| 266 | As an example, the accordion calorimeter of <b>ATLAS</b> has a |
---|
| 267 | complicated tracking geometry, however the readout can be done by |
---|
| 268 | simple cylindrical sectors divided by theta, phi, and depth. Tracks |
---|
| 269 | will be traced in the tracking geometry, the ``real'' one, and the |
---|
| 270 | sensitive detector will have its own readout geometry Geant4 will |
---|
| 271 | message to find to which ``readout'' cell the current hit belongs. |
---|
| 272 | <center><img src="hit.src/RO.gif"></center> |
---|
| 273 | <p> |
---|
| 274 | The picture shows how this association is done in Geant4. The first step is |
---|
| 275 | to associate a sensitive detector to a volume of the tracking geometry, in |
---|
| 276 | the usual way (see <a href="#4.4.2">Section 4.4.2</a>). The next step is to |
---|
| 277 | associate your <i>G4VReadoutGeometry</i> object to the sensitive detector. |
---|
| 278 | </p> |
---|
| 279 | <p> |
---|
| 280 | At tracking time, the base class <i>G4VReadoutGeometry</i> will provide to |
---|
| 281 | your sensitive detector code the <i>G4TouchableHistory</i> in the Readout |
---|
| 282 | geometry at the beginning of the step position (position of |
---|
| 283 | <i>PreStepPoint</i> of <i>G4Step</i>) and at this position only. |
---|
| 284 | </p> |
---|
| 285 | <p> |
---|
| 286 | This <i>G4TouchableHistory</i> is given to your sensitive detector code |
---|
| 287 | through the <i>G4VSensitiveDetector</i> virtual method: |
---|
| 288 | <pre> |
---|
| 289 | G4bool processHits(G4Step* aStep, G4TouchableHistory* ROhist); |
---|
| 290 | </pre> |
---|
| 291 | by the <tt>ROhist</tt> argument. |
---|
| 292 | <p> |
---|
| 293 | Thus, you will be able to use information from both the <i>G4Step</i> and |
---|
| 294 | the <i>G4TouchableHistory</i> coming from your Readout geometry. Note that |
---|
| 295 | since the association is done through a sensitive detector object, it is |
---|
| 296 | perfectly possible to have several Readout geometries in parallel. |
---|
| 297 | <p> |
---|
| 298 | |
---|
| 299 | <b>Definition of a virtual geometry setup</b> |
---|
| 300 | <p> |
---|
| 301 | The base class for the implementation of a Readout geometry is |
---|
| 302 | <i>G4VReadoutGeometry</i>. This class has a single pure virtual protected |
---|
| 303 | method: |
---|
| 304 | <pre> |
---|
| 305 | virtual G4VPhysicalVolume* build() = 0; |
---|
| 306 | </pre> |
---|
| 307 | which you must override in your concrete class. The <i>G4VPhysicalVolume</i> |
---|
| 308 | pointer you will have to return is of the physical world of the Readout |
---|
| 309 | geometry. |
---|
| 310 | <p> |
---|
| 311 | The step by step procedure for constructing a Readout geometry is: |
---|
| 312 | <ul> |
---|
| 313 | <li>inherit from <i>G4VReadoutGeometry</i> to define a <i>MyROGeom</i> |
---|
| 314 | class;<p> |
---|
| 315 | <li>implement the Readout geometry in the <tt>build()</tt> method, |
---|
| 316 | returning the physical world of this geometry.<p> |
---|
| 317 | The world is specified in the same way as for the |
---|
| 318 | detector construction: a physical volume with no mother. The |
---|
| 319 | axis system of this world is the same as the one of the |
---|
| 320 | world for tracking.<p> |
---|
| 321 | In this geometry you need to declare the sensitive parts |
---|
| 322 | in the same way as in the tracking geometry: by setting a |
---|
| 323 | non-<tt>NULL</tt> <i>G4VSensitiveDetector</i> pointer in, say, the |
---|
| 324 | relevant <i>G4LogicalVolume</i> objects. This sensitive class needs |
---|
| 325 | to be there, but will not be used.<p> |
---|
| 326 | You will also need to assign well defined materials to the volumes you |
---|
| 327 | place in this geometry, but these materials are irrelevant since they |
---|
| 328 | will not be seen by the tracking. It is foreseen to allow the setting |
---|
| 329 | of a <tt>NULL</tt> pointer in this case of the parallel geometry.<p> |
---|
| 330 | <li>in the <tt>construct()</tt> method of your concrete |
---|
| 331 | <i>G4VUserDetectorConstruction</i> class:<p> |
---|
| 332 | <ul> |
---|
| 333 | <li>instantiate your Readout geometry: |
---|
| 334 | <pre> |
---|
| 335 | MyROGeom* ROgeom = new MyROGeom("ROName"); |
---|
| 336 | </pre> |
---|
| 337 | <li>build it: |
---|
| 338 | <pre> |
---|
| 339 | ROgeom->buildROGeometry(); |
---|
| 340 | </pre> |
---|
| 341 | That will invoke your <tt>build()</tt> method.<p> |
---|
| 342 | <li>Instantiate the sensitive detector which will |
---|
| 343 | receive the <tt>ROGeom</tt> pointer, <tt>MySensitive</tt>, and |
---|
| 344 | add this sensitive to the <i>G4SDManager</i>. Associate this |
---|
| 345 | sensitive to the volume(s) of the tracking geometry as usual.<p> |
---|
| 346 | <li>Associate the sensitive to the Readout geometry: |
---|
| 347 | <pre> |
---|
| 348 | MySensitive->SetROgeometry(ROgeom); |
---|
| 349 | </pre> |
---|
| 350 | </ul> |
---|
| 351 | </ul> |
---|
| 352 | <p> |
---|
| 353 | |
---|
| 354 | <HR> |
---|
| 355 | <a name="4.4.4"> |
---|
| 356 | <H2>4.4.4 <i>G4SDManager</i></H2></a> |
---|
| 357 | |
---|
| 358 | <i>G4SDManager</i> is the singleton manager class for sensitive detectors. |
---|
| 359 | <p> |
---|
| 360 | |
---|
| 361 | <B>Activation / inactivation of sensitive detectors</B> |
---|
| 362 | <P> |
---|
| 363 | The user interface commands <tt>activate</tt> and <tt>inactivate</tt> |
---|
| 364 | are available to control your sensitive detectors. For example: |
---|
| 365 | <p> |
---|
| 366 | <tt>/hits/activate detector_name</tt><br> |
---|
| 367 | <tt>/hits/inactivate detector_name</tt> |
---|
| 368 | <p> |
---|
| 369 | where <tt>detector_name</tt> can be the detector name or the category |
---|
| 370 | name. For example, if your EM calorimeter is named <tt>/myDet/myCal/myEMcal</tt>, |
---|
| 371 | <pre> |
---|
| 372 | /hits/inactivate myCal |
---|
| 373 | </pre> |
---|
| 374 | will inactivate all detectors belonging to the <tt>myCal</tt> category. |
---|
| 375 | <p> |
---|
| 376 | |
---|
| 377 | <B>Access to the hit collections</B> |
---|
| 378 | <p> |
---|
| 379 | Hit collections are accessed for various cases. |
---|
| 380 | <p> |
---|
| 381 | <ul> |
---|
| 382 | <li>Digitization |
---|
| 383 | <li>Event filtering in <i>G4VUserStackingAction</i> |
---|
| 384 | <li>``End of event'' simple analysis |
---|
| 385 | <li>Drawing / printing hits |
---|
| 386 | </ul> |
---|
| 387 | <p> |
---|
| 388 | The following is an example of how to access the hit collection of a |
---|
| 389 | particular concrete type: |
---|
| 390 | <pre> |
---|
| 391 | G4SDManager* fSDM = G4SDManager::GetSDMpointer(); |
---|
| 392 | G4RunManager* fRM = G4RunManager::GetRunManager(); |
---|
| 393 | G4int collectionID = fSDM->GetCollectionID("collection_name"); |
---|
| 394 | const G4Event* currentEvent = fRM->GetCurrentEvent(); |
---|
| 395 | G4HCofThisEvent* HCofEvent = currentEvent->GetHCofThisEvent(); |
---|
| 396 | <i>MyHitsCollection</i>* myCollection = (<i>MyHitsCollection</i>*)(HC0fEvent->GetHC(collectionID)); |
---|
| 397 | </pre> |
---|
| 398 | <p> |
---|
| 399 | |
---|
| 400 | <hr> |
---|
| 401 | <a name="4.4.5"> |
---|
| 402 | <h2>4.4.5 <i>G4MultiFunctionalDetector</i> and |
---|
| 403 | <i>G4VPrimitiveScorer</i></h2></a> |
---|
| 404 | |
---|
| 405 | <i>G4MultiFunctionalDetector</i> is a concrete class derived from |
---|
| 406 | <i>G4VSensitiveDetector</i>. Instead of implementing a user-specific detector |
---|
| 407 | class, <i>G4MultiFunctionalDetector</i> allows the user to register |
---|
| 408 | <i>G4VPrimitiveScorer</i> classes to build up the sensitivity. |
---|
| 409 | <i>G4MultiFunctionalDetector</i> should be instantiated in the users detector |
---|
| 410 | construction with its unique name and should be assigned to one or more |
---|
| 411 | <i>G4LogicalVolume</i>s. |
---|
| 412 | <p> |
---|
| 413 | |
---|
| 414 | <i>G4VPrimitiveScorer</i> is an abstract base class representing a class to be |
---|
| 415 | registered to <i>G4MultiFunctionalDetector</i> that creates a |
---|
| 416 | <i>G4THitsMap</i> object of one physics quantity for an event. Geant4 provides |
---|
| 417 | many concrete primitive scorer classes listed in the |
---|
| 418 | <a href="#4.4.6">next section</a>, and the user can also implement his/her |
---|
| 419 | own primitive scorers. Each primitive scorer object must be instantiated with |
---|
| 420 | a name that must be unique among primitive scorers registered in a |
---|
| 421 | <i>G4MultiFunctionalDetector</i>. Please note that a primitive scorer object |
---|
| 422 | must <b>not</b> be shared by more than one <i>G4MultiFunctionalDetector</i> |
---|
| 423 | object. |
---|
| 424 | <p> |
---|
| 425 | |
---|
| 426 | As mentioned in <a href="#4.4.1>4.4.1</a>, each <i>G4VPrimitiveScorer</i> |
---|
| 427 | generates one <i>G4THitsMap</i> object per event. The name of the map object |
---|
| 428 | is the same as the name of the primitive scorer. Each of the concrete |
---|
| 429 | primitive scorers listed in the <a href="#4.4.6">next section</a> |
---|
| 430 | generates a <i>G4THitsMap<G4double></i> that maps a <i>G4double</i> |
---|
| 431 | value to its key integer number. By default, the key is taken as the copy |
---|
| 432 | number of the <i>G4LogicalVolume</i> to which <i>G4MultiFunctionalDetector</i> |
---|
| 433 | is assigned. In case the logical volume is uniquely placed in its mother |
---|
| 434 | volume and the mother is replicated, the copy number of its mother volume can |
---|
| 435 | be taken by setting the second argument of the <i>G4VPrimitiveScorer</i> |
---|
| 436 | constructor, "<i>depth</i>" to 1, i.e. one level up. Furthermore, in case the |
---|
| 437 | key must consider more than one copy number of a different geometry hierarchy, |
---|
| 438 | the user can derive his/her own primitive scorer from the provided concrete |
---|
| 439 | class and implement the <i>GetIndex(G4Step*)</i> virtual method to return the |
---|
| 440 | unique key. |
---|
| 441 | |
---|
| 442 | <P> |
---|
| 443 | Source listing 4.4.2 shows an example of primitive sensitivity class |
---|
| 444 | definitions. |
---|
| 445 | <p> |
---|
| 446 | <center> |
---|
| 447 | <table border=2 cellpadding=10> |
---|
| 448 | <tr> |
---|
| 449 | <td> |
---|
| 450 | <pre> |
---|
| 451 | void ExN07DetectorConstruction::SetupDetectors() |
---|
| 452 | { |
---|
| 453 | G4String filterName, particleName; |
---|
| 454 | |
---|
| 455 | G4SDParticleFilter* gammaFilter = new G4SDParticleFilter(filterName="gammaFilter",particleName="gamma"); |
---|
| 456 | G4SDParticleFilter* electronFilter = new G4SDParticleFilter(filterName="electronFilter",particleName="e-"); |
---|
| 457 | G4SDParticleFilter* positronFilter = new G4SDParticleFilter(filterName="positronFilter",particleName="e+"); |
---|
| 458 | G4SDParticleFilter* epFilter = new G4SDParticleFilter(filterName="epFilter"); |
---|
| 459 | epFilter->add(particleName="e-"); |
---|
| 460 | epFilter->add(particleName="e+"); |
---|
| 461 | |
---|
| 462 | |
---|
| 463 | for(G4int i=0;i<3;i++) |
---|
| 464 | { |
---|
| 465 | for(G4int j=0;j<2;j++) |
---|
| 466 | { |
---|
| 467 | // Loop counter j = 0 : absorber |
---|
| 468 | // = 1 : gap |
---|
| 469 | G4String detName = calName[i]; |
---|
| 470 | if(j==0) |
---|
| 471 | { detName += "_abs"; } |
---|
| 472 | else |
---|
| 473 | { detName += "_gap"; } |
---|
| 474 | G4MultiFunctionalDetector* det = new G4MultiFunctionalDetector(detName); |
---|
| 475 | |
---|
| 476 | // The second argument in each primitive means the "level" of geometrical hierarchy, |
---|
| 477 | // the copy number of that level is used as the key of the G4THitsMap. |
---|
| 478 | // For absorber (j = 0), the copy number of its own physical volume is used. |
---|
| 479 | // For gap (j = 1), the copy number of its mother physical volume is used, since there |
---|
| 480 | // is only one physical volume of gap is placed with respect to its mother. |
---|
| 481 | G4VPrimitiveScorer* primitive; |
---|
| 482 | primitive = new G4PSEnergyDeposit("eDep",j); |
---|
| 483 | det->RegisterPrimitive(primitive); |
---|
| 484 | primitive = new G4PSNofSecondary("nGamma",j); |
---|
| 485 | primitive->SetFilter(gammaFilter); |
---|
| 486 | det->RegisterPrimitive(primitive); |
---|
| 487 | primitive = new G4PSNofSecondary("nElectron",j); |
---|
| 488 | primitive->SetFilter(electronFilter); |
---|
| 489 | det->RegisterPrimitive(primitive); |
---|
| 490 | primitive = new G4PSNofSecondary("nPositron",j); |
---|
| 491 | primitive->SetFilter(positronFilter); |
---|
| 492 | det->RegisterPrimitive(primitive); |
---|
| 493 | primitive = new G4PSMinKinEAtGeneration("minEkinGamma",j); |
---|
| 494 | primitive->SetFilter(gammaFilter); |
---|
| 495 | det->RegisterPrimitive(primitive); |
---|
| 496 | primitive = new G4PSMinKinEAtGeneration("minEkinElectron",j); |
---|
| 497 | primitive->SetFilter(electronFilter); |
---|
| 498 | det->RegisterPrimitive(primitive); |
---|
| 499 | primitive = new G4PSMinKinEAtGeneration("minEkinPositron",j); |
---|
| 500 | primitive->SetFilter(positronFilter); |
---|
| 501 | det->RegisterPrimitive(primitive); |
---|
| 502 | primitive = new G4PSTrackLength("trackLength",j); |
---|
| 503 | primitive->SetFilter(epFilter); |
---|
| 504 | det->RegisterPrimitive(primitive); |
---|
| 505 | primitive = new G4PSNofStep("nStep",j); |
---|
| 506 | primitive->SetFilter(epFilter); |
---|
| 507 | det->RegisterPrimitive(primitive); |
---|
| 508 | |
---|
| 509 | G4SDManager::GetSDMpointer()->AddNewDetector(det); |
---|
| 510 | if(j==0) |
---|
| 511 | { layerLogical[i]->SetSensitiveDetector(det); } |
---|
| 512 | else |
---|
| 513 | { gapLogical[i]->SetSensitiveDetector(det); } |
---|
| 514 | } |
---|
| 515 | } |
---|
| 516 | } |
---|
| 517 | </pre> |
---|
| 518 | </td> |
---|
| 519 | </tr> |
---|
| 520 | <tr> |
---|
| 521 | <td align=center> |
---|
| 522 | Source listing 4.4.2<BR> |
---|
| 523 | An example of defining primitive sensitivity classes taken from <i>ExN07DetectorConstruction</i>. |
---|
| 524 | </td> |
---|
| 525 | </tr> |
---|
| 526 | </table></center> |
---|
| 527 | <p> |
---|
| 528 | |
---|
| 529 | Each <i>G4THitsMap</i> object can be accessed from <i>G4HCofThisEvent</i> with |
---|
| 530 | a unique collection ID number. This ID number can be obtained from |
---|
| 531 | <i>G4SDManager::GetCollectionID()</i> with a name of |
---|
| 532 | <i>G4MultiFunctionalDetector</i> and <i>G4VPrimitiveScorer</i> connected |
---|
| 533 | with a slush ("/"). |
---|
| 534 | <i>G4THitsMap</i> has a [] operator taking the key value as an argument and |
---|
| 535 | returning <b>the pointer</b> of the value. Please note that the [] operator |
---|
| 536 | returns <b>the pointer</b> of the value. If you get zero from the [] |
---|
| 537 | operator, it does <b>not</b> mean the value is zero, but that the provided key |
---|
| 538 | does not exist. The value itself is accessible with an astarisk ("*"). It is |
---|
| 539 | advised to check the validity of the returned pointer before accessing the |
---|
| 540 | value. <i>G4THitsMap</i> also has a += operator in order to accumulate |
---|
| 541 | event data into run data. Source listing 4.4.3 shows the use of |
---|
| 542 | <i>G4THitsMap</i>. |
---|
| 543 | <p> |
---|
| 544 | <center> |
---|
| 545 | <table border=2 cellpadding=10> |
---|
| 546 | <tr> |
---|
| 547 | <td> |
---|
| 548 | <pre> |
---|
| 549 | #include "ExN07Run.hh" |
---|
| 550 | #include "G4Event.hh" |
---|
| 551 | #include "G4HCofThisEvent.hh" |
---|
| 552 | #include "G4SDManager.hh" |
---|
| 553 | |
---|
| 554 | ExN07Run::ExN07Run() |
---|
| 555 | { |
---|
| 556 | G4String detName[6] = {"Calor-A_abs","Calor-A_gap","Calor-B_abs","Calor-B_gap","Calor-C_abs","Calor-C_gap"}; |
---|
| 557 | G4String primNameSum[6] = {"eDep","nGamma","nElectron","nPositron","trackLength","nStep"}; |
---|
| 558 | G4String primNameMin[3] = {"minEkinGamma","minEkinElectron","minEkinPositron"}; |
---|
| 559 | |
---|
| 560 | G4SDManager* SDMan = G4SDManager::GetSDMpointer(); |
---|
| 561 | G4String fullName; |
---|
| 562 | for(size_t i=0;i<6;i++) |
---|
| 563 | { |
---|
| 564 | for(size_t j=0;j<6;j++) |
---|
| 565 | { |
---|
| 566 | fullName = detName[i]+"/"+primNameSum[j]; |
---|
| 567 | colIDSum[i][j] = SDMan->GetCollectionID(fullName); |
---|
| 568 | } |
---|
| 569 | for(size_t k=0;k<3;k++) |
---|
| 570 | { |
---|
| 571 | fullName = detName[i]+"/"+primNameMin[k]; |
---|
| 572 | colIDMin[i][k] = SDMan->GetCollectionID(fullName); |
---|
| 573 | } |
---|
| 574 | } |
---|
| 575 | } |
---|
| 576 | |
---|
| 577 | void ExN07Run::RecordEvent(const G4Event* evt) |
---|
| 578 | { |
---|
| 579 | G4HCofThisEvent* HCE = evt->GetHCofThisEvent(); |
---|
| 580 | if(!HCE) return; |
---|
| 581 | numberOfEvent++; |
---|
| 582 | for(size_t i=0;i<6;i++) |
---|
| 583 | { |
---|
| 584 | for(size_t j=0;j<6;j++) |
---|
| 585 | { |
---|
| 586 | G4THitsMap<G4double>* evtMap = (G4THitsMap<G4double>*)(HCE->GetHC(colIDSum[i][j])); |
---|
| 587 | mapSum[i][j] += *evtMap; |
---|
| 588 | } |
---|
| 589 | for(size_t k=0;k<3;k++) |
---|
| 590 | { |
---|
| 591 | G4THitsMap<G4double>* evtMap = (G4THitsMap<G4double>*)(HCE->GetHC(colIDMin[i][k])); |
---|
| 592 | std::map<G4int,G4double*>::iterator itr = evtMap->GetMap()->begin(); |
---|
| 593 | for(; itr != evtMap->GetMap()->end(); itr++) |
---|
| 594 | { |
---|
| 595 | G4int key = (itr->first); |
---|
| 596 | G4double val = *(itr->second); |
---|
| 597 | G4double* mapP = mapMin[i][k][key]; |
---|
| 598 | if( mapP && (val>*mapP) ) continue; |
---|
| 599 | mapMin[i][k].set(key,val); |
---|
| 600 | } |
---|
| 601 | } |
---|
| 602 | } |
---|
| 603 | } |
---|
| 604 | </pre> |
---|
| 605 | </td> |
---|
| 606 | </tr> |
---|
| 607 | <tr> |
---|
| 608 | <td align=center> |
---|
| 609 | Source listing 4.4.3<BR> |
---|
| 610 | An example of accessing to <i>G4THitsMap</i> objects. |
---|
| 611 | </td> |
---|
| 612 | </tr> |
---|
| 613 | </table></center> |
---|
| 614 | <p> |
---|
| 615 | |
---|
| 616 | <HR> |
---|
| 617 | <a name="4.4.6"> |
---|
| 618 | <H2>4.4.6 Concrete classes of <i>G4VPrimitiveScorer</i></H2></a> |
---|
| 619 | |
---|
| 620 | With Geant4 version 8.0, several concrete primitive scorer classes are |
---|
| 621 | provided, all of which are derived from the <i>G4VPrimitiveScorer</i> abstract |
---|
| 622 | base class and which are to be registered to <i>G4MultiFunctionalDetector</i>. |
---|
| 623 | Each of them contains one <i>G4THitsMap</i> object and scores a simple double |
---|
| 624 | value for each key. |
---|
| 625 | |
---|
| 626 | <p> |
---|
| 627 | <b>Track length scorers</b><p> |
---|
| 628 | |
---|
| 629 | <DL> |
---|
| 630 | <DT>G4PSTrackLength</DT> |
---|
| 631 | <DD>The track length is defined as the sum of step lengths of the particles |
---|
| 632 | inside the cell. Bt default, the track weight is not taken into account, |
---|
| 633 | but could be used as a multiplier of each step length if the |
---|
| 634 | <i>Weighted()</i> method of this class object is invoked.</DD> |
---|
| 635 | <p> |
---|
| 636 | <DT>G4PSPassageTrackLength</DT> |
---|
| 637 | <DD>The passage track length is the same as the track length in |
---|
| 638 | <i>G4PSTrackLength</i>, except that only tracks which pass through the volume |
---|
| 639 | are taken into account. It means newly-generated or stopped tracks inside the |
---|
| 640 | cell are excluded from the calculation. By default, the track weight is not |
---|
| 641 | taken into account, but could be used as a multiplier of each step length if |
---|
| 642 | the <i>Weighted()</i> method of this class object is invoked.</DD> |
---|
| 643 | </DL> |
---|
| 644 | |
---|
| 645 | <p> |
---|
| 646 | <b>Deposited energy scorers</b><p> |
---|
| 647 | |
---|
| 648 | <DL> |
---|
| 649 | <DT>G4PSEnergyDeposit</DT> |
---|
| 650 | <DD>This scorer stores a sum of particles' energy deposits at each step in the |
---|
| 651 | cell. The particle weight is multiplied at each step.</DD> |
---|
| 652 | <p> |
---|
| 653 | <DT>G4PSDoseDeposit</DT> |
---|
| 654 | <DD>In some cases, dose is a more convenient way to evaluate the effect of |
---|
| 655 | energy deposit in a cell than simple deposited energy. The dose deposit is |
---|
| 656 | defined by the sum of energy deposits at each step in a cell divided by the |
---|
| 657 | mass of the cell. The mass is calculated from the density and volume of the |
---|
| 658 | cell taken from the methods of <i>G4VSolid</i> and <i>G4LogicalVolume</i>. |
---|
| 659 | The particle weight is multiplied at each step.</DD> |
---|
| 660 | </DL> |
---|
| 661 | |
---|
| 662 | <p> |
---|
| 663 | <b>Current and flux scorers</b><p> |
---|
| 664 | There are two different definitions of a particle's flow for a given geometry. |
---|
| 665 | One is a current and the other is a flux. In our scorers, the current is |
---|
| 666 | simply defined as the number of particles (with the particle's weight) at a |
---|
| 667 | certain surface or volume, while the flux takes the particle's injection angle |
---|
| 668 | to the geometry into account. The current and flux are usually defined at a |
---|
| 669 | surface, but volume current and volume flux are also provided. |
---|
| 670 | <p> |
---|
| 671 | <DL> |
---|
| 672 | <DT>G4PSFlatSurfaceCurrent</DT> |
---|
| 673 | <DD>Flat surface current is a surface based scorer. The present implementation |
---|
| 674 | is limited to scoring only at the -Z surface of a <i>G4Box</i> solid. The |
---|
| 675 | quantity is defined by the number of tracks that reach the surface. |
---|
| 676 | The user must choose a direction of the particle to be scored. The choices |
---|
| 677 | are fCurrent_In, fCurrent_Out, or fCurrent_InOut, one of which must be entered |
---|
| 678 | as the second argument of the constructor. Here, fCurrent_In scores incoming |
---|
| 679 | particles to the cell, while fCurrent_Out scores only outgoing particles from |
---|
| 680 | the cell. fCurrent_InOut scores both directions. The current is multiplied by |
---|
| 681 | particle weight and is normalized for a unit area.</DD><p> |
---|
| 682 | <DT>G4PSSphereSurfaceCurrent</DT> |
---|
| 683 | <DD>Sphere surface current is a surface based scorer, and similar to the |
---|
| 684 | G4PSFlatSurfaceCurrent. The only difference is that the surface is defined at |
---|
| 685 | the <b>inner surface</b> of a G4Sphere solid.</DD><p> |
---|
| 686 | <DT>G4PSPassageCurrent</DT> |
---|
| 687 | <DD>Passage current is a volume-based scorer. The current is defined by the |
---|
| 688 | number of tracks that pass through the volume. A particle weight is applied at |
---|
| 689 | the exit point. A passage current is defined for a volume.</DD><p> |
---|
| 690 | |
---|
| 691 | <DT>G4PSFlatSurfaceFlux</DT> |
---|
| 692 | <DD>Flat surface flux is a surface based flux scorer. The surface flux is |
---|
| 693 | defined by the number of tracks that reach the surface. The expression of |
---|
| 694 | surface flux is given by the sum of W/cos(t)/A, where W, t and A represent |
---|
| 695 | particle weight, injection angle of particle with respect to the surface |
---|
| 696 | normal, and area of the surface. The user must enter one of the particle |
---|
| 697 | directions, fFlux_In, fFlux_Out, or fFlux_InOut in the constructor. |
---|
| 698 | Here, fFlux_In scores incoming particles to the cell, while fFlux_Out scores |
---|
| 699 | outgoing particles from the cell. fFlux_InOut scores both directions.</DD><p> |
---|
| 700 | <DT>G4PSCellFlux</DT> |
---|
| 701 | <DD>Cell flux is a volume based flux scorer. The cell flux is defined by a |
---|
| 702 | track length (L) of the particle inside a volume divided by the volume (V) of |
---|
| 703 | this cell. The track length is calculated by a sum of the step lengths in the |
---|
| 704 | cell. The expression for cell flux is given by the sum of (W*L)/V, where W is |
---|
| 705 | a particle weight, and is multiplied by the track length at each step.</DD><p> |
---|
| 706 | <DT>G4PSPassageCellFlux</DT> |
---|
| 707 | <DD>Passage cell flux is a volume based scorer similar to <i>G4PSCellFlux</i>. |
---|
| 708 | The only difference is that tracks which pass through a cell are taken into |
---|
| 709 | account. It means generated or stopped tracks inside the volume are excluded |
---|
| 710 | from the calculation.</DD> |
---|
| 711 | </DL> |
---|
| 712 | |
---|
| 713 | <p> |
---|
| 714 | <b>Other scorers</b><p> |
---|
| 715 | <DL> |
---|
| 716 | <DT>G4PSMinKinEAtGeneration</DT> |
---|
| 717 | <DD>This scorer records the minimum kinetic energy of secondary particles at |
---|
| 718 | their production point in the volume in an event. This primitive scorer does |
---|
| 719 | not integrate the quantity, but records the minimum quantity. </DD><p> |
---|
| 720 | <DT>G4PSNofSecondary</DT> |
---|
| 721 | <DD>This class scores the number of secondary particles generated in the |
---|
| 722 | volume. The weight of the secondary track is taken into account. </DD><p> |
---|
| 723 | <DT>G4PSNofStep</DT> |
---|
| 724 | <DD>This class scores the number of steps in the cell. A particle weight is |
---|
| 725 | not applied.</DD> |
---|
| 726 | <DT>G4PSCellCharge</DT> |
---|
| 727 | <DD>This class scored the total charge of particles which has stoped in the |
---|
| 728 | volume.</DD> |
---|
| 729 | </DL> |
---|
| 730 | |
---|
| 731 | <hr> |
---|
| 732 | <a name="4.4.7"> |
---|
| 733 | <H2>4.4.7 <i>G4VSDFilter</i> and its derived classes</H2></a> |
---|
| 734 | |
---|
| 735 | <i>G4VSDFilter</i> is an abstract class that represents a track filter to be |
---|
| 736 | associated with <i>G4VSensitiveDetector</i> or <i>G4VPrimitiveScorer</i>. It |
---|
| 737 | defines a virtual method |
---|
| 738 | <DL><DD><i>G4bool Accept(const G4Step*)</i></DD></DL> |
---|
| 739 | that should return <i>true</i> if this particular step should be scored by |
---|
| 740 | the <i>G4VSensitiveDetector</i> or <i>G4VPrimitiveScorer</i>. |
---|
| 741 | |
---|
| 742 | <p> |
---|
| 743 | While the user can implement his/her own filter class, Geant4 version 8.0 |
---|
| 744 | provides the following concrete filter classes: |
---|
| 745 | <p> |
---|
| 746 | <DL> |
---|
| 747 | <DT>G4SDChargedFilter</DL> |
---|
| 748 | <DD>All charged particles are accepted.</DD><p> |
---|
| 749 | <DT>G4SDNeutralFilter</DL> |
---|
| 750 | <DD>All neutral particles are accepted.</DD><p> |
---|
| 751 | <DT>G4SDParticleFilter</DL> |
---|
| 752 | <DD>Particle species which are registered to this filter object by |
---|
| 753 | <i>Add("particle_name")</i> are accepted. More than one species can be |
---|
| 754 | registered.</DD><p> |
---|
| 755 | <DT>G4SDKineticEnergyFilter</DT> |
---|
| 756 | <DD>A track with kinetic energy greater than or equal to EKmin and smaller |
---|
| 757 | than EKmin is accepted. EKmin and EKmax should be defined as arguments |
---|
| 758 | of the constructor. The default values of EKmin and EKmax are zero and |
---|
| 759 | DBL_MAX.</DD><p> |
---|
| 760 | <DT>G4SDParticleWithEnergyFilter</DT> |
---|
| 761 | <DD>Combination of <i>G4SDParticleFilter</i> and |
---|
| 762 | <i>G4SDParticleWithEnergyFilter</i>.</DD><p> |
---|
| 763 | </DL> |
---|
| 764 | |
---|
| 765 | The use of the <i>G4SDParticleFilter</i> class is demonstrated in the Source |
---|
| 766 | Listing 4.4.2, where filters which accept gamma, electron, positron and |
---|
| 767 | electron/positron are defined. |
---|
| 768 | |
---|
| 769 | <br><br> |
---|
| 770 | <hr> |
---|
| 771 | <a href="../../../../Authors/html/subjectsToAuthors.html"> |
---|
| 772 | <i>About the authors</i></a> |
---|
| 773 | |
---|
| 774 | </body> |
---|
| 775 | </html> |
---|