| 1 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|---|
| 2 | <html>
|
|---|
| 3 | <head>
|
|---|
| 4 | <meta http-equiv="Content-Type"
|
|---|
| 5 | content="text/html; charset=iso-8859-1">
|
|---|
| 6 | <meta name="GENERATOR" content="Microsoft FrontPage 5.0">
|
|---|
| 7 | </head>
|
|---|
| 8 | <body>
|
|---|
| 9 | <!-- Changed by: Katsuya Amako, 30-Jul-1998 -->
|
|---|
| 10 | <!-- Proof read by: Joe Chuma, 29-Jun-1999 --><br>
|
|---|
| 11 | <table width="100%">
|
|---|
| 12 | <tbody>
|
|---|
| 13 | <tr>
|
|---|
| 14 | <td>
|
|---|
| 15 | <a href="../../../../Overview/html/index.html"><img
|
|---|
| 16 | src="../../../../resources/html/IconsGIF/Overview.gif" alt="Overview"
|
|---|
| 17 | height="16" width="59"></a>
|
|---|
| 18 | <a href="index.html"><img
|
|---|
| 19 | src="../../../../resources/html/IconsGIF/Contents.gif" alt="Contents"
|
|---|
| 20 | height="16" width="59"></a>
|
|---|
| 21 | <a href="tracking.html"><img
|
|---|
| 22 | src="../../../../resources/html/IconsGIF/Previous.gif" alt="Previous"
|
|---|
| 23 | height="16" width="59"></a>
|
|---|
| 24 | <a href="particle.html"><img
|
|---|
| 25 | src="../../../../resources/html/IconsGIF/Next.gif" alt="Next"
|
|---|
| 26 | height="16" width="59"></a>
|
|---|
| 27 | </td>
|
|---|
| 28 | <td align="right"><font color="#238e23"><font size="-1">
|
|---|
| 29 | <b>Geant4 User's Guide</b> </font></font>
|
|---|
| 30 | <br>
|
|---|
| 31 | <font color="#238e23"><font size="-1">
|
|---|
| 32 | <b>For Application Developers</b></font></font>
|
|---|
| 33 | <br>
|
|---|
| 34 | <font color="#238e23"><font size="-1"><b>Tracking and Physics</b> </font></font></td>
|
|---|
| 35 | </tr>
|
|---|
| 36 | </tbody>
|
|---|
| 37 | </table>
|
|---|
| 38 | <p>
|
|---|
| 39 | </p>
|
|---|
| 40 | <center><font color="#238e23"><font size="+3"><b>5.2 Physics Processes</b></font></font>
|
|---|
| 41 | </center>
|
|---|
| 42 | <p>
|
|---|
| 43 | </p>
|
|---|
| 44 | <hr align="center" size="7">
|
|---|
| 45 | <p> Physics processes describe how particles interact with a material.
|
|---|
| 46 | Seven major categories of processes are provided by Geant4: </p>
|
|---|
| 47 | <ol>
|
|---|
| 48 | <li> <a href="#5.2.1">electromagnetic</a>, </li>
|
|---|
| 49 | <li> <a href="#5.2.2">hadronic</a>, </li>
|
|---|
| 50 | <li> <a href="#5.2.3">decay</a>, </li>
|
|---|
| 51 | <li> <a href="#5.2.4">photolepton-hadron</a>, </li>
|
|---|
| 52 | <li> <a href="#5.2.5">optical</a>, </li>
|
|---|
| 53 | <li> <a href="#5.2.6">parameterization</a> and </li>
|
|---|
| 54 | <li> <a href="#5.2.7">transportation</a>. </li>
|
|---|
| 55 | </ol>
|
|---|
| 56 | <p>
|
|---|
| 57 | The generalization and abstraction of physics processes is a key issue
|
|---|
| 58 | in the
|
|---|
| 59 | design of Geant4. All physics processes are treated in the same manner
|
|---|
| 60 | from the tracking point of view. The Geant4 approach enables anyone to
|
|---|
| 61 | create a process and assign it to a particle type. This openness should
|
|---|
| 62 | allow the creation of processes for novel, domain-specific or
|
|---|
| 63 | customised purposes by individuals or groups of users.
|
|---|
| 64 | </p>
|
|---|
| 65 | <p> Each process has two groups of methods which play an important role
|
|---|
| 66 | in tracking, <tt>GetPhysicalInteractionLength</tt> (GPIL) and <tt>DoIt</tt>.
|
|---|
| 67 | The GPIL method gives the step length from the current space-time point
|
|---|
| 68 | to the next space-time point. It does this by calculating the
|
|---|
| 69 | probability of interaction based on the process's cross section
|
|---|
| 70 | information. At the end of this step the <tt>DoIt</tt> method should
|
|---|
| 71 | be invoked. The <tt>DoIt</tt> method implements the details of the
|
|---|
| 72 | interaction, changing the particle's energy, momentum, direction and
|
|---|
| 73 | position, and producing secondary tracks if required. These changes are
|
|---|
| 74 | recorded as <i>G4VParticleChange</i> objects(see <a
|
|---|
| 75 | href="#particlechange">Particle Change</a>).</p>
|
|---|
| 76 | <b><i>G4VProcess</i></b>
|
|---|
| 77 | <p><i>G4VProcess</i> is the base class for all physics processes. Each
|
|---|
| 78 | physics
|
|---|
| 79 | process must implement virtual methods of <i>G4VProcess</i> which
|
|---|
| 80 | describe the interaction (DoIt) and determine when an interaction
|
|---|
| 81 | should occur (GPIL). In order to accommodate various types of
|
|---|
| 82 | interactions <i>G4VProcess</i> provides three <tt>DoIt</tt> methods:
|
|---|
| 83 | </p>
|
|---|
| 84 | <ul>
|
|---|
| 85 | <li><tt>G4VParticleChange* AlongStepDoIt( const G4Track& track,
|
|---|
| 86 | const G4Step& stepData )</tt>
|
|---|
| 87 | <p> This method is invoked while <i>G4SteppingManager</i> is
|
|---|
| 88 | transporting a particle through one step. The corresponding <tt>AlongStepDoIt</tt>
|
|---|
| 89 | for each defined process is applied for every step regardless of which
|
|---|
| 90 | process produces the minimum step length. Each resulting change to the
|
|---|
| 91 | track information is recorded and accumulated in <i>G4Step</i>. After
|
|---|
| 92 | all processes have been invoked, changes due to <tt>AlongStepDoIt</tt>
|
|---|
| 93 | are applied to <i>G4Track</i>, including the particle relocation and
|
|---|
| 94 | the safety update. Note that after the invocation of <tt>AlongStepDoIt</tt>,
|
|---|
| 95 | the endpoint of the <i>G4Track</i> object is in a new volume if the
|
|---|
| 96 | step was limited by a geometric boundary. In order to obtain
|
|---|
| 97 | information about the old volume, <i>G4Step</i> must be accessed,
|
|---|
| 98 | since it contains information about both endpoints of a step.</p>
|
|---|
| 99 | </li>
|
|---|
| 100 | <li><tt>G4VParticleChange* PostStepDoIt( const G4Track& track,
|
|---|
| 101 | const G4Step& stepData )</tt>
|
|---|
| 102 | <p> This method is invoked at the end point of a step, only if its
|
|---|
| 103 | process has produced the minimum step length, or if the process is
|
|---|
| 104 | forced to occur. <i>G4Track</i> will be updated after each invocation
|
|---|
| 105 | of <tt>PostStepDoIt</tt>, in contrast to the <tt>AlongStepDoIt</tt>
|
|---|
| 106 | method. </p>
|
|---|
| 107 | </li>
|
|---|
| 108 | <li><tt>G4VParticleChange* AtRestDoIt( const G4Track& track,
|
|---|
| 109 | const G4Step& stepData )</tt>
|
|---|
| 110 | <p> This method is invoked only for stopped particles, and only if
|
|---|
| 111 | its process produced the minimum step length or the process is forced
|
|---|
| 112 | to occur.</p>
|
|---|
| 113 | </li>
|
|---|
| 114 | </ul>
|
|---|
| 115 | <p>
|
|---|
| 116 | For each of the above <tt>DoIt</tt> methods <i>G4VProcess</i>
|
|---|
| 117 | provides a corresponding pure virtual GPIL method: </p>
|
|---|
| 118 | <ul>
|
|---|
| 119 | <li><tt>G4double PostStepGetPhysicalInteractionLength( const
|
|---|
| 120 | G4Track& track, G4double previousStepSize, G4ForceCondition*
|
|---|
| 121 | condition )</tt>
|
|---|
| 122 | <p> This method generates the step length allowed by its process.
|
|---|
| 123 | It also provides a flag to force the interaction to occur regardless of
|
|---|
| 124 | its step length.</p>
|
|---|
| 125 | </li>
|
|---|
| 126 | <li><tt> G4double AlongStepGetPhysicalInteractionLength( const
|
|---|
| 127 | G4Track& track, G4double previousStepSize, G4double
|
|---|
| 128 | currentMinimumStep, G4double& proposedSafety, G4GPILSelection*
|
|---|
| 129 | selection )</tt>
|
|---|
| 130 | <p> This method generates the step length allowed by its process.</p>
|
|---|
| 131 | </li>
|
|---|
| 132 | <li><tt>G4double AtRestGetPhysicalInteractionLength( const
|
|---|
| 133 | G4Track& track, G4ForceCondition* condition )</tt>
|
|---|
| 134 | <p> This method generates the step length in time allowed by its
|
|---|
| 135 | process. It also provides a flag to force the interaction to occur
|
|---|
| 136 | regardless of its step length.</p>
|
|---|
| 137 | </li>
|
|---|
| 138 | </ul>
|
|---|
| 139 | <p></p>
|
|---|
| 140 | <p>
|
|---|
| 141 | Other pure virtual methods in <i>G4Vprocess</i> follow:
|
|---|
| 142 | </p>
|
|---|
| 143 | <ul>
|
|---|
| 144 | <li><tt>virtual G4bool IsApplicable(const G4ParticleDefinition&)</tt>
|
|---|
| 145 | <p> returns true if this process object is applicable to the
|
|---|
| 146 | particle type.</p>
|
|---|
| 147 | </li>
|
|---|
| 148 | <li><tt>virtual void PreparePhysicsTable(const
|
|---|
| 149 | G4ParticleDefinition&)</tt> and </li>
|
|---|
| 150 | <li><tt>virtual void BuildPhysicsTable(const
|
|---|
| 151 | G4ParticleDefinition&)</tt>
|
|---|
| 152 | <p> is messaged by the process manager, whenever cross section
|
|---|
| 153 | tables should be prepared and rebuilt due to changing cut-off values.
|
|---|
| 154 | It is not mandatory if the process is not affected by cut-off values.</p>
|
|---|
| 155 | </li>
|
|---|
| 156 | <li><tt>virtual void StartTracking()</tt> and </li>
|
|---|
| 157 | <li><tt>virtual void EndTracking()</tt>
|
|---|
| 158 | <p> are messaged by the tracking manager at the beginning and end
|
|---|
| 159 | of tracking the current track.</p>
|
|---|
| 160 | </li>
|
|---|
| 161 | </ul>
|
|---|
| 162 | <b>Other base classes for processes</b>
|
|---|
| 163 | <p> Specialized processes may be derived from seven additional virtual
|
|---|
| 164 | base classes which are themselves derived from <i>G4VProcess</i>.
|
|---|
| 165 | Three of these classes are used for simple processes:
|
|---|
| 166 | </p>
|
|---|
| 167 | <p>
|
|---|
| 168 | <table>
|
|---|
| 169 | <tbody>
|
|---|
| 170 | <tr>
|
|---|
| 171 | <td><i>G4VRestProcess</i> </td>
|
|---|
| 172 | <td>processes using only the <tt>AtRestDoIt</tt> method </td>
|
|---|
| 173 | </tr>
|
|---|
| 174 | <tr>
|
|---|
| 175 | <td> <br>
|
|---|
| 176 | </td>
|
|---|
| 177 | <td>example: neutron capture </td>
|
|---|
| 178 | </tr>
|
|---|
| 179 | <tr>
|
|---|
| 180 | <td><i>G4VContinuousProcess</i> </td>
|
|---|
| 181 | <td>processes using only the <tt>AlongStepDoIt</tt> method </td>
|
|---|
| 182 | </tr>
|
|---|
| 183 | <tr>
|
|---|
| 184 | </tr>
|
|---|
| 185 | <tr>
|
|---|
| 186 | <td> <br>
|
|---|
| 187 | </td>
|
|---|
| 188 | <td>example: cerenkov </td>
|
|---|
| 189 | </tr>
|
|---|
| 190 | <tr>
|
|---|
| 191 | <td><i>G4VDiscreteProcess</i> </td>
|
|---|
| 192 | <td>processes using only the <tt>PostStepDoIt</tt> method </td>
|
|---|
| 193 | </tr>
|
|---|
| 194 | <tr>
|
|---|
| 195 | <td> <br>
|
|---|
| 196 | </td>
|
|---|
| 197 | <td>example: compton scattering, hadron inelastic interaction </td>
|
|---|
| 198 | </tr>
|
|---|
| 199 | <tr>
|
|---|
| 200 | </tr>
|
|---|
| 201 | <tr>
|
|---|
| 202 | </tr>
|
|---|
| 203 | </tbody>
|
|---|
| 204 | </table>
|
|---|
| 205 | </p>
|
|---|
| 206 | <p> The other four classes are provided for rather complex processes:
|
|---|
| 207 | <table>
|
|---|
| 208 | <tbody>
|
|---|
| 209 | <tr>
|
|---|
| 210 | <td><i>G4VContinuousDiscreteProcess</i> </td>
|
|---|
| 211 | <td>processes using both <tt>AlongStepDoIt</tt> and <tt>PostStepDoIt</tt>
|
|---|
| 212 | methods </td>
|
|---|
| 213 | </tr>
|
|---|
| 214 | <tr>
|
|---|
| 215 | </tr>
|
|---|
| 216 | <tr>
|
|---|
| 217 | <td> <br>
|
|---|
| 218 | </td>
|
|---|
| 219 | <td>example: transportation, ionisation(energy loss and delta
|
|---|
| 220 | ray) </td>
|
|---|
| 221 | </tr>
|
|---|
| 222 | <tr>
|
|---|
| 223 | <td><i>G4VRestDiscreteProcess</i> </td>
|
|---|
| 224 | <td>processes using both <tt>AtRestDoIt</tt> and <tt>PostStepDoIt</tt>
|
|---|
| 225 | methods </td>
|
|---|
| 226 | </tr>
|
|---|
| 227 | <tr>
|
|---|
| 228 | </tr>
|
|---|
| 229 | <tr>
|
|---|
| 230 | <td> <br>
|
|---|
| 231 | </td>
|
|---|
| 232 | <td>example: positron annihilation, decay (both in flight and at
|
|---|
| 233 | rest) </td>
|
|---|
| 234 | </tr>
|
|---|
| 235 | <tr>
|
|---|
| 236 | <td><i>G4VRestContinuousProcess</i> </td>
|
|---|
| 237 | <td>processes using both <tt>AtRestDoIt</tt> and <tt>AlongStepDoIt</tt>
|
|---|
| 238 | methods </td>
|
|---|
| 239 | </tr>
|
|---|
| 240 | <tr>
|
|---|
| 241 | </tr>
|
|---|
| 242 | <tr>
|
|---|
| 243 | <td><i>G4VRestContinuousDiscreteProcess</i> </td>
|
|---|
| 244 | <td>processes using <tt>AtRestDoIt</tt>, <tt>AlongStepDoIt and <tt>PostStepDoIt</tt>
|
|---|
| 245 | methods </tt></td>
|
|---|
| 246 | </tr>
|
|---|
| 247 | <tr>
|
|---|
| 248 | </tr>
|
|---|
| 249 | <tr>
|
|---|
| 250 | </tr>
|
|---|
| 251 | </tbody>
|
|---|
| 252 | </table>
|
|---|
| 253 | </p>
|
|---|
| 254 | <p><a name="particlechange">
|
|---|
| 255 | <b>Particle change</b></a>
|
|---|
| 256 | </p>
|
|---|
| 257 | <p><i>G4VParticleChange</i> and its descendants are used to store the
|
|---|
| 258 | final state information of the track, including secondary tracks, which
|
|---|
| 259 | has been generated by the <tt>DoIt</tt> methods. The instance of <i>G4VParticleChange</i>
|
|---|
| 260 | is the only object whose information is updated by the physics
|
|---|
| 261 | processes, hence it is responsible for updating the step.
|
|---|
| 262 | The stepping manager collects secondary tracks and only sends requests
|
|---|
| 263 | via particle change to update <i>G4Step</i>.
|
|---|
| 264 | </p>
|
|---|
| 265 | <p><i>G4VParticleChange</i> is introduced as an abstract class. It has
|
|---|
| 266 | a minimal set of methods for updating <i>G4Step</i> and handling
|
|---|
| 267 | secondaries.
|
|---|
| 268 | A physics process can therefore define its own particle change derived
|
|---|
| 269 | from <i>G4VParticleChange</i>. Three pure virtual methods are
|
|---|
| 270 | provided, </p>
|
|---|
| 271 | <ul>
|
|---|
| 272 | <li><tt>virtual G4Step* UpdateStepForAtRest( G4Step* step )</tt>, </li>
|
|---|
| 273 | <li><tt>virtual G4Step* UpdateStepForAlongStep( G4Step* step )</tt>
|
|---|
| 274 | and </li>
|
|---|
| 275 | <li><tt>virtual G4Step* UpdateStepForPostStep( G4Step* step )</tt>, </li>
|
|---|
| 276 | </ul>
|
|---|
| 277 | which correspond to the three <tt>DoIt</tt> methods of <i>G4VProcess</i>.
|
|---|
| 278 | Each derived class should implement these methods.
|
|---|
| 279 | <p></p>
|
|---|
| 280 | <hr><a name="5.2.1"></a>
|
|---|
| 281 | <h2>5.2.1 Electromagnetic Interactions</h2>
|
|---|
| 282 | This section summarizes the electromagnetic physics processes which are
|
|---|
| 283 | installed in Geant4. For details on the implementation of these
|
|---|
| 284 | processes please refer to the
|
|---|
| 285 | <a href="../../../../UsersGuides/PhysicsReferenceManual/html/PhysicsReferenceManual.html">
|
|---|
| 286 | <b>Physics Reference Manual</b></a>.
|
|---|
| 287 | <p></p>
|
|---|
| 288 | <h4>5.2.1.1 "Standard" Electromagnetic Processes</h4>
|
|---|
| 289 | The following is a summary of the standard electromagnetic processes available in Geant4.
|
|---|
| 290 | <ul>
|
|---|
| 291 | <li>Photon processes
|
|---|
| 292 | <ul>
|
|---|
| 293 | <li>Compton scattering (class name <i>G4ComptonScattering</i>)</li>
|
|---|
| 294 | <li>Gamma conversion (also called pair production, class name <i>G4GammaConversion</i>)</li>
|
|---|
| 295 | <li>Photo-electric effect (class name <i>G4PhotoElectricEffect</i>)</li>
|
|---|
| 296 | <li>Muon pair production (class name <i>G4GammaConversionToMuons</i>)</li>
|
|---|
| 297 | </ul>
|
|---|
| 298 | </li>
|
|---|
| 299 | <li>Electron/positron processes
|
|---|
| 300 | <ul>
|
|---|
| 301 | <li>Ionisation and delta ray production (class name <i>G4eIonisation</i>)</li>
|
|---|
| 302 | <li>Bremsstrahlung (class name <i>G4eBremsstrahlung</i>)</li>
|
|---|
| 303 | <li>Positron annihilation into two gammas (class name <i>G4eplusAnnihilation</i>)</li>
|
|---|
| 304 | <li>Positron annihilation into two muons (class name <i>G4AnnihiToMuPair</i>)</li>
|
|---|
| 305 | <li>Positron annihilation into hadrons (class name <i>G4eeToHadrons</i>)</li>
|
|---|
| 306 | </ul>
|
|---|
| 307 | </li>
|
|---|
| 308 | <li>Muon processes
|
|---|
| 309 | <ul>
|
|---|
| 310 | <li>Ionisation and delta ray production (class name <i>G4MuIonisation</i>)</li>
|
|---|
| 311 | <li>Bremsstrahlung (class name <i>G4MuBremsstrahlung</i>)</li>
|
|---|
| 312 | <li>e+e- pair production (class name <i>G4MuPairProduction</i>)</li>
|
|---|
| 313 | </ul>
|
|---|
| 314 | </li>
|
|---|
| 315 | <li>Hadron/ion processes
|
|---|
| 316 | <ul>
|
|---|
| 317 | <li>Ionisation (class name <i>G4hIonisation</i>)</li>
|
|---|
| 318 | <li>Ionisation for ions (class name <i>G4ionIonisation</i>)</li>
|
|---|
| 319 | <li>Ionisation for ions in low-density media (class name <i>G4ionGasIonisation</i>)</li>
|
|---|
| 320 | <li>Ionisation for heavy exotic particles (class name <i>G4hhIonisation</i>)</li>
|
|---|
| 321 | <li>Ionisation for classic magnetic monopole (class name <i>G4mplIonisation</i>)</li>
|
|---|
| 322 | </ul>
|
|---|
| 323 | </li>
|
|---|
| 324 | <li>The scattering processes<br>
|
|---|
| 325 | The class name <i>G4MultipleScattering</i> is a general process in the
|
|---|
| 326 | sense that the same process/class is used to simulate the multiple
|
|---|
| 327 | scattering of all the charged particles (i.e. it is used for e+/e-,
|
|---|
| 328 | muons/charged hadrons). </li>
|
|---|
| 329 | <li>The processes described above use physics model classes, which
|
|---|
| 330 | may be combined according to particle energy. It is possible to change the
|
|---|
| 331 | energy range over which different models are valid, and to apply other
|
|---|
| 332 | models specific to particle type, energy range, and G4Region. The
|
|---|
| 333 | following alternative models are available: <br>
|
|---|
| 334 | <ul>
|
|---|
| 335 | <li>Ionisation in thin absorbers (class name <i>G4PAIModel</i>)</li>
|
|---|
| 336 | </ul>
|
|---|
| 337 | </li>
|
|---|
| 338 | </ul>
|
|---|
| 339 | An example of the registration of these processes in a physics list is
|
|---|
| 340 | given
|
|---|
| 341 | in source listing 5.2.1.1, extracted from examples/novice/N02.
|
|---|
| 342 | <p></p>
|
|---|
| 343 | <center>
|
|---|
| 344 | <table border="2" cellpadding="10">
|
|---|
| 345 | <tbody>
|
|---|
| 346 | <tr>
|
|---|
| 347 | <td>
|
|---|
| 348 | <pre>void PhysicsList::ConstructEM()<br>{<br> theParticleIterator->reset();<br><br> while( (*theParticleIterator)() ){<br><br> G4ParticleDefinition* particle = theParticleIterator->value();<br> G4ProcessManager* pmanager = particle->GetProcessManager();<br> G4String particleName = particle->GetParticleName();<br><br> if (particleName == "gamma") {<br><br> pmanager->AddDiscreteProcess(new G4PhotoElectricEffect);<br> pmanager->AddDiscreteProcess(new G4ComptonScattering);<br> pmanager->AddDiscreteProcess(new G4GammaConversion);<br><br> } else if (particleName == "e-") {<br><br> pmanager->AddProcess(new G4MultipleScattering, -1, 1, 1);<br> pmanager->AddProcess(new G4eIonisation, -1, 2, 2);<br> pmanager->AddProcess(new G4eBremsstrahlung, -1, 3, 3);<br><br> } else if (particleName == "e+") {<br><br> pmanager->AddProcess(new G4MultipleScattering, -1, 1, 1);<br> pmanager->AddProcess(new G4eIonisation, -1, 2, 2);<br> pmanager->AddProcess(new G4eBremsstrahlung, -1, 3, 3);<br> pmanager->AddProcess(new G4eplusAnnihilation, 0,-1, 4);<br> <br> } else if( particleName == "mu+" || <br> particleName == "mu-" ) {<br><br> pmanager->AddProcess(new G4MultipleScattering, -1, 1, 1);<br> pmanager->AddProcess(new G4MuIonisation, -1, 2, 2);<br> pmanager->AddProcess(new G4MuBremsstrahlung, -1, 3, 3);<br> pmanager->AddProcess(new G4MuPairProduction, -1, 4, 4); <br> <br> } else if ((!particle->IsShortLived()) &&<br> (particle->GetPDGCharge() != 0.0) && <br> (particle->GetParticleName() != "chargedgeantino")) {<br> //all others charged particles except geantino<br> pmanager->AddProcess(new G4MultipleScattering, -1, 1, 1);<br> pmanager->AddProcess(new G4hIonisation, -1, 2, 2);<br> <br> }<br> }<br>}<br> </pre>
|
|---|
| 349 | </td>
|
|---|
| 350 | </tr>
|
|---|
| 351 | <tr>
|
|---|
| 352 | <td align="center"> Source listing 5.2.1.1 <br>
|
|---|
| 353 | <tt>Registration of standard electromagnetic processes</tt>
|
|---|
| 354 | </td>
|
|---|
| 355 | </tr>
|
|---|
| 356 | </tbody>
|
|---|
| 357 | </table>
|
|---|
| 358 | </center>
|
|---|
| 359 | <p>
|
|---|
| 360 | <br>
|
|---|
| 361 | Novice and extended electromagnetic examples illustrating the use of
|
|---|
| 362 | electromagnetic processes are available as part of the Geant4 <a
|
|---|
| 363 | href="http://geant4.web.cern.ch/geant4/support/download.shtml">release</a>.
|
|---|
| 364 | <br>
|
|---|
| 365 | </p>
|
|---|
| 366 | </p>
|
|---|
| 367 | <p><b> Options </b> are available for steering the standard electromagnetic processes.
|
|---|
| 368 | These options may be invoked either by UI commands or by the interface class
|
|---|
| 369 | G4EmProcessOptions. This class has the following public methods:
|
|---|
| 370 | <br/><br/>
|
|---|
| 371 | - SetLossFluctuations(G4bool) <br>
|
|---|
| 372 | - SetSubCutoff(G4bool, const G4Region* r=0) <br>
|
|---|
| 373 | - SetIntegral(G4bool) <br>
|
|---|
| 374 | - SetRandomStep(G4bool) <br>
|
|---|
| 375 | - SetApplyCuts(G4bool) <br>
|
|---|
| 376 | - SetBuildCSDARange(G4bool) <br>
|
|---|
| 377 | - SetLPMFlag(G4bool) <br>
|
|---|
| 378 | - SetBremsstrahlungTh(G4double) <br>
|
|---|
| 379 | - SetMinSubRange(G4double) <br>
|
|---|
| 380 | - SetMinEnergy(G4double) <br>
|
|---|
| 381 | - SetMaxEnergy(G4double) <br>
|
|---|
| 382 | - SetMaxEnergyForCSDARange(G4double) <br>
|
|---|
| 383 | - SetMaxEnergyForMuons(G4double) <br>
|
|---|
| 384 | - SetDEDXBinning(G4int) <br>
|
|---|
| 385 | - SetDEDXBinningForCSDARange(G4int) <br>
|
|---|
| 386 | - SetLambdaBinning(G4int) <br>
|
|---|
| 387 | - SetVerbose(G4int, const G4String name= "all") <br>
|
|---|
| 388 | - SetLambdaFactor(G4double) <br>
|
|---|
| 389 | - SetMscStepLimitation(G4bool, G4double factor = -1.)
|
|---|
| 390 | <br/><br/>
|
|---|
| 391 | The corresponding UI command can be accessed in the UI subdirectory "/process/eLoss".
|
|---|
| 392 | </p>
|
|---|
| 393 | </p>
|
|---|
| 394 | <p><b> G4EmCalculator </b> is a class which provides access to cross sections and stopping
|
|---|
| 395 | powers. This class can be used anywhere in the user code provided the physics list has
|
|---|
| 396 | already been initialised (G4State_Idle).
|
|---|
| 397 | G4EmCalculator has "Get" methods which can be applied to materials for which physics tables
|
|---|
| 398 | are already built, and "Compute" methods which can be applied to any material defined in the
|
|---|
| 399 | application or existing in the Geant4 internal database. The public methods of this class
|
|---|
| 400 | are:
|
|---|
| 401 | <br/><br/>
|
|---|
| 402 | - GetDEDX(kinEnergy,particle,material,G4Region region=0) <br>
|
|---|
| 403 | - GetRangeFromRestrictedDEDX(kinEnergy,particle,material,G4Region* region=0) <br>
|
|---|
| 404 | - GetCSDARange(kinEnergy,particle,material,G4Region* region=0) <br>
|
|---|
| 405 | - GetRange(kinEnergy,particle,material,G4Region* region=0) <br>
|
|---|
| 406 | - GetKinEnergy(range,particle,material,G4Region* region=0) <br>
|
|---|
| 407 | - GetCrosSectionPerVolume(kinEnergy,particle,material,G4Region* region=0) <br>
|
|---|
| 408 | - GetMeanFreePath(kinEnergy,particle,material,G4Region* region=0) <br>
|
|---|
| 409 | - PrintDEDXTable(particle) <br>
|
|---|
| 410 | - PrintRangeTable(particle) <br>
|
|---|
| 411 | - PrintInverseRangeTable(particle) <br>
|
|---|
| 412 | - ComputeDEDX(kinEnergy,particle,process,material,cut=DBL_MAX) <br>
|
|---|
| 413 | - ComputeElectronicDEDX(kinEnergy,particle,material,cut=DBL_MAX) <br>
|
|---|
| 414 | - ComputeNuclearDEDX(kinEnergy,particle,material,cut=DBL_MAX) <br>
|
|---|
| 415 | - ComputeTotalDEDX(kinEnergy,particle,material,cut=DBL_MAX) <br>
|
|---|
| 416 | - ComputeCrosSectionPerVolume(kinEnergy,particle,process,material,cut=0) <br>
|
|---|
| 417 | - ComputeCrosSectionPerAtom(kinEnergy,particle,process,Z,A,cut=0) <br>
|
|---|
| 418 | - ComputeMeanFreePath(kinEnergy,particle,process,material,cut=0) <br>
|
|---|
| 419 | - FindParticle(const G4String&) <br>
|
|---|
| 420 | - FindMaterial(const G4String&) <br>
|
|---|
| 421 | - FindRegion(const G4String&) <br>
|
|---|
| 422 | - FindCouple(const G4Material*, const G4Region* region=0) <br>
|
|---|
| 423 | - SetVerbose(G4int)
|
|---|
| 424 | <br/><br/>
|
|---|
| 425 | For these interfaces, particles, materials, or processes may be pointers or strings with names.
|
|---|
| 426 | </p>
|
|---|
| 427 | </p>
|
|---|
| 428 |
|
|---|
| 429 | <h4>5.2.1.2 Low Energy Electromagnetic Processes</h4>
|
|---|
| 430 | The following is a summary of the Low Energy Electromagnetic processes
|
|---|
| 431 | available in Geant4. Further information is available in the <a
|
|---|
| 432 | href="http://www.ge.infn.it/geant4/lowE/index.html">homepage</a>
|
|---|
| 433 | of the Geant4 Low Energy Electromagnetic Physics Working Group.
|
|---|
| 434 | The physics content of these processes is documented in Geant4
|
|---|
| 435 | <a
|
|---|
| 436 | href="../../../../UsersGuides/PhysicsReferenceManual/html/PhysicsReferenceManual.html">Physics
|
|---|
| 437 | Reference Manual</a> and in other <a
|
|---|
| 438 | href="http://www.ge.infn.it/geant4/lowE/papers.html">papers</a>.
|
|---|
| 439 | <ul>
|
|---|
| 440 | <li><b> Photon processes </b>
|
|---|
| 441 | <ul>
|
|---|
| 442 | <li> Compton scattering (class <i>G4LowEnergyCompton</i>)</li>
|
|---|
| 443 | <li> Polarized Compton scattering (class <i>G4LowEnergyPolarizedCompton</i>)</li>
|
|---|
| 444 | <li> Rayleigh scattering (class <i>G4LowEnergyRayleigh</i>)</li>
|
|---|
| 445 | <li> Gamma conversion (also called pair production, class <i>G4LowEnergyGammaConversion</i>)</li>
|
|---|
| 446 | <li> Photo-electric effect (class<i>G4LowEnergyPhotoElectric</i>)</li>
|
|---|
| 447 | </ul>
|
|---|
| 448 | </li>
|
|---|
| 449 | <li><b> Electron processes </b>
|
|---|
| 450 | <ul>
|
|---|
| 451 | <li>Bremsstrahlung (class <i>G4LowEnergyBremsstrahlung</i>)</li>
|
|---|
| 452 | <li>Ionisation and delta ray production (class <i>G4LowEnergyIonisation</i>)</li>
|
|---|
| 453 | </ul>
|
|---|
| 454 | </li>
|
|---|
| 455 | <li><b> Hadron and ion processes </b>
|
|---|
| 456 | <ul>
|
|---|
| 457 | <li> Ionisation and delta ray production (class <i>G4hLowEnergyIonisation</i>)</li>
|
|---|
| 458 | </ul>
|
|---|
| 459 | </li>
|
|---|
| 460 | </ul>
|
|---|
| 461 | An example of the registration of these processes in a physics list is
|
|---|
| 462 | given
|
|---|
| 463 | in souce listing 5.2.1.2
|
|---|
| 464 | <p></p>
|
|---|
| 465 | <center>
|
|---|
| 466 | <table border="2" cellpadding="10">
|
|---|
| 467 | <tbody>
|
|---|
| 468 | <tr>
|
|---|
| 469 | <td>
|
|---|
| 470 | <pre>void LowEnPhysicsList::ConstructEM()<br>{<br> theParticleIterator->reset();<br><br> while( (*theParticleIterator)() ){<br><br> G4ParticleDefinition* particle = theParticleIterator->value();<br> G4ProcessManager* pmanager = particle->GetProcessManager();<br> G4String particleName = particle->GetParticleName();<br><br> if (particleName == "gamma") {<br><br> theLEPhotoElectric = new G4LowEnergyPhotoElectric();<br> theLECompton = new G4LowEnergyCompton();<br> theLEGammaConversion = new G4LowEnergyGammaConversion();<br> theLERayleigh = new G4LowEnergyRayleigh();<br><br> pmanager->AddDiscreteProcess(theLEPhotoElectric);<br> pmanager->AddDiscreteProcess(theLECompton);<br> pmanager->AddDiscreteProcess(theLERayleigh);<br> pmanager->AddDiscreteProcess(theLEGammaConversion);<br><br> }<br> else if (particleName == "e-") {<br><br> theLEIonisation = new G4LowEnergyIonisation();<br> theLEBremsstrahlung = new G4LowEnergyBremsstrahlung();<br> theeminusMultipleScattering = new G4MultipleScattering();<br><br> pmanager->AddProcess(theeminusMultipleScattering,-1,1,1);<br> pmanager->AddProcess(theLEIonisation,-1,2,2);<br> pmanager->AddProcess(theLEBremsstrahlung,-1,-1,3);<br><br> }<br> else if (particleName == "e+") {<br><br> theeplusMultipleScattering = new G4MultipleScattering();<br> theeplusIonisation = new G4eIonisation();<br> theeplusBremsstrahlung = new G4eBremsstrahlung();<br> theeplusAnnihilation = new G4eplusAnnihilation();<br><br> pmanager->AddProcess(theeplusMultipleScattering,-1,1,1);<br> pmanager->AddProcess(theeplusIonisation,-1,2,2);<br> pmanager->AddProcess(theeplusBremsstrahlung,-1,-1,3);<br> pmanager->AddProcess(theeplusAnnihilation,0,-1,4);<br> }<br> }<br>}<br> </pre>
|
|---|
| 471 | </td>
|
|---|
| 472 | </tr>
|
|---|
| 473 | <tr>
|
|---|
| 474 | <td align="center"> Source listing 5.2.1.2 <br>
|
|---|
| 475 | <tt>Registration of electromagnetic low energy electron/photon
|
|---|
| 476 | processes</tt>
|
|---|
| 477 | </td>
|
|---|
| 478 | </tr>
|
|---|
| 479 | </tbody>
|
|---|
| 480 | </table>
|
|---|
| 481 | </center>
|
|---|
| 482 | <p>
|
|---|
| 483 | <br>
|
|---|
| 484 | Advanced <b> examples </b> illustrating the use of Low Energy
|
|---|
| 485 | Electromagnetic processes are available as part of the Geant4 <a
|
|---|
| 486 | href="http://geant4.web.cern.ch/geant4/support/download.shtml">release</a> and are
|
|---|
| 487 | further documented <a
|
|---|
| 488 | href="http://www.ge.infn.it/geant4/lowE/examples/index.html">here</a>.
|
|---|
| 489 | </p>
|
|---|
| 490 | <p>To run the Low Energy code for photon and electron electromagnetic
|
|---|
| 491 | processes, <b><a
|
|---|
| 492 | href="http://geant4.web.cern.ch/geant4/support/download.shtml">
|
|---|
| 493 | data files</a></b> need to be copied by the user to
|
|---|
| 494 | his/her code repository. These files are distributed together with
|
|---|
| 495 | Geant4 <a href="http://geant4.web.cern.ch/geant4/support/download.shtml">release</a>.
|
|---|
| 496 | <br>
|
|---|
| 497 | The user should set the environment variable <b>G4LEDATA</b>
|
|---|
| 498 | to the directory where he/she has copied the files.
|
|---|
| 499 | </p>
|
|---|
| 500 | <p><b> Options </b> are available for low energy electromagnetic
|
|---|
| 501 | processes for hadrons and ions in terms of public member functions of
|
|---|
| 502 | the G4hLowEnergyIonisation class: <br>
|
|---|
| 503 | - SetHighEnergyForProtonParametrisation(G4double) <br>
|
|---|
| 504 | - SetLowEnergyForProtonParametrisation(G4double) <br>
|
|---|
| 505 | - SetHighEnergyForAntiProtonParametrisation(G4double) <br>
|
|---|
| 506 | - SetLowEnergyForAntiProtonParametrisation(G4double) <br>
|
|---|
| 507 | - SetElectronicStoppingPowerModel(const G4ParticleDefinition*,const
|
|---|
| 508 | G4String& ) <br>
|
|---|
| 509 | - SetNuclearStoppingPowerModel(const G4String&) <br>
|
|---|
| 510 | - SetNuclearStoppingOn() <br>
|
|---|
| 511 | - SetNuclearStoppingOff() <br>
|
|---|
| 512 | - SetBarkasOn() <br>
|
|---|
| 513 | - SetBarkasOff() <br>
|
|---|
| 514 | - SetFluorescence(const G4bool) <br>
|
|---|
| 515 | - ActivateAugerElectronProduction(G4bool) <br>
|
|---|
| 516 | - SetCutForSecondaryPhotons(G4double) <br>
|
|---|
| 517 | - SetCutForSecondaryElectrons(G4double) <br>
|
|---|
| 518 | The available models for ElectronicStoppingPower and
|
|---|
| 519 | NuclearStoppingPower are documented in the <a
|
|---|
| 520 | href="http://www.ge.infn.it/geant4/lowE/swprocess/design">class
|
|---|
| 521 | diagrams</a>. </p>
|
|---|
| 522 | <p><b> Options </b> are available for low energy electromagnetic
|
|---|
| 523 | processes for electrons in the G4LowEnergyIonisation class: <br>
|
|---|
| 524 | - ActivateAuger(G4bool) <br>
|
|---|
| 525 | - SetCutForLowEnSecPhotons(G4double) <br>
|
|---|
| 526 | - SetCutForLowEnSecElectrons(G4double) <br>
|
|---|
| 527 | </p>
|
|---|
| 528 | <p><b> Options </b> are available for low energy electromagnetic
|
|---|
| 529 | processes for electrons/positrons in the G4LowEnergyBremsstrahlung
|
|---|
| 530 | class, that allow the use of alternative bremsstrahlung angular
|
|---|
| 531 | generators: <br>
|
|---|
| 532 | - SetAngularGenerator(G4VBremAngularDistribution* distribution); <br>
|
|---|
| 533 | - SetAngularGenerator(const G4String& name); <br>
|
|---|
| 534 | Currently three angular generators are available: G4ModifiedTsai,
|
|---|
| 535 | 2BNGenerator and 2BSGenerator. G4ModifiedTsai is set by default, but it
|
|---|
| 536 | can be forced using the string "tsai". 2BNGenerator and 2BSGenerator
|
|---|
| 537 | can be set using the strings "2bs" and "2bn". Information regarding
|
|---|
| 538 | conditions of use, performance and energy limits of different models
|
|---|
| 539 | are available in the <a
|
|---|
| 540 | href="../../../../UsersGuides/PhysicsReferenceManual/html/PhysicsReferenceManual.html">
|
|---|
| 541 | Physics Reference Manual</a> and in the Geant4 Low Energy
|
|---|
| 542 | Electromagnetic Physics Working Group <a
|
|---|
| 543 | href="http://www.ge.infn.it/geant4/lowE/index.html">homepage</a>.
|
|---|
| 544 | </p>
|
|---|
| 545 | <p> Other <b> options </b> G4LowEnergyBremsstrahlung class are: <br>
|
|---|
| 546 | - SetCutForLowEnSecPhotons(G4double) <br>
|
|---|
| 547 | </p>
|
|---|
| 548 | <p><b> Options </b> can also be set in the G4LowEnergyPhotoElectric
|
|---|
| 549 | class, that allow the use of alternative photoelectron angular
|
|---|
| 550 | generators: <br>
|
|---|
| 551 | - SetAngularGenerator(G4VPhotoElectricAngularDistribution* distribution); <br>
|
|---|
| 552 | - SetAngularGenerator(const G4String& name); <br>
|
|---|
| 553 | Currently three angular generators are available: G4PhotoElectricAngularGeneratorSimple,
|
|---|
| 554 | G4PhotoElectricAngularGeneratorSauterGavrilla and G4PhotoElectricAngularGeneratorPolarized.
|
|---|
| 555 | G4PhotoElectricAngularGeneratorSimple is set by default, but it
|
|---|
| 556 | can be forced using the string "default". G4PhotoElectricAngularGeneratorSauterGavrilla and G4PhotoElectricAngularGeneratorPolarized
|
|---|
| 557 | can be set using the strings "standard" and "polarized". Information regarding
|
|---|
| 558 | conditions of use, performance and energy limits of different models
|
|---|
| 559 | are available in the <a
|
|---|
| 560 | href="../../../../UsersGuides/PhysicsReferenceManual/html/PhysicsReferenceManual.html">
|
|---|
| 561 | Physics Reference Manual</a> and in the Geant4 Low Energy
|
|---|
| 562 | Electromagnetic Physics Working Group <a
|
|---|
| 563 | href="http://www.ge.infn.it/geant4/lowE/index.html">homepage</a>.
|
|---|
| 564 | </p>
|
|---|
| 565 | <h4> </h4>
|
|---|
| 566 | <h4>5.2.1.3 Interactions of Muons</h4>
|
|---|
| 567 | The following is a summary of the muon interaction processes available
|
|---|
| 568 | in Geant4.
|
|---|
| 569 | <ul type="circle">
|
|---|
| 570 | <li>Bremsstrahlung (class name <i>G4MuBremsstrahlung</i>) </li>
|
|---|
| 571 | <li>Ionisation and delta ray/knock on electron production ( class
|
|---|
| 572 | name <i>G4MuIonisation</i>) </li>
|
|---|
| 573 | <li>Nuclear interaction (class name <i>G4MuNuclearInteraction</i>) </li>
|
|---|
| 574 | <li>Direct pair production (class name <i>G4MuPairProduction</i>) </li>
|
|---|
| 575 | In the case of
|
|---|
| 576 | muons, the bremsstrahlung, ionisation and pair production processes
|
|---|
| 577 | give contributions to the total continuous energy loss. </li>
|
|---|
| 578 | </ul>
|
|---|
| 579 | <h4>5.2.1.4 ``X-ray production'' Processes</h4>
|
|---|
| 580 | The following is a summary of the X-ray production processes available
|
|---|
| 581 | in Geant4.
|
|---|
| 582 | <ul type="circle">
|
|---|
| 583 | <li>Cerenkov process (class name <i>G4Cerenkov</i>) </li>
|
|---|
| 584 | <li>Synchrotron radiation (class name <i>G4SynchrotronRadiation</i>)</li>
|
|---|
| 585 | <li>Transition radiation (class names <i>G4TransitionRadiation</i>
|
|---|
| 586 | and <i>G4ForwardXrayTR</i>). </li>
|
|---|
| 587 | </ul>
|
|---|
| 588 | The Low Energy electromagnetic processes listed in section 5.2.1.2 also
|
|---|
| 589 | produce X-rays through fluorescence.
|
|---|
| 590 | <p></p>
|
|---|
| 591 | <hr><a name="5.2.2"></a>
|
|---|
| 592 | <h2>5.2.2 Hadronic Interactions</h2>
|
|---|
| 593 | This section briefly introduces the hadronic physics processes
|
|---|
| 594 | installed in Geant4. For details of the implementation of hadronic
|
|---|
| 595 | interactions available in Geant4, please refer to the <a
|
|---|
| 596 | href="../../../../UsersGuides/PhysicsReferenceManual/html/PhysicsReferenceManual.html">
|
|---|
| 597 | <b>Physics Reference Manual</b></a>.
|
|---|
| 598 | <p></p>
|
|---|
| 599 | <h4>5.2.2.1 Treatment of Cross Sections</h4>
|
|---|
| 600 | <b>Cross section data sets</b>
|
|---|
| 601 | <p> Each hadronic process object (derived from <i>G4HadronicProcess</i>)
|
|---|
| 602 | may have one or more cross section data sets associated with it. The
|
|---|
| 603 | term "data set" is meant, in a broad sense, to be an object that
|
|---|
| 604 | encapsulates methods and data for calculating total cross sections for
|
|---|
| 605 | a given process. The methods and data may take many forms, from a
|
|---|
| 606 | simple equation using a few hard-wired numbers to a sophisticated
|
|---|
| 607 | parameterisation using large data tables. Cross section data sets are
|
|---|
| 608 | derived from the abstract class <i>G4VCrossSectionDataSet</i>, and are
|
|---|
| 609 | required to implement the following methods:
|
|---|
| 610 | </p>
|
|---|
| 611 | <p> </p>
|
|---|
| 612 | <pre> G4bool IsApplicable( const G4DynamicParticle*, const G4Element* )<br> </pre>
|
|---|
| 613 | This method must return <tt>True</tt> if the data set is able to
|
|---|
| 614 | calculate a total cross section for the given particle and material,
|
|---|
| 615 | and <tt>False</tt> otherwise.
|
|---|
| 616 | <p> </p>
|
|---|
| 617 | <pre> G4double GetCrossSection( const G4DynamicParticle*, const G4Element* )<br> </pre>
|
|---|
| 618 | This method, which will be invoked only if <tt>True</tt> was returned
|
|---|
| 619 | by <tt>IsApplicable</tt>, must return a cross section, in Geant4
|
|---|
| 620 | default units, for the given particle and material.
|
|---|
| 621 | <p> </p>
|
|---|
| 622 | <pre> void BuildPhysicsTable( const G4ParticleDefinition& )<br> </pre>
|
|---|
| 623 | This method may be invoked to request the data set to recalculate its
|
|---|
| 624 | internal database or otherwise reset its state after a change in the
|
|---|
| 625 | cuts or other parameters of the given particle type.
|
|---|
| 626 | <p> </p>
|
|---|
| 627 | <pre> void DumpPhysicsTable( const G4ParticleDefinition& ) = 0<br> </pre>
|
|---|
| 628 | This method may be invoked to request the data set to print its
|
|---|
| 629 | internal database and/or other state information, for the given
|
|---|
| 630 | particle type, to the standard output stream.
|
|---|
| 631 | <p><b>Cross section data store</b>
|
|---|
| 632 | </p>
|
|---|
| 633 | <p>Cross section data sets are used by the process for the calculation
|
|---|
| 634 | of the physical interaction length. A given cross section data set may
|
|---|
| 635 | only apply to a certain energy range, or may only be able to calculate
|
|---|
| 636 | cross sections for a particular type of particle. The class <i>G4CrossSectionDataStore</i>
|
|---|
| 637 | has been provided to allow the user to specify, if desired, a series of
|
|---|
| 638 | data sets for a process, and to arrange the priority of data sets so
|
|---|
| 639 | that the appropriate one is used for a given energy range, particle,
|
|---|
| 640 | and material. It implements the following public methods:
|
|---|
| 641 | </p>
|
|---|
| 642 | <p> </p>
|
|---|
| 643 | <pre> G4CrossSectionDataStore()<br> ~G4CrossSectionDataStore()<br> </pre>
|
|---|
| 644 | and
|
|---|
| 645 | <p> </p>
|
|---|
| 646 | <pre> G4double GetCrossSection( const G4DynamicParticle*, const G4Element* )<br> </pre>
|
|---|
| 647 | For a given particle and material, this method returns a cross section
|
|---|
| 648 | value provided by one of the collection of cross section data sets
|
|---|
| 649 | listed in the data store object. If there are no known data sets, a <tt>G4Exception</tt>
|
|---|
| 650 | is thrown and <tt>DBL_MIN</tt> is returned. Otherwise, each data set
|
|---|
| 651 | in the list is queried, in reverse list order, by invoking its <tt>IsApplicable</tt>
|
|---|
| 652 | method for the given particle and material. The first data set object
|
|---|
| 653 | that responds positively will then be asked to return a cross section
|
|---|
| 654 | value via its <tt>GetCrossSection</tt> method. If no data set responds
|
|---|
| 655 | positively, a <tt>G4Exception</tt> is thrown and <tt>DBL_MIN</tt> is
|
|---|
| 656 | returned.
|
|---|
| 657 | <p> </p>
|
|---|
| 658 | <pre> void AddDataSet( G4VCrossSectionDataSet* aDataSet )<br> </pre>
|
|---|
| 659 | This method adds the given cross section data set to the end of the
|
|---|
| 660 | list of data sets in the data store. For the evaluation of cross
|
|---|
| 661 | sections, the list has a LIFO (Last In First Out) priority, meaning
|
|---|
| 662 | that data sets added later to the list will have priority over those
|
|---|
| 663 | added earlier to the list. Another way of saying this, is that the data
|
|---|
| 664 | store, when given a <tt>GetCrossSection</tt> request, does the <tt>IsApplicable</tt>
|
|---|
| 665 | queries in the reverse list order, starting with the last data set in
|
|---|
| 666 | the list and proceeding to the first, and the first data set that
|
|---|
| 667 | responds positively is used to calculate the cross section.
|
|---|
| 668 | <p> </p>
|
|---|
| 669 | <pre> void BuildPhysicsTable( const G4ParticleDefinition& aParticleType )<br> </pre>
|
|---|
| 670 | This method may be invoked to indicate to the data store that there has
|
|---|
| 671 | been a change in the cuts or other parameters of the given particle
|
|---|
| 672 | type. In response, the data store will invoke the <tt>BuildPhysicsTable</tt>
|
|---|
| 673 | of each of its data sets.
|
|---|
| 674 | <p> </p>
|
|---|
| 675 | <pre> void DumpPhysicsTable( const G4ParticleDefinition& )<br> </pre>
|
|---|
| 676 | This method may be used to request the data store to invoke the <tt>DumpPhysicsTable</tt>
|
|---|
| 677 | method of each of its data sets.
|
|---|
| 678 | <p><b>Default cross sections</b>
|
|---|
| 679 | </p>
|
|---|
| 680 | <p> The defaults for total cross section data and calculations have
|
|---|
| 681 | been encapsulated in the singleton class <i>G4HadronCrossSections</i>.
|
|---|
| 682 | Each hadronic process: <i>G4HadronInelasticProcess</i>, <i>G4HadronElasticProcess</i>,
|
|---|
| 683 | <i>G4HadronFissionProcess</i>, and <i>G4HadronCaptureProcess</i>,
|
|---|
| 684 | comes already equipped with a cross section data store and a default
|
|---|
| 685 | cross section data set. The data set objects are really just shells
|
|---|
| 686 | that invoke the singleton <i>G4HadronCrossSections</i> to do the real
|
|---|
| 687 | work of calculating cross sections.
|
|---|
| 688 | </p>
|
|---|
| 689 | <p> The default cross sections can be overridden in whole or in part by
|
|---|
| 690 | the user. To this end, the base class <i>G4HadronicProcess</i> has a
|
|---|
| 691 | ``get'' method: </p>
|
|---|
| 692 | <pre> G4CrossSectionDataStore* GetCrossSectionDataStore()<br> </pre>
|
|---|
| 693 | which gives public access to the data store for each process. The
|
|---|
| 694 | user's cross section data sets can be added to the data store according
|
|---|
| 695 | to the following framework:
|
|---|
| 696 | <pre> G4Hadron...Process aProcess(...)<br><br> MyCrossSectionDataSet myDataSet(...)<br><br> aProcess.GetCrossSectionDataStore()->AddDataSet( &MyDataSet )<br> </pre>
|
|---|
| 697 | <p> The added data set will override the default cross section data
|
|---|
| 698 | whenever so indicated by its <tt>IsApplicable</tt> method.
|
|---|
| 699 | </p>
|
|---|
| 700 | <p> In addition to the ``get'' method, <i>G4HadronicProcess</i> also
|
|---|
| 701 | has the method </p>
|
|---|
| 702 | <pre> void SetCrossSectionDataStore( G4CrossSectionDataStore* )<br> </pre>
|
|---|
| 703 | <p> which allows the user to completely replace the default data store
|
|---|
| 704 | with a new data store.
|
|---|
| 705 | </p>
|
|---|
| 706 | <p> It should be noted that a process does not send any information
|
|---|
| 707 | about itself to its associated data store (and hence data set) objects.
|
|---|
| 708 | Thus, each data set is assumed to be formulated to calculate cross
|
|---|
| 709 | sections for one and only one type of process. Of course, this does not
|
|---|
| 710 | prevent different data sets from sharing common data and/or calculation
|
|---|
| 711 | methods, as in the case of the <i>G4HadronCrossSections</i> class
|
|---|
| 712 | mentioned above. Indeed, <i>G4VCrossSectionDataSet</i> specifies only
|
|---|
| 713 | the abstract interface between physics processes and their data sets,
|
|---|
| 714 | and leaves the user free to implement whatever sort of underlying
|
|---|
| 715 | structure is appropriate.
|
|---|
| 716 | </p>
|
|---|
| 717 | <p> The current implementation of the data set <i>G4HadronCrossSections</i>
|
|---|
| 718 | reuses the total cross-sections for inelastic and elastic scattering,
|
|---|
| 719 | radiative capture and fission as used with <b>GHEISHA</b> to provide
|
|---|
| 720 | cross-sections for calculation of the respective mean free paths of a
|
|---|
| 721 | given particle in a given material.
|
|---|
| 722 | </p>
|
|---|
| 723 | <p></p>
|
|---|
| 724 | <h4>Cross-sections for low energy neutron transport</h4>
|
|---|
| 725 | <p> The cross section data for low energy neutron transport are
|
|---|
| 726 | organized in a set of files that are read in by the corresponding data
|
|---|
| 727 | set classes at time zero. Hereby the file system is used, in order to
|
|---|
| 728 | allow highly granular access to the data. The ``root'' directory of the
|
|---|
| 729 | cross-section directory structure is accessed through an environment
|
|---|
| 730 | variable, <tt>NeutronHPCrossSections</tt>, which is to be set by the
|
|---|
| 731 | user. The classes accessing the total cross-sections of the individual
|
|---|
| 732 | processes, i.e., the cross-section data set classes for low energy
|
|---|
| 733 | neutron transport, are <i>G4NeutronHPElasticData</i>, <i>G4NeutronHPCaptureData</i>,
|
|---|
| 734 | <i>G4NeutronHPFissionData</i>, and <i>G4NeutronHPInelasticData</i>.
|
|---|
| 735 | For detailed descriptions of the low energy neutron total
|
|---|
| 736 | cross-sections, they may be registered by the user as described above
|
|---|
| 737 | with the data stores of the corresponding processes for neutron
|
|---|
| 738 | interactions.
|
|---|
| 739 | </p>
|
|---|
| 740 | <p>It should be noted that using these total cross section classes does
|
|---|
| 741 | not require that the neutron_hp models also be used. It is up to the
|
|---|
| 742 | user to decide whethee this is desirable or not for his particular
|
|---|
| 743 | problem.
|
|---|
| 744 | </p>
|
|---|
| 745 | <p></p>
|
|---|
| 746 | <h4>5.2.2.2 Hadrons at Rest</h4>
|
|---|
| 747 | <b>List of implemented "Hadron at Rest" processes</b>
|
|---|
| 748 | <p> The following process classes have been implemented: </p>
|
|---|
| 749 | <ul type="circle">
|
|---|
| 750 | <li>pi- absorption (class name <i>G4PionMinusAbsorptionAtRest</i> or
|
|---|
| 751 | <i>G4PiMinusAbsorptionAtRest</i>)</li>
|
|---|
| 752 | <li>kaon- absorption (class name <i>G4KaonMinusAbsorptionAtRest</i>
|
|---|
| 753 | or <i>G4KaonMinusAbsorption</i>)</li>
|
|---|
| 754 | <li>neutron capture (class name <i>G4NeutronCaptureAtRest</i>)</li>
|
|---|
| 755 | <li>anti-proton annihilation (class name <i>G4AntiProtonAnnihilationAtRest</i>)</li>
|
|---|
| 756 | <li>anti-neutron annihilation (class name <i>G4AntiNeutronAnnihilationAtRest</i>)</li>
|
|---|
| 757 | <li>mu- capture (class name <i>G4MuonMinusCaptureAtRest</i>)</li>
|
|---|
| 758 | <li>alternative CHIPS model for any negativly charged particle (class name <i>G4QCaptureAtRest</i>)</li>
|
|---|
| 759 | </ul>
|
|---|
| 760 | Obviously the last process does not, strictly speaking, deal with a
|
|---|
| 761 | ``hadron at rest''. It does, nonetheless, share common features with
|
|---|
| 762 | the others in the above list because of the implementation model
|
|---|
| 763 | chosen. The differences betweeen the alternative implementation for
|
|---|
| 764 | kaon and pion absorption concern the fast part of the emitted particle
|
|---|
| 765 | spectrum.
|
|---|
| 766 | G4PiMinusAbsorptionAtRest, and G4KaonMinusAbsorptionAtRest focus
|
|---|
| 767 | especially on a good description of this part of the spectrum.
|
|---|
| 768 | <p><b>Implementation Interface to Geant4</b>
|
|---|
| 769 | </p>
|
|---|
| 770 | <p> All of these classes are derived from the abstract class <i>G4VRestProcess</i>.
|
|---|
| 771 | In addition to the constructor and destructor methods,
|
|---|
| 772 | the following public methods of the abstract class have been
|
|---|
| 773 | implemented for each of the above six processes:
|
|---|
| 774 | </p>
|
|---|
| 775 | <p> </p>
|
|---|
| 776 | <ul>
|
|---|
| 777 | <li><tt>AtRestGetPhysicalInteractionLength( const G4Track&,
|
|---|
| 778 | G4ForceCondition* )</tt><br>
|
|---|
| 779 | This method returns the time taken before the interaction actually
|
|---|
| 780 | occurs. In all processes listed above, except for muon capture, a value
|
|---|
| 781 | of zero is returned. For the muon capture process the muon capture
|
|---|
| 782 | lifetime is returned.
|
|---|
| 783 | <p> </p>
|
|---|
| 784 | </li>
|
|---|
| 785 | <li><tt>AtRestDoIt( const G4Track&, const G4Step& )</tt><br>
|
|---|
| 786 | This method generates the secondary particles produced by the process.
|
|---|
| 787 | <p> </p>
|
|---|
| 788 | </li>
|
|---|
| 789 | <li><tt>IsApplicable( const G4ParticleDefinition& )</tt><br>
|
|---|
| 790 | This method returns the result of a check to see if the process is
|
|---|
| 791 | possible for a given particle. </li>
|
|---|
| 792 | </ul>
|
|---|
| 793 | <p>
|
|---|
| 794 | <b>Example of how to use a hadron at rest process</b>
|
|---|
| 795 | </p>
|
|---|
| 796 | <p> Including a ``hadron at rest'' process for a particle, a pi- for
|
|---|
| 797 | example, into the Geant4 system is straightforward and can be done in
|
|---|
| 798 | the following way: </p>
|
|---|
| 799 | <ul>
|
|---|
| 800 | <li>create a process:
|
|---|
| 801 | <pre> theProcess = new G4PionMinusAbsorptionAtRest();<br> </pre>
|
|---|
| 802 | </li>
|
|---|
| 803 | <li>register the process with the particle's process manager:
|
|---|
| 804 | <pre> theParticleDef = G4PionMinus::PionMinus();<br> G4ProcessManager* pman = theParticleDef->GetProcessManager();<br> pman->AddRestProcess( theProcess );<br> </pre>
|
|---|
| 805 | </li>
|
|---|
| 806 | </ul>
|
|---|
| 807 | <h4>5.2.2.3 Hadrons in Flight</h4>
|
|---|
| 808 | <b>What processes do you need?</b>
|
|---|
| 809 | <p> For hadrons in motion, there are four physics process classes.
|
|---|
| 810 | Table 5.2.2.3 shows each process and the particles for which it is
|
|---|
| 811 | relevant.
|
|---|
| 812 | </p>
|
|---|
| 813 | <p> </p>
|
|---|
| 814 | <center>
|
|---|
| 815 | <table border="2" cellpadding="10">
|
|---|
| 816 | <tbody>
|
|---|
| 817 | <tr>
|
|---|
| 818 | <td valign="top"><i>G4HadronElasticProcess</i> </td>
|
|---|
| 819 | <td>pi+, pi-, K<sup>+</sup>, K<sup>0</sup><sub>S</sub>, K<sup>0</sup><sub>L</sub>,
|
|---|
| 820 | K<sup>-</sup>, p, p-bar, n, n-bar, lambda, lambda-bar, Sigma<sup>+</sup>,
|
|---|
| 821 | Sigma<sup>-</sup>, Sigma<sup>+</sup>-bar, Sigma<sup>-</sup>-bar, Xi<sup>0</sup>,
|
|---|
| 822 | Xi<sup>-</sup>, Xi<sup>0</sup>-bar, Xi<sup>-</sup>-bar </td>
|
|---|
| 823 | </tr>
|
|---|
| 824 | <tr>
|
|---|
| 825 | <td valign="top"><i>G4HadronInelasticProcess</i> </td>
|
|---|
| 826 | <td>pi+, pi-, K<sup>+</sup>, K<sup>0</sup><sub>S</sub>, K<sup>0</sup><sub>L</sub>,
|
|---|
| 827 | K<sup>-</sup>, p, p-bar, n, n-bar, lambda, lambda-bar, Sigma<sup>+</sup>,
|
|---|
| 828 | Sigma<sup>-</sup>, Sigma<sup>+</sup>-bar, Sigma<sup>-</sup>-bar, Xi<sup>0</sup>,
|
|---|
| 829 | Xi<sup>-</sup>, Xi<sup>0</sup>-bar, Xi<sup>-</sup>-bar </td>
|
|---|
| 830 | </tr>
|
|---|
| 831 | <tr>
|
|---|
| 832 | <td valign="top"><i>G4HadronFissionProcess </i></td>
|
|---|
| 833 | <td>all </td>
|
|---|
| 834 | </tr>
|
|---|
| 835 | <tr>
|
|---|
| 836 | <td valign="top"><i>G4CaptureProcess</i> </td>
|
|---|
| 837 | <td>n, n-bar </td>
|
|---|
| 838 | </tr>
|
|---|
| 839 | <tr>
|
|---|
| 840 | <td align="center" colspan="2"> Table 5.2.2.3<br>
|
|---|
| 841 | Hadronic processes and relevant particles. </td>
|
|---|
| 842 | </tr>
|
|---|
| 843 | </tbody>
|
|---|
| 844 | </table>
|
|---|
| 845 | </center>
|
|---|
| 846 | <p>
|
|---|
| 847 | <b>How to register Models</b>
|
|---|
| 848 | </p>
|
|---|
| 849 | <p> To register an inelastic process model for a particle, a proton for
|
|---|
| 850 | example, first get the pointer to the particle's process manager: </p>
|
|---|
| 851 | <pre> G4ParticleDefinition *theProton = G4Proton::ProtonDefinition();<br> G4ProcessManager *theProtonProcMan = theProton->GetProcessManager();<br> </pre>
|
|---|
| 852 | Create an instance of the particle's inelastic process:
|
|---|
| 853 | <pre> G4ProtonInelasticProcess *theProtonIEProc = new G4ProtonInelasticProcess();<br> </pre>
|
|---|
| 854 | Create an instance of the model which determines the secondaries
|
|---|
| 855 | produced in the interaction, and calculates the momenta of the
|
|---|
| 856 | particles:
|
|---|
| 857 | <pre> G4LEProtonInelastic *theProtonIE = new G4LEProtonInelastic();<br> </pre>
|
|---|
| 858 | Register the model with the particle's inelastic process:
|
|---|
| 859 | <pre> theProtonIEProc->RegisterMe( theProtonIE );<br> </pre>
|
|---|
| 860 | Finally, add the particle's inelastic process to the list of discrete
|
|---|
| 861 | processes:
|
|---|
| 862 | <pre> <br> theProtonProcMan->AddDiscreteProcess( theProtonIEProc );<br> </pre>
|
|---|
| 863 | The particle's inelastic process class, <i>G4ProtonInelasticProcess</i>
|
|---|
| 864 | in the example above, derives from the <i>G4HadronicInelasticProcess</i>
|
|---|
| 865 | class, and simply defines the process name and calls the <i>G4HadronicInelasticProcess</i>
|
|---|
| 866 | constructor. All of the specific particle inelastic processes derive
|
|---|
| 867 | from the <i>G4HadronicInelasticProcess</i> class, which calls the <tt>PostStepDoIt</tt>
|
|---|
| 868 | function, which returns the particle change object from the <i>G4HadronicProcess</i>
|
|---|
| 869 | function <tt>GeneralPostStepDoIt</tt>. This class also gets the mean
|
|---|
| 870 | free path, builds the physics table, and gets the microscopic cross
|
|---|
| 871 | section. The <i>G4HadronicInelasticProcess</i> class derives from the
|
|---|
| 872 | <i>G4HadronicProcess</i> class, which is the top level hadronic process
|
|---|
| 873 | class.
|
|---|
| 874 | The <i>G4HadronicProcess</i> class derives from the <i>G4VDiscreteProcess</i>
|
|---|
| 875 | class. The inelastic, elastic, capture, and fission processes derive
|
|---|
| 876 | from the <i>G4HadronicProcess</i> class. This pure virtual class also
|
|---|
| 877 | provides the energy range manager object and the <tt>RegisterMe</tt>
|
|---|
| 878 | access function.
|
|---|
| 879 | <p>A sample case for the proton's inelastic interaction model class is
|
|---|
| 880 | shown in source listing 5.2.2, where <tt>G4LEProtonInelastic.hh</tt>
|
|---|
| 881 | is the name of the include file:
|
|---|
| 882 | </p>
|
|---|
| 883 | <p></p>
|
|---|
| 884 | <center>
|
|---|
| 885 | <table border="2" cellpadding="10">
|
|---|
| 886 | <tbody>
|
|---|
| 887 | <tr>
|
|---|
| 888 | <td>
|
|---|
| 889 | <pre> ----------------------------- include file ------------------------------------------<br><br>#include "G4InelasticInteraction.hh"<br> class G4LEProtonInelastic : public G4InelasticInteraction<br> {<br> public:<br> G4LEProtonInelastic() : G4InelasticInteraction()<br> {<br> SetMinEnergy( 0.0 );<br> SetMaxEnergy( 25.*GeV );<br> }<br> ~G4LEProtonInelastic() { }<br> G4ParticleChange *ApplyYourself( const G4Track &aTrack,<br> G4Nucleus &targetNucleus );<br> private:<br> void CascadeAndCalculateMomenta( required arguments );<br> };<br><br> ----------------------------- source file ------------------------------------------<br><br> #include "G4LEProtonInelastic.hh"<br> G4ParticleChange *<br> G4LEProton Inelastic::ApplyYourself( const G4Track &aTrack,<br> G4Nucleus &targetNucleus )<br> {<br> theParticleChange.Initialize( aTrack );<br> const G4DynamicParticle *incidentParticle = aTrack.GetDynamicParticle();<br> // create the target particle<br> G4DynamicParticle *targetParticle = targetNucleus.ReturnTargetParticle();<br> CascadeAndCalculateMomenta( required arguments )<br> { ... }<br> return &theParticleChange;<br> }<br> </pre>
|
|---|
| 890 | </td>
|
|---|
| 891 | </tr>
|
|---|
| 892 | <tr>
|
|---|
| 893 | <td align="center"> Source listing 5.2.2<br>
|
|---|
| 894 | An example of a proton inelastic interaction model class.
|
|---|
| 895 | </td>
|
|---|
| 896 | </tr>
|
|---|
| 897 | </tbody>
|
|---|
| 898 | </table>
|
|---|
| 899 | </center>
|
|---|
| 900 | <p>
|
|---|
| 901 | The <tt>CascadeAndCalculateMomenta</tt> function is the bulk of the
|
|---|
| 902 | model and is to be provided by the model's creator. It should determine
|
|---|
| 903 | what secondary particles are produced in the interaction, calculate the
|
|---|
| 904 | momenta for all the particles, and put this information into the <i>ParticleChange</i>
|
|---|
| 905 | object which is returned.
|
|---|
| 906 | </p>
|
|---|
| 907 | <p>The <i>G4LEProtonInelastic</i> class derives from the <i>G4InelasticInteraction</i>
|
|---|
| 908 | class, which is an abstract base class since the pure virtual function <tt>ApplyYourself</tt>
|
|---|
| 909 | is not defined there. <i>G4InelasticInteraction</i> itself derives
|
|---|
| 910 | from the
|
|---|
| 911 | <i>G4HadronicInteraction</i> abstract base class. This class is the
|
|---|
| 912 | base class for all the model classes. It sorts out the energy range for
|
|---|
| 913 | the models and provides class utilities. The <i>G4HadronicInteraction</i>
|
|---|
| 914 | class provides the <tt>Set/GetMinEnergy</tt> and the <tt>Set/GetMaxEnergy</tt>
|
|---|
| 915 | functions which determine the minimum and maximum energy range for the
|
|---|
| 916 | model. An energy range can be set for a specific element, a specific
|
|---|
| 917 | material, or for general applicability:
|
|---|
| 918 | </p>
|
|---|
| 919 | <p> </p>
|
|---|
| 920 | <pre> void SetMinEnergy( G4double anEnergy, G4Element *anElement )<br> void SetMinEnergy( G4double anEnergy, G4Material *aMaterial )<br> void SetMinEnergy( const G4double anEnergy )<br> void SetMaxEnergy( G4double anEnergy, G4Element *anElement )<br> void SetMaxEnergy( G4double anEnergy, G4Material *aMaterial )<br> void SetMaxEnergy( const G4double anEnergy )<br> </pre>
|
|---|
| 921 | <p>
|
|---|
| 922 | <b>Which models are there, and what are the defaults</b>
|
|---|
| 923 | </p>
|
|---|
| 924 | <p>In Geant4, any model can be run together with any other model
|
|---|
| 925 | without
|
|---|
| 926 | the need for the implementation of a special interface, or batch suite,
|
|---|
| 927 | and the ranges of applicability for the different models can
|
|---|
| 928 | be steered at initialisation time. This way, highly specialised models
|
|---|
| 929 | (valid
|
|---|
| 930 | only for one material and particle, and applicable only in a very
|
|---|
| 931 | restricted energy range) can be used in the same application, together
|
|---|
| 932 | with more general code, in a coherent fashion.
|
|---|
| 933 | </p>
|
|---|
| 934 | <p>Each model has an intrinsic range of applicability, and the model
|
|---|
| 935 | chosen for
|
|---|
| 936 | a simulation depends very much on the use-case. Consequently, there are
|
|---|
| 937 | no ``defaults''. However, physics lists are provided which specify sets
|
|---|
| 938 | of models for various purposes.
|
|---|
| 939 | </p>
|
|---|
| 940 | <p>Three types of hadronic shower models have been implemented:
|
|---|
| 941 | parametrisation driven models, data driven models, and theory driven
|
|---|
| 942 | models.
|
|---|
| 943 | </p>
|
|---|
| 944 | <p> </p>
|
|---|
| 945 | <ul>
|
|---|
| 946 | <li>Parametrisation driven models are used for all processes
|
|---|
| 947 | pertaining to particles coming to rest, and interacting with the
|
|---|
| 948 | nucleus. For particles in flight, two sets of models exist for
|
|---|
| 949 | inelastic scattering; low energy, and high energy models. Both sets are
|
|---|
| 950 | based originally on the <b>GHEISHA</b> package of Geant3.21, and the
|
|---|
| 951 | original approaches to primary interaction, nuclear excitation,
|
|---|
| 952 | intra-nuclear cascade and evaporation is kept. The models are located
|
|---|
| 953 | in the sub-directories <tt>hadronics/models/low_energy</tt> and <tt>hadronics/models/high_energy</tt>.
|
|---|
| 954 | The low energy models are targeted towards energies below 20 GeV;
|
|---|
| 955 | the high energy models cover the energy range from 20 GeV to
|
|---|
| 956 | O(TeV). Fission, capture and coherent elastic scattering are also
|
|---|
| 957 | modeled through parametrised models. </li>
|
|---|
| 958 | <li>Data driven models are available for the transport of low energy
|
|---|
| 959 | neutrons in matter in sub-directory <tt>hadronics/models/neutron_hp</tt>.
|
|---|
| 960 | The modeling is based on the data formats of <b>ENDF/B-VI</b>, and all
|
|---|
| 961 | distributions of this standard data format are implemented. The data
|
|---|
| 962 | sets used are selected from data libraries that conform to these
|
|---|
| 963 | standard formats. The file system is used in order to allow granular
|
|---|
| 964 | access to, and flexibility in, the use of the cross sections for
|
|---|
| 965 | different isotopes, and channels. The energy coverage of these models
|
|---|
| 966 | is from thermal energies to 20 MeV. </li>
|
|---|
| 967 | <li>Theory driven models are available for inelastic scattering in a
|
|---|
| 968 | first implementation, covering the full energy range of LHC
|
|---|
| 969 | experiments. They are located in sub-directory <tt>hadronics/models/generator</tt>.
|
|---|
| 970 | The current philosophy implies the usage of parton string models at
|
|---|
| 971 | high energies, of intra-nuclear transport models at intermediate
|
|---|
| 972 | energies, and of statistical break-up models for de-excitation. </li>
|
|---|
| 973 | </ul>
|
|---|
| 974 | <p>
|
|---|
| 975 | </p>
|
|---|
| 976 | <hr><a name="5.2.3"></a>
|
|---|
| 977 | <h2>5.2.3 Particle Decay Process</h2>
|
|---|
| 978 | This section briefly introduces decay processes installed in Geant4.
|
|---|
| 979 | For details of the implementation of particle decays, please refer to
|
|---|
| 980 | the <a
|
|---|
| 981 | href="../../../../UsersGuides/PhysicsReferenceManual/html/PhysicsReferenceManual.html">
|
|---|
| 982 | <b>Physics Reference Manual</b></a>.
|
|---|
| 983 | <p></p>
|
|---|
| 984 | <h4>5.2.3.1 Particle Decay Class</h4>
|
|---|
| 985 | Geant4 provides a <i>G4Decay</i> class for both ``at rest'' and ``in
|
|---|
| 986 | flight'' particle decays. <i>G4Decay</i> can be applied to all
|
|---|
| 987 | particles except:
|
|---|
| 988 | <center>
|
|---|
| 989 | <table>
|
|---|
| 990 | <tbody>
|
|---|
| 991 | <tr>
|
|---|
| 992 | <td>massless particles, i.e., </td>
|
|---|
| 993 | <td><tt>G4ParticleDefinition::thePDGMass <= 0</tt> </td>
|
|---|
| 994 | </tr>
|
|---|
| 995 | <tr>
|
|---|
| 996 | <td>particles with ``negative'' life time, i.e., </td>
|
|---|
| 997 | <td><tt>G4ParticleDefinition::thePDGLifeTime < 0</tt> </td>
|
|---|
| 998 | </tr>
|
|---|
| 999 | <tr>
|
|---|
| 1000 | <td>shortlived particles, i.e., </td>
|
|---|
| 1001 | <td><tt>G4ParticleDefinition::fShortLivedFlag = True</tt> </td>
|
|---|
| 1002 | </tr>
|
|---|
| 1003 | </tbody>
|
|---|
| 1004 | </table>
|
|---|
| 1005 | </center>
|
|---|
| 1006 | <p>
|
|---|
| 1007 | Decay for some particles may be switched on or off by using <tt>G4ParticleDefinition::SetPDGStable()</tt>
|
|---|
| 1008 | as well as <tt>ActivateProcess()</tt> and <tt>InActivateProcess()</tt>
|
|---|
| 1009 | methods of <i>G4ProcessManager</i>.
|
|---|
| 1010 | </p>
|
|---|
| 1011 | <p><i>G4Decay</i> proposes the step length (or step time for <tt>AtRest</tt>)
|
|---|
| 1012 | according to the lifetime of the particle unless <tt>PreAssignedDecayProperTime</tt>
|
|---|
| 1013 | is defined in <i>G4DynamicParticle</i>.
|
|---|
| 1014 | </p>
|
|---|
| 1015 | <p>The <i>G4Decay</i> class itself does not define decay modes of the
|
|---|
| 1016 | particle. Geant4 provides two ways of doing this: </p>
|
|---|
| 1017 | <ul>
|
|---|
| 1018 | <li>using <i>G4DecayChannel</i> in <i>G4DecayTable</i>, and </li>
|
|---|
| 1019 | <li>using <tt>thePreAssignedDecayProducts</tt> of <i>G4DynamicParticle</i>
|
|---|
| 1020 | </li>
|
|---|
| 1021 | </ul>
|
|---|
| 1022 | The <i>G4Decay</i> class calculates the <tt>PhysicalInteractionLength</tt>
|
|---|
| 1023 | and boosts decay products created by <i>G4VDecayChannel</i> or event
|
|---|
| 1024 | generators. See below for information on the determination of the decay
|
|---|
| 1025 | modes.
|
|---|
| 1026 | <p>An object of <i>G4Decay</i> can be shared by particles.
|
|---|
| 1027 | Registration of the decay process to particles in the <tt>ConstructPhysics</tt>
|
|---|
| 1028 | method of <i>PhysicsList</i> (see <a
|
|---|
| 1029 | href="../GettingStarted/physicsDef.html#2.5.3">Section 2.5.3</a>)
|
|---|
| 1030 | is shown in Source listing 5.2.3.
|
|---|
| 1031 | </p>
|
|---|
| 1032 | <p></p>
|
|---|
| 1033 | <center>
|
|---|
| 1034 | <table border="2" cellpadding="10">
|
|---|
| 1035 | <tbody>
|
|---|
| 1036 | <tr>
|
|---|
| 1037 | <td>
|
|---|
| 1038 | <pre>#include "G4Decay.hh"<br>void ExN02PhysicsList::ConstructGeneral()<br>{<br> // Add Decay Process<br> G4Decay* theDecayProcess = new G4Decay();<br> theParticleIterator->reset();<br> while( (*theParticleIterator)() ){<br> G4ParticleDefinition* particle = theParticleIterator->value();<br> G4ProcessManager* pmanager = particle->GetProcessManager();<br> if (theDecayProcess->IsApplicable(*particle)) { <br> pmanager ->AddProcess(theDecayProcess);<br> // set ordering for PostStepDoIt and AtRestDoIt<br> pmanager ->SetProcessOrdering(theDecayProcess, idxPostStep);<br> pmanager ->SetProcessOrdering(theDecayProcess, idxAtRest);<br> }<br> }<br>}<br> </pre>
|
|---|
| 1039 | </td>
|
|---|
| 1040 | </tr>
|
|---|
| 1041 | <tr>
|
|---|
| 1042 | <td align="center"> Source listing 5.2.3<br>
|
|---|
| 1043 | Registration of the decay process to particles in the <tt>ConstructPhysics</tt>
|
|---|
| 1044 | method of <i>PhysicsList</i>.
|
|---|
| 1045 | </td>
|
|---|
| 1046 | </tr>
|
|---|
| 1047 | </tbody>
|
|---|
| 1048 | </table>
|
|---|
| 1049 | </center>
|
|---|
| 1050 | <p>
|
|---|
| 1051 | </p>
|
|---|
| 1052 | <h4>5.2.3.2 Decay Table</h4>
|
|---|
| 1053 | Each particle has its <i>G4DecayTable</i>, which stores information on
|
|---|
| 1054 | the decay modes of the particle. Each decay mode, with its branching
|
|---|
| 1055 | ratio, corresponds to an object of various ``decay channel'' classes
|
|---|
| 1056 | derived from <i>G4VDecayChannel</i>. Default decay modes are created
|
|---|
| 1057 | in the constructors of particle classes. For example, the decay table
|
|---|
| 1058 | of the neutral pion has <i>G4PhaseSpaceDecayChannel</i> and <i>G4DalitzDecayChannel</i>
|
|---|
| 1059 | as follows:
|
|---|
| 1060 | <p> </p>
|
|---|
| 1061 | <pre> // create a decay channel<br> G4VDecayChannel* mode;<br> // pi0 -> gamma + gamma<br> mode = new G4PhaseSpaceDecayChannel("pi0",0.988,2,"gamma","gamma");<br> table->Insert(mode);<br> // pi0 -> gamma + e+ + e-<br> mode = new G4DalitzDecayChannel("pi0",0.012,"e-","e+");<br> table->Insert(mode);<br> </pre>
|
|---|
| 1062 | <p>
|
|---|
| 1063 | Decay modes and branching ratios defined in Geant4 are listed in <a
|
|---|
| 1064 | href="particle.html#5.3.2">Section 5.3.2</a>.
|
|---|
| 1065 | </p>
|
|---|
| 1066 | <h4>5.2.3.3 Pre-assigned Decay Modes by Event Generators</h4>
|
|---|
| 1067 | Decays of heavy flavor particles such as B mesons are very complex,
|
|---|
| 1068 | with many varieties of decay modes and decay mechanisms. There are many
|
|---|
| 1069 | models for heavy particle decay provided by various event generators
|
|---|
| 1070 | and it is impossible to define all the decay modes of heavy particles
|
|---|
| 1071 | by using <i>G4VDecayChannel</i>. In other words, decays of heavy
|
|---|
| 1072 | particles cannot be defined by the Geant4 decay process, but should be
|
|---|
| 1073 | defined by event generators or other external packages. Geant4 provides
|
|---|
| 1074 | two ways to do this: <tt>pre-assigned decay mode</tt> and <tt>external
|
|---|
| 1075 | decayer</tt>.
|
|---|
| 1076 | <p>In the latter approach, the class <i>G4VExtDecayer</i> is used for
|
|---|
| 1077 | the interface to an external package which defines decay modes for a
|
|---|
| 1078 | particle. If an instance of <i>G4VExtDecayer</i> is attached to <i>G4Decay</i>,
|
|---|
| 1079 | daughter particles will be generated by the external decay handler. </p>
|
|---|
| 1080 | <p>In the former case, decays of heavy particles are simulated by an
|
|---|
| 1081 | event generator and the primary event contains the decay information.
|
|---|
| 1082 | <i>G4VPrimaryGenerator</i> automatically attaches any daughter
|
|---|
| 1083 | particles
|
|---|
| 1084 | to the parent particle as the PreAssignedDecayProducts member of <i>G4DynamicParticle</i>.
|
|---|
| 1085 | <i>G4Decay</i> adopts these pre-assigned daughter particles instead of
|
|---|
| 1086 | asking
|
|---|
| 1087 | <i>G4VDecayChannel</i> to generate decay products.
|
|---|
| 1088 | </p>
|
|---|
| 1089 | <p>In addition, the user may assign a <tt>pre-assigned</tt> decay time
|
|---|
| 1090 | for a specific track in its rest frame (i.e. decay time is defined in
|
|---|
| 1091 | the proper time) by using the <i>G4PrimaryParticle::SetProperTime()</i>
|
|---|
| 1092 | method. <i>G4VPrimaryGenerator</i> sets the PreAssignedDecayProperTime
|
|---|
| 1093 | member of <i>G4DynamicParticle</i>. <i>G4Decay</i> uses this decay
|
|---|
| 1094 | time instead of the life time of the particle type.
|
|---|
| 1095 | </p>
|
|---|
| 1096 | <hr><a name="5.2.4"></a>
|
|---|
| 1097 | <h2>5.2.4 Photolepton-hadron Processes</h2>
|
|---|
| 1098 | To be delivered.
|
|---|
| 1099 | <p><br>
|
|---|
| 1100 | <br>
|
|---|
| 1101 | </p>
|
|---|
| 1102 | <hr><a name="5.2.5"></a>
|
|---|
| 1103 | <h2>5.2.5 Optical Photon Processes</h2>
|
|---|
| 1104 | <p>
|
|---|
| 1105 | A photon is considered to be <i>optical</i> when its wavelength is
|
|---|
| 1106 | much
|
|---|
| 1107 | greater than the typical atomic spacing. In GEANT4 optical photons are
|
|---|
| 1108 | treated as a class of particle distinct from their higher energy <i>gamma</i>
|
|---|
| 1109 | cousins. This implementation allows the wave-like properties of
|
|---|
| 1110 | electromagnetic radiation to be incorporated into the optical photon
|
|---|
| 1111 | process. Because this theoretical description breaks down at higher
|
|---|
| 1112 | energies, there is no smooth transition as a function of energy between
|
|---|
| 1113 | the optical photon and gamma particle classes. </p>
|
|---|
| 1114 | <p>
|
|---|
| 1115 | For the simulation of optical photons to work correctly in GEANT4, they
|
|---|
| 1116 | must be imputed a linear polarization. This is unlike most other
|
|---|
| 1117 | particles in GEANT4 but is automatically and correctly done for optical
|
|---|
| 1118 | photons that are generated as secondaries by existing processes in GEANT4.
|
|---|
| 1119 | Not so, if the user wishes to start optical photons as primary particles.
|
|---|
| 1120 | In this case, the user must set the linear polarization using particle
|
|---|
| 1121 | gun methods, the General Particle Source, or his/her PrimaryGeneratorAction.
|
|---|
| 1122 | For an unpolarized source, the linear polarization should be sampled
|
|---|
| 1123 | randomly for each new primary photon.
|
|---|
| 1124 | </p>
|
|---|
| 1125 | <p>
|
|---|
| 1126 | The GEANT4 catalogue of processes at optical wavelengths includes
|
|---|
| 1127 | refraction and reflection at medium boundaries, bulk absorption and
|
|---|
| 1128 | Rayleigh scattering. Processes which produce optical photons include
|
|---|
| 1129 | the Cerenkov effect, transition radiation and scintillation. Optical
|
|---|
| 1130 | photons are generated in GEANT4 without energy conservation and their
|
|---|
| 1131 | energy must therefore not be tallied as part of the energy balance of
|
|---|
| 1132 | an event. </p>
|
|---|
| 1133 | <p>
|
|---|
| 1134 | The optical properties of the medium which are key to the
|
|---|
| 1135 | implementation of
|
|---|
| 1136 | these types of processes are stored as entries in a <tt>G4MaterialPropertiesTable</tt>
|
|---|
| 1137 | which is linked to the <tt>G4Material</tt>
|
|---|
| 1138 | in question. These properties may be constants or they may be expressed
|
|---|
| 1139 | as a function of the photon's wavelength. This table is a private data
|
|---|
| 1140 | member of the <tt>G4Material</tt> class. The <tt>G4MaterialPropertiesTable</tt>
|
|---|
| 1141 | is implemented as a hash directory, in which each entry consists of a <i>value</i>
|
|---|
| 1142 | and a <i>key</i>. The key is used to quickly and efficiently retrieve
|
|---|
| 1143 | the corresponding value. All values in the dictionary are either
|
|---|
| 1144 | instantiations of <tt>G4double</tt> or the class <tt>G4MaterialPropertyVector</tt>,
|
|---|
| 1145 | and all keys are of type <tt>G4String</tt>. </p>
|
|---|
| 1146 | <p>
|
|---|
| 1147 | A <tt>G4MaterialPropertyVector</tt> is composed of instantiations of
|
|---|
| 1148 | the class <tt>G4MPVEntry</tt>. The <tt>G4MPVEntry</tt> is a pair of
|
|---|
| 1149 | numbers, which in the case of an optical property, are the photon
|
|---|
| 1150 | momentum and
|
|---|
| 1151 | corresponding property value. The <tt>G4MaterialPropertyVector</tt> is
|
|---|
| 1152 | implemented as a <tt>G4std::vector</tt>, with the sorting operation
|
|---|
| 1153 | defined as MPVEntry<sub>1</sub> < MPVEntry<sub>2</sub> ==
|
|---|
| 1154 | photon_momentum<sub>1</sub> < photon_momentum<sub>2</sub>. This
|
|---|
| 1155 | results in all <tt>G4MaterialPropertyVector</tt>s being sorted in
|
|---|
| 1156 | ascending order of photon momenta. It is possible for the user to add
|
|---|
| 1157 | as many material
|
|---|
| 1158 | (optical) properties to the material as he wishes using the methods
|
|---|
| 1159 | supplied by the <tt>G4MaterialPropertiesTable</tt> class. An example
|
|---|
| 1160 | of this is shown in source listing 5.2.4. </p>
|
|---|
| 1161 | <center>
|
|---|
| 1162 | <table border="2" cellpadding="10">
|
|---|
| 1163 | <tbody>
|
|---|
| 1164 | <tr>
|
|---|
| 1165 | <td>
|
|---|
| 1166 | <pre>const G4int NUMENTRIES = 32;<br><br>G4double ppckov[NUMENTRIES] = {2.034*eV, ......, 4.136*eV};<br>G4double rindex[NUMENTRIES] = {1.3435, ......, 1.3608};<br>G4double absorption[NUMENTRIES] = {344.8*cm, ......, 1450.0*cm];<br><br>G4MaterialPropertiesTable *MPT = new G4MaterialPropertiesTable();<br><br>MPT -> AddConstProperty("SCINTILLATIONYIELD",100./MeV);<br><br>MPT -> AddProperty("RINDEX",ppckov,rindex,NUMENTRIES};<br>MPT -> AddProperty("ABSLENGTH",ppckov,absorption,NUMENTRIES};<br><br>scintillator -> SetMaterialPropertiesTable(MPT);<br><br></pre>
|
|---|
| 1167 | </td>
|
|---|
| 1168 | </tr>
|
|---|
| 1169 | <tr>
|
|---|
| 1170 | <td align="center"> Source listing 5.2.4<br>
|
|---|
| 1171 | Optical properties added to a <tt>G4MaterialPropertiesTable</tt> and
|
|---|
| 1172 | linked to a <tt>G4Material</tt>.
|
|---|
| 1173 | </td>
|
|---|
| 1174 | </tr>
|
|---|
| 1175 | </tbody>
|
|---|
| 1176 | </table>
|
|---|
| 1177 | </center>
|
|---|
| 1178 | <h4>5.2.5.1 Generation of Photons in <tt>processes/electromagnetic/xrays</tt>
|
|---|
| 1179 | - Cerenkov Effect</h4>
|
|---|
| 1180 | <p>
|
|---|
| 1181 | The radiation of Cerenkov light occurs when a charged particle moves
|
|---|
| 1182 | through a dispersive medium faster than the group velocity of light in
|
|---|
| 1183 | that medium. Photons are emitted on the surface of a cone, whose
|
|---|
| 1184 | opening angle with respect
|
|---|
| 1185 | to the particle's instantaneous direction decreases as the particle
|
|---|
| 1186 | slows down. At the same time, the frequency of the photons emitted
|
|---|
| 1187 | increases, and the number produced decreases. When the particle
|
|---|
| 1188 | velocity drops below the local speed of light, the radiation ceases and
|
|---|
| 1189 | the emission cone angle collapses to zero. The photons produced by this
|
|---|
| 1190 | process have an inherent
|
|---|
| 1191 | polarization perpendicular to the cone's surface at production. </p>
|
|---|
| 1192 | <p>
|
|---|
| 1193 | The flux, spectrum, polarization and emission of Cerenkov radiation in
|
|---|
| 1194 | the <tt>AlongStepDoIt</tt> method of the class <tt>G4Cerenkov</tt>
|
|---|
| 1195 | follow well-known formulae, with two inherent computational
|
|---|
| 1196 | limitations. The first arises from step-wise simulation, and the second
|
|---|
| 1197 | comes from the requirement that numerical integration calculate the
|
|---|
| 1198 | average number of Cerenkov photons per step. The process makes use of a
|
|---|
| 1199 | <tt>G4PhysicsTable</tt> which contains incremental integrals to
|
|---|
| 1200 | expedite this calculation. </p>
|
|---|
| 1201 | <p> The time and position of Cerenkov photon emission are calculated
|
|---|
| 1202 | from quantities known at the beginning of a charged particle's step.
|
|---|
| 1203 | The step is assumed to be rectilinear even in the presence of a
|
|---|
| 1204 | magnetic field. The user
|
|---|
| 1205 | may limit the step size by specifying a maximum (average) number of
|
|---|
| 1206 | Cerenkov photons created during the step, using the <tt>SetMaxNumPhotonsPerStep(const
|
|---|
| 1207 | G4int NumPhotons)</tt> method. The actual number generated will
|
|---|
| 1208 | necessarily be different due to the Poissonian nature
|
|---|
| 1209 | of the production. In the present implementation, the production
|
|---|
| 1210 | density of photons is distributed evenly along the particle's track
|
|---|
| 1211 | segment, even if the particle has slowed significantly during the step.
|
|---|
| 1212 | </p>
|
|---|
| 1213 | <p>
|
|---|
| 1214 | The frequently very large number of secondaries produced in a single
|
|---|
| 1215 | step (about 300/cm in water), compelled the idea in GEANT3.21 of
|
|---|
| 1216 | suspending the primary particle until all its progeny have been
|
|---|
| 1217 | tracked. Despite the fact that GEANT4 employs dynamic memory allocation
|
|---|
| 1218 | and thus does not suffer from the limitations of GEANT3.21 with its
|
|---|
| 1219 | fixed large initial ZEBRA store, GEANT4 nevertheless provides for an
|
|---|
| 1220 | analogous functionality with the public method <tt>SetTrackSecondariesFirst</tt>.
|
|---|
| 1221 | An example of the registration of the Cerenkov process is given in
|
|---|
| 1222 | source listing 5.2.5. </p>
|
|---|
| 1223 | <center>
|
|---|
| 1224 | <table border="2" cellpadding="10">
|
|---|
| 1225 | <tbody>
|
|---|
| 1226 | <tr>
|
|---|
| 1227 | <td>
|
|---|
| 1228 | <pre>#include "G4Cerenkov.hh"<br><br>void ExptPhysicsList::ConstructOp(){<br><br> G4Cerenkov* theCerenkovProcess = new G4Cerenkov("Cerenkov");<br><br> G4int MaxNumPhotons = 300;<br><br> theCerenkovProcess->SetTrackSecondariesFirst(true);<br> theCerenkovProcess->SetMaxNumPhotonsPerStep(MaxNumPhotons);<br><br> theParticleIterator->reset();<br> while( (*theParticleIterator)() ){<br> G4ParticleDefinition* particle = theParticleIterator->value();<br> G4ProcessManager* pmanager = particle->GetProcessManager();<br> G4String particleName = particle->GetParticleName();<br> if (theCerenkovProcess->IsApplicable(*particle)) {<br> pmanager->AddContinuousProcess(theCerenkovProcess);<br> }<br> }<br>}<br></pre>
|
|---|
| 1229 | </td>
|
|---|
| 1230 | </tr>
|
|---|
| 1231 | <tr>
|
|---|
| 1232 | <td align="center"> Source listing 5.2.5<br>
|
|---|
| 1233 | Registration of the Cerenkov process in <tt>PhysicsList</tt>.
|
|---|
| 1234 | </td>
|
|---|
| 1235 | </tr>
|
|---|
| 1236 | </tbody>
|
|---|
| 1237 | </table>
|
|---|
| 1238 | </center>
|
|---|
| 1239 | <h4>5.2.5.2 Generation of Photons in <tt>processes/electromagnetic/xrays</tt>
|
|---|
| 1240 | -
|
|---|
| 1241 | Scintillation</h4>
|
|---|
| 1242 | <p>
|
|---|
| 1243 | Every scintillating material has a characteristic light yield, <tt>SCINTILLATIONYIELD</tt>,
|
|---|
| 1244 | and an intrinsic resolution, <tt>RESOLUTIONSCALE</tt>, which generally
|
|---|
| 1245 | broadens the statistical distribution of generated photons. A wider
|
|---|
| 1246 | intrinsic resolution is due to impurities which are typical for doped
|
|---|
| 1247 | crystals like NaI(Tl) and CsI(Tl). On the other hand, the intrinsic
|
|---|
| 1248 | resolution can also be narrower when the Fano factor plays a role. The
|
|---|
| 1249 | actual number of emitted photons during a step fluctuates around the
|
|---|
| 1250 | mean number of photons with a width given by <tt>ResolutionScale*sqrt(MeanNumberOfPhotons)</tt>.
|
|---|
| 1251 | The average light yield, <tt>MeanNumberOfPhotons</tt>, has a linear
|
|---|
| 1252 | dependence on the local energy deposition, but it may be different for
|
|---|
| 1253 | minimum ionizing and non-minimum ionizing particles. </p>
|
|---|
| 1254 | <p>
|
|---|
| 1255 | A scintillator is also characterized by its photon emission spectrum
|
|---|
| 1256 | and by the exponential decay of its time spectrum. In GEANT4 the
|
|---|
| 1257 | scintillator can have a fast and a slow component. The relative
|
|---|
| 1258 | strength of the fast component as a fraction of total scintillation
|
|---|
| 1259 | yield is given by the <tt>YIELDRATIO</tt>. Scintillation may be
|
|---|
| 1260 | simulated by specifying these empirical parameters for each material.
|
|---|
| 1261 | It is sufficient to specify in the user's <tt>DetectorConstruction</tt>
|
|---|
| 1262 | class a relative spectral distribution as a function of photon energy
|
|---|
| 1263 | for the scintillating material. An example of this is shown in source
|
|---|
| 1264 | listing 5.2.6. </p>
|
|---|
| 1265 | <p>
|
|---|
| 1266 | </p>
|
|---|
| 1267 | <center>
|
|---|
| 1268 | <table border="2" cellpadding="10">
|
|---|
| 1269 | <tbody>
|
|---|
| 1270 | <tr>
|
|---|
| 1271 | <td>
|
|---|
| 1272 | <pre> const G4int NUMENTRIES = 9;<br> G4double Scnt_PP[NUMENTRIES] = { 6.6*eV, 6.7*eV, 6.8*eV, 6.9*eV,<br> 7.0*eV, 7.1*eV, 7.2*eV, 7.3*eV, 7.4*eV };<br><br> G4double Scnt_FAST[NUMENTRIES] = { 0.000134, 0.004432, 0.053991, 0.241971, <br> 0.398942, 0.000134, 0.004432, 0.053991,<br> 0.241971 };<br> G4double Scnt_SLOW[NUMENTRIES] = { 0.000010, 0.000020, 0.000030, 0.004000,<br> 0.008000, 0.005000, 0.020000, 0.001000,<br> 0.000010 };<br><br> G4Material* Scnt;<br> G4MaterialPropertiesTable* Scnt_MPT = new G4MaterialPropertiesTable();<br><br> Scnt_MPT->AddProperty("FASTCOMPONENT", Scnt_PP, Scnt_FAST, NUMENTRIES);<br> Scnt_MPT->AddProperty("SLOWCOMPONENT", Scnt_PP, Scnt_SLOW, NUMENTRIES);<br><br> Scnt_MPT->AddConstProperty("SCINTILLATIONYIELD", 5000./MeV);<br> Scnt_MPT->AddConstProperty("RESOLUTIONSCALE", 2.0);<br> Scnt_MPT->AddConstProperty("FASTTIMECONSTANT", 1.*ns);<br> Scnt_MPT->AddConstProperty("SLOWTIMECONSTANT", 10.*ns);<br> Scnt_MPT->AddConstProperty("YIELDRATIO", 0.8);<br><br> Scnt->SetMaterialPropertiesTable(Scnt_MPT);<br></pre>
|
|---|
| 1273 | </td>
|
|---|
| 1274 | </tr>
|
|---|
| 1275 | <tr>
|
|---|
| 1276 | <td align="center"> Source listing 5.2.6<br>
|
|---|
| 1277 | Specification of scintillation properties in <tt>DetectorConstruction</tt>.
|
|---|
| 1278 | </td>
|
|---|
| 1279 | </tr>
|
|---|
| 1280 | </tbody>
|
|---|
| 1281 | </table>
|
|---|
| 1282 | </center>
|
|---|
| 1283 | <p></p>
|
|---|
| 1284 | <p>
|
|---|
| 1285 | In cases where the scintillation yield of a scintillator depends on the
|
|---|
| 1286 | particle type, different scintillation processes may be defined for
|
|---|
| 1287 | them. How this yield scales to the one specified for the material is
|
|---|
| 1288 | expressed with the <tt>ScintillationYieldFactor</tt> in the user's <tt>PhysicsList</tt>
|
|---|
| 1289 | as shown in source listing 5.2.7. In those cases where the fast to slow
|
|---|
| 1290 | excitation ratio changes with particle type, the method <tt>SetScintillationExcitationRatio</tt>
|
|---|
| 1291 | can be called for each scintillation process (see the advanced
|
|---|
| 1292 | underground_physics example). This overwrites the <tt>YieldRatio</tt>
|
|---|
| 1293 | obtained from the <tt>G4MaterialPropertiesTable</tt>. </p>
|
|---|
| 1294 | <p>
|
|---|
| 1295 | </p>
|
|---|
| 1296 | <center>
|
|---|
| 1297 | <table border="2" cellpadding="10">
|
|---|
| 1298 | <tbody>
|
|---|
| 1299 | <tr>
|
|---|
| 1300 | <td>
|
|---|
| 1301 | <pre> G4Scintillation* theMuonScintProcess = new G4Scintillation("Scintillation");<br><br> theMuonScintProcess->SetTrackSecondariesFirst(true);<br> theMuonScintProcess->SetScintillationYieldFactor(0.8);<br><br> theParticleIterator->reset();<br> while( (*theParticleIterator)() ){<br> G4ParticleDefinition* particle = theParticleIterator->value();<br> G4ProcessManager* pmanager = particle->GetProcessManager();<br> G4String particleName = particle->GetParticleName();<br> if (theMuonScintProcess->IsApplicable(*particle)) {<br> if (particleName == "mu+") {<br> pmanager->AddProcess(theMuonScintProcess);<br> pmanager->SetProcessOrderingToLast(theMuonScintProcess, idxAtRest);<br> pmanager->SetProcessOrderingToLast(theMuonScintProcess, idxPostStep);<br> }<br> }<br> }<br></pre>
|
|---|
| 1302 | </td>
|
|---|
| 1303 | </tr>
|
|---|
| 1304 | <tr>
|
|---|
| 1305 | <td align="center"> Source listing 5.2.7<br>
|
|---|
| 1306 | Implementation of the scintillation process in <tt>PhysicsList</tt>.
|
|---|
| 1307 | </td>
|
|---|
| 1308 | </tr>
|
|---|
| 1309 | </tbody>
|
|---|
| 1310 | </table>
|
|---|
| 1311 | </center>
|
|---|
| 1312 | <p></p>
|
|---|
| 1313 | <p>
|
|---|
| 1314 | A Gaussian-distributed number of photons is generated according to the
|
|---|
| 1315 | energy lost during the step. A resolution scale of 1.0 produces a
|
|---|
| 1316 | statistical fluctuation around the average yield set with <tt>AddConstProperty("SCINTILLATIONYIELD")</tt>,
|
|---|
| 1317 | while values > 1 broaden the fluctuation. A value of zero produces
|
|---|
| 1318 | no fluctuation. Each photon's
|
|---|
| 1319 | frequency is sampled from the empirical spectrum. The photons originate
|
|---|
| 1320 | evenly along the track segment and are emitted uniformly into 4π with a
|
|---|
| 1321 | random linear polarization and at times characteristic for the
|
|---|
| 1322 | scintillation component. </p>
|
|---|
| 1323 | <h4>5.2.5.3 Generation of Photons in <tt>processes/optical</tt> -
|
|---|
| 1324 | Wavelength Shifting</h4>
|
|---|
| 1325 | <p>
|
|---|
| 1326 | Wavelength Shifting (WLS) fibers are used in many high-energy particle
|
|---|
| 1327 | physics
|
|---|
| 1328 | experiments. They absorb light at one wavelength and re-emit light at a
|
|---|
| 1329 | different wavelength and are used for several reasons. For one, they
|
|---|
| 1330 | tend to
|
|---|
| 1331 | decrease the self-absorption of the detector so that as much light
|
|---|
| 1332 | reaches the
|
|---|
| 1333 | PMTs as possible. WLS fibers are also used to match the emission
|
|---|
| 1334 | spectrum of
|
|---|
| 1335 | the detector with the input spectrum of the PMT.
|
|---|
| 1336 | </p>
|
|---|
| 1337 | <p>A WLS material is characterized by its photon absorption and photon
|
|---|
| 1338 | emission
|
|---|
| 1339 | spectrum and by a possible time delay between the absorption and
|
|---|
| 1340 | re-emission
|
|---|
| 1341 | of the photon. Wavelength Shifting may be simulated by specifying these
|
|---|
| 1342 | empirical parameters for each WLS material in the simulation. It is
|
|---|
| 1343 | sufficient to specify in the user's <tt>DetectorConstruction</tt>
|
|---|
| 1344 | class a
|
|---|
| 1345 | relative spectral distribution as a function of photon energy for the
|
|---|
| 1346 | WLS
|
|---|
| 1347 | material. WLSABSLENGTH is the absorption length of the material as a
|
|---|
| 1348 | function
|
|---|
| 1349 | of the photon's momentum. WLSCOMPONENT is the relative emission
|
|---|
| 1350 | spectrum of
|
|---|
| 1351 | the material as a function of the photon's momentum, and
|
|---|
| 1352 | WLSTIMECONSTANT
|
|---|
| 1353 | accounts for any time delay which may occur between absorption and
|
|---|
| 1354 | re-emission
|
|---|
| 1355 | of the photon. An example is shown in source listing 5.2.8. </p>
|
|---|
| 1356 | <p>
|
|---|
| 1357 | </p>
|
|---|
| 1358 | <center>
|
|---|
| 1359 | <table border="2" cellpadding="10">
|
|---|
| 1360 | <tbody>
|
|---|
| 1361 | <tr>
|
|---|
| 1362 | <td>
|
|---|
| 1363 | <pre> const G4int nEntries = 9;<br><br> G4double PhotonEnergy[nEntries] = { 6.6*eV, 6.7*eV, 6.8*eV, 6.9*eV,<br> 7.0*eV, 7.1*eV, 7.2*eV, 7.3*eV, 7.4*eV };<br><br> G4double RIndexFiber[nEntries] =<br> { 1.60, 1.60, 1.60, 1.60, 1.60, 1.60, 1.60, 1.60, 1.60 };<br> G4double AbsFiber[nEntries] =<br> {0.1*mm,0.2*mm,0.3*mm,0.4*cm,1.0*cm,10*cm,1.0*m,10.0*m,10.0*m};<br> G4double EmissionFiber[nEntries] =<br> {0.0, 0.0, 0.0, 0.1, 0.5, 1.0, 5.0, 10.0, 10.0 };<br><br> G4Material* WLSFiber;<br> G4MaterialPropertiesTable* MPTFiber = new G4MaterialPropertiesTable();<br><br> MPTFiber->AddProperty("RINDEX",PhotonEnergy,RIndexFiber,nEntries);<br> MPTFiber->AddProperty("WLSABSLENGTH",PhotonEnergy,AbsFiber,nEntries);<br> MPTFiber->AddProperty("WLSCOMPONENT",PhotonEnergy,EmissionFiber,nEntries);<br> MPTFiber->AddConstProperty("WLSTIMECONSTANT", 0.5*ns);<br><br> WLSFiber->SetMaterialPropertiesTable(MPTFiber);<br><br></pre>
|
|---|
| 1364 | </td>
|
|---|
| 1365 | </tr>
|
|---|
| 1366 | <tr>
|
|---|
| 1367 | <td align="center"> Source listing 5.2.8<br>
|
|---|
| 1368 | Specification of WLS properties in <tt>DetectorConstruction</tt>.
|
|---|
| 1369 | </td>
|
|---|
| 1370 | </tr>
|
|---|
| 1371 | </tbody>
|
|---|
| 1372 | </table>
|
|---|
| 1373 | </center>
|
|---|
| 1374 | <p></p>
|
|---|
| 1375 | <p>
|
|---|
| 1376 | The process is defined in the PhysicsList in the usual way. The process
|
|---|
| 1377 | class
|
|---|
| 1378 | name is G4OpWLS. It should be instantiated with
|
|---|
| 1379 | theWLSProcess = new G4OpWLS("OpWLS") and attached to the process
|
|---|
| 1380 | manager of
|
|---|
| 1381 | the optical photon as a DiscreteProcess.
|
|---|
| 1382 | The way the WLSTIMECONSTANT is used depends on the time profile method
|
|---|
| 1383 | chosen by the user. If in the PhysicsList
|
|---|
| 1384 | theWLSProcess->UseTimeGenerator("exponential") option is set, the time
|
|---|
| 1385 | delay between absorption and re-emission of the photon is sampled from
|
|---|
| 1386 | an exponential distribution, with the decay term equal to WLSTIMECONSTANT.
|
|---|
| 1387 | If, on the other hand, theWLSProcess->UseTimeGenerator("delta") is chosen,
|
|---|
| 1388 | the time delay is a delta function and equal to WLSTIMECONSTANT. The
|
|---|
| 1389 | default is "delta" in case the
|
|---|
| 1390 | G4OpWLS::UseTimeGenerator(const G4String name) method is not used.
|
|---|
| 1391 | </p>
|
|---|
| 1392 | <h4>5.2.5.4 Tracking of Photons in <tt>processes/optical</tt></h4>
|
|---|
| 1393 | <p>
|
|---|
| 1394 | <b>Absorption</b> </p>
|
|---|
| 1395 | <p>The implementation of optical photon bulk absorption, <tt>G4OpAbsorption</tt>,
|
|---|
| 1396 | is trivial in that the process merely kills the particle. The procedure
|
|---|
| 1397 | requires the user to fill the relevant <tt>G4MaterialPropertiesTable</tt>
|
|---|
| 1398 | with
|
|---|
| 1399 | empirical data for the absorption length, using <tt>ABSLENGTH</tt> as
|
|---|
| 1400 | the property key in the public method <tt>AddProperty</tt>. The
|
|---|
| 1401 | absorption length is the average distance traveled by a photon before
|
|---|
| 1402 | being absorpted by
|
|---|
| 1403 | the medium; i.e. it is the mean free path returned by the <tt>GetMeanFreePath</tt>
|
|---|
| 1404 | method. </p>
|
|---|
| 1405 | <p>
|
|---|
| 1406 | <b>Rayleigh Scattering</b>
|
|---|
| 1407 | </p>
|
|---|
| 1408 | <p>The differential cross section in Rayleigh scattering, σ/ω ,
|
|---|
| 1409 | is proportional to cos<sup>2</sup>(θ), where θ is the polar
|
|---|
| 1410 | of the new polarization vector with respect to the old polarization
|
|---|
| 1411 | vector. The <tt>G4OpRayleigh</tt> scattering process samples this
|
|---|
| 1412 | angle accordingly and then calculates the scattered photon's new
|
|---|
| 1413 | direction by requiring that it be perpendicular to the photon's new
|
|---|
| 1414 | polarization in such a way that the final direction, initial and final
|
|---|
| 1415 | polarizations are all in one plane. This process thus depends on the
|
|---|
| 1416 | particle's polarization (spin). The photon's
|
|---|
| 1417 | polarization is a data member of the <tt>G4DynamicParticle</tt> class.
|
|---|
| 1418 | </p>
|
|---|
| 1419 | <p>A photon which is not assigned a polarization at production, either
|
|---|
| 1420 | via the <tt>SetPolarization</tt> method of the <tt>G4PrimaryParticle</tt>
|
|---|
| 1421 | class, or indirectly with the <tt>SetParticlePolarization</tt> method
|
|---|
| 1422 | of the <tt>G4ParticleGun</tt> class, may not be Rayleigh scattered.
|
|---|
| 1423 | Optical photons produced by the <tt>G4Cerenkov</tt> process have
|
|---|
| 1424 | inherently a polarization perpendicular to the cone's surface at
|
|---|
| 1425 | production. Scintillation photons have a random linear polarization
|
|---|
| 1426 | perpendicular to their direction. </p>
|
|---|
| 1427 | <p>
|
|---|
| 1428 | The process requires a <tt>G4MaterialPropertiesTable</tt> to be filled
|
|---|
| 1429 | by the user with Rayleigh scattering length data. The Rayleigh
|
|---|
| 1430 | scattering attenuation length is the average distance traveled by a
|
|---|
| 1431 | photon before it is Rayleigh scattered in the medium and it is the
|
|---|
| 1432 | distance returned by the <tt>GetMeanFreePath</tt> method. The <tt>G4OpRayleigh</tt>
|
|---|
| 1433 | class provides a <tt>RayleighAttenuationLengthGenerator</tt> method
|
|---|
| 1434 | which calculates the attenuation coefficient of a medium following the
|
|---|
| 1435 | Einstein-Smoluchowski formula
|
|---|
| 1436 | whose derivation requires the use of statistical mechanics, includes
|
|---|
| 1437 | temperature, and depends on the isothermal compressibility of the
|
|---|
| 1438 | medium. This generator is convenient when the Rayleigh attenuation
|
|---|
| 1439 | length is not known from measurement but may be calculated from first
|
|---|
| 1440 | principles using the above
|
|---|
| 1441 | material constants. For a medium named <i>Water</i> and no Rayleigh
|
|---|
| 1442 | scattering attenutation length specified by the user, the program
|
|---|
| 1443 | automatically calls the
|
|---|
| 1444 | <tt>RayleighAttenuationLengthGenerator</tt></p>
|
|---|
| 1445 | which calculates it for
|
|---|
| 1446 | 10 degrees Celsius liquid water.
|
|---|
| 1447 | <p></p>
|
|---|
| 1448 | <p>
|
|---|
| 1449 | <b>Boundary Process</b>
|
|---|
| 1450 | </p>
|
|---|
| 1451 | <p>[E. Hecht and A. Zajac, Optics, Addison-Wesley Publishing Co., pp.
|
|---|
| 1452 | 71-80
|
|---|
| 1453 | and pp. 244-246, 1974.]</p>
|
|---|
| 1454 | <p> For the simple case of a perfectly smooth interface between two
|
|---|
| 1455 | dielectric materials, all the user needs to provide are the refractive
|
|---|
| 1456 | indices of the two materials stored in their respective <tt>G4MaterialPropertiesTable</tt>.
|
|---|
| 1457 | In all other cases, the optical boundary process design relies on the
|
|---|
| 1458 | concept of <i>surfaces</i>. The information is split into two classes.
|
|---|
| 1459 | One class
|
|---|
| 1460 | in the material category keeps information about the physical
|
|---|
| 1461 | properties of the surface itself, and a second class in the geometry
|
|---|
| 1462 | category holds pointers to the relevant physical and logical volumes
|
|---|
| 1463 | involved and has an association
|
|---|
| 1464 | to the physical class. Surface objects of the second type are stored in
|
|---|
| 1465 | a related table and can be retrieved by either specifying the two
|
|---|
| 1466 | ordered pairs of physical volumes touching at the surface, or by the
|
|---|
| 1467 | logical volume entirely surrounded by this surface. The former is
|
|---|
| 1468 | called a <i>border surface</i> while the latter is referred to as the <i>skin
|
|---|
| 1469 | surface</i>. This second type of surface is useful in situations where
|
|---|
| 1470 | a volume is coded with a reflector and is placed into many different
|
|---|
| 1471 | mother volumes. A limitation is that the skin surface can only have one
|
|---|
| 1472 | and the same optical property for all of the
|
|---|
| 1473 | enclosed volume's sides. The border surface is an ordered pair of
|
|---|
| 1474 | physical volumes, so in principle, the user can choose different
|
|---|
| 1475 | optical properties for photons arriving from the reverse side of the
|
|---|
| 1476 | same interface. For the optical boundary process to use a border
|
|---|
| 1477 | surface, the two volumes must have been positioned with <tt>G4PVPlacement</tt>.
|
|---|
| 1478 | The ordered combination can exist at many places in the simulation.
|
|---|
| 1479 | When the surface concept is not needed, and a perfectly smooth surface
|
|---|
| 1480 | exists beteen two dielectic materials, the only relevant property is
|
|---|
| 1481 | the index of refraction, a quantity stored with the material, and no
|
|---|
| 1482 | restriction exists on how the volumes were positioned. </p>
|
|---|
| 1483 | <p>
|
|---|
| 1484 | The physical surface object also specifies which model the boundary
|
|---|
| 1485 | process should use to simulate interactions with that surface. In
|
|---|
| 1486 | addition, the physical surface can have a material property table all
|
|---|
| 1487 | its own. The usage of this table allows all specular constants to be
|
|---|
| 1488 | wavelength dependent. In case the surface is painted or wrapped (but
|
|---|
| 1489 | not a cladding), the table may include the thin layer's index of
|
|---|
| 1490 | refraction. This allows the simulation of boundary effects at the
|
|---|
| 1491 | intersection between the medium and the surface layer, as well as the
|
|---|
| 1492 | Lambertian reflection at the far side of the thin layer. This occurs
|
|---|
| 1493 | within the process itself and does not invoke the <tt>G4Navigator</tt>.
|
|---|
| 1494 | Combinations of surface finish properties, such as <i>polished</i> or <i>ground</i>
|
|---|
| 1495 | and <i>front painted</i> or <i>back painted</i>, enumerate the
|
|---|
| 1496 | different situations which can be simulated. </p>
|
|---|
| 1497 | <p>
|
|---|
| 1498 | When a photon arrives at a medium boundary its behavior depends on the
|
|---|
| 1499 | nature of the two materials that join at that boundary. Medium
|
|---|
| 1500 | boundaries may be formed between two dielectric materials or a
|
|---|
| 1501 | dielectric and a metal. In the case of two dielectric materials, the
|
|---|
| 1502 | photon can undergo total internal reflection, refraction or reflection,
|
|---|
| 1503 | depending on the photon's wavelength, angle of incidence, and the
|
|---|
| 1504 | refractive indices on both sides of the boundary.
|
|---|
| 1505 | Furthermore, reflection and transmission probabilites are sensitive to
|
|---|
| 1506 | the state of linear polarization. In the case of an interface between a
|
|---|
| 1507 | dielectric and a metal, the photon can be absorbed by the metal or
|
|---|
| 1508 | reflected
|
|---|
| 1509 | back into the dielectric. If the photon is absorbed it can be detected
|
|---|
| 1510 | according to the photoelectron efficiency of the metal. </p>
|
|---|
| 1511 | <p>
|
|---|
| 1512 | As expressed in Maxwell's equations, Fresnel reflection and refraction
|
|---|
| 1513 | are
|
|---|
| 1514 | intertwined through their relative probabilities of occurrence.
|
|---|
| 1515 | Therefore neither of these processes, nor total internal reflection,
|
|---|
| 1516 | are viewed as individual processes deserving separate class
|
|---|
| 1517 | implementation. Nonetheless, an attempt was made to adhere to the
|
|---|
| 1518 | abstraction of having independent processes by splitting the code into
|
|---|
| 1519 | different methods where practicable. </p>
|
|---|
| 1520 | <p>
|
|---|
| 1521 | One implementation of the <tt>G4OpBoundaryProcess</tt> class employs
|
|---|
| 1522 | the <a
|
|---|
| 1523 | href="http://geant4.slac.stanford.edu/UsersWorkshop/G4Lectures/Peter/moisan.ps">
|
|---|
| 1524 | UNIFIED model</a> [A. Levin and C. Moisan, A More Physical Approach to
|
|---|
| 1525 | Model the Surface Treatment of Scintillation Counters and its
|
|---|
| 1526 | Implementation into DETECT, TRIUMF Preprint TRI-PP-96-64, Oct. 1996] of
|
|---|
| 1527 | the DETECT program [G.F. Knoll, T.F. Knoll and T.M. Henderson, Light
|
|---|
| 1528 | Collection Scintillation Detector Composites for Neutron Detection,
|
|---|
| 1529 | IEEE
|
|---|
| 1530 | Trans. Nucl. Sci., 35 (1988) 872.]. It applies to dielectric-dielectric
|
|---|
| 1531 | interfaces and tries to provide a realistic simulation, which deals
|
|---|
| 1532 | with all aspects of surface finish and reflector coating. The surface
|
|---|
| 1533 | may be assumed as smooth and covered with a metallized coating
|
|---|
| 1534 | representing a specular reflector with given reflection coefficient, or
|
|---|
| 1535 | painted with a diffuse reflecting material where Lambertian reflection
|
|---|
| 1536 | occurs. The surfaces may or may not be in optical contact with another
|
|---|
| 1537 | component and most importantly, one may consider a surface to be made
|
|---|
| 1538 | up of micro-facets with normal vectors that follow given distributions
|
|---|
| 1539 | around the nominal normal for the volume at the impact point. For very
|
|---|
| 1540 | rough surfaces, it is possible for the photon to inversely aim at the
|
|---|
| 1541 | same surface again after reflection of refraction and so multiple
|
|---|
| 1542 | interactions with the boundary are possible within the process itself
|
|---|
| 1543 | and without the need for relocation by <tt>G4Navigator</tt>. </p>
|
|---|
| 1544 | <p>
|
|---|
| 1545 | The UNIFIED model provides for a range of different reflection
|
|---|
| 1546 | mechanisms. The specular lobe constant represents the reflection
|
|---|
| 1547 | probability about the normal of a micro facet. The specular spike
|
|---|
| 1548 | constant, in turn, illustrates
|
|---|
| 1549 | the probability of reflection about the average surface normal. The
|
|---|
| 1550 | diffuse lobe constant is for the probability of internal Lambertian
|
|---|
| 1551 | reflection, and finally the back-scatter spike constant is for the case
|
|---|
| 1552 | of several reflections within a deep groove with the ultimate result of
|
|---|
| 1553 | exact
|
|---|
| 1554 | back-scattering. The four probabilities must add up to one, with the
|
|---|
| 1555 | diffuse lobe constant being implicit. The reader may consult the
|
|---|
| 1556 | reference for a thorough description of the model. </p>
|
|---|
| 1557 | <p>
|
|---|
| 1558 | </p>
|
|---|
| 1559 | <center>
|
|---|
| 1560 | <table border="2" cellpadding="10">
|
|---|
| 1561 | <tbody>
|
|---|
| 1562 | <tr>
|
|---|
| 1563 | <td>
|
|---|
| 1564 | <pre>G4VPhysicalVolume* volume1;<br>G4VPhysicalVolume* volume2;<br><br>G4OpticalSurface* OpSurface = new G4OpticalSurface("name");<br><br>G4LogicalBorderSurface* Surface = new<br> G4LogicalBorderSurface("name",volume1,volume2,OpSurface);<br><br>G4double sigma_alpha = 0.1;<br><br>OpSurface -> SetType(dielectric_dielectric);<br>OpSurface -> SetModel(unified);<br>OpSurface -> SetFinish(groundbackpainted);<br>OpSurface -> SetSigmaAlpha(sigma_alpha);<br><br>const G4int NUM = 2;<br><br>G4double pp[NUM] = {2.038*eV, 4.144*eV};<br>G4double specularlobe[NUM] = {0.3, 0.3};<br>G4double specularspike[NUM] = {0.2, 0.2};<br>G4double backscatter[NUM] = {0.1, 0.1};<br>G4double rindex[NUM] = {1.35, 1.40};<br>G4double reflectivity[NUM] = {0.3, 0.5};<br>G4double efficiency[NUM] = {0.8, 0.1};<br><br>G4MaterialPropertiesTable* SMPT = new G4MaterialPropertiesTable();<br><br>SMPT -> AddProperty("RINDEX",pp,rindex,NUM);<br>SMPT -> AddProperty("SPECULARLOBECONSTANT",pp,specularlobe,NUM);<br>SMPT -> AddProperty("SPECULARSPIKECONSTANT",pp,specularspike,NUM);<br>SMPT -> AddProperty("BACKSCATTERCONSTANT",pp,backscatter,NUM);<br>SMPT -> AddProperty("REFLECTIVITY",pp,reflectivity,NUM);<br>SMPT -> AddProperty("EFFICIENCY",pp,efficiency,NUM);<br><br>OpSurface -> SetMaterialPropertiesTable(SMPT);<br></pre>
|
|---|
| 1565 | </td>
|
|---|
| 1566 | </tr>
|
|---|
| 1567 | <tr>
|
|---|
| 1568 | <td align="center"> Source listing 5.2.9<br>
|
|---|
| 1569 | Dielectric-dielectric surface properties defined via the <i>G4OpticalSurface</i>.
|
|---|
| 1570 | </td>
|
|---|
| 1571 | </tr>
|
|---|
| 1572 | </tbody>
|
|---|
| 1573 | </table>
|
|---|
| 1574 | </center>
|
|---|
| 1575 | <p></p>
|
|---|
| 1576 | The original <a
|
|---|
| 1577 | href="http://cern.ch/wwwasdoc/geant_html3/node231.html#SECTION09700000000000000000000">GEANT3.21
|
|---|
| 1578 | implementation</a>
|
|---|
| 1579 | of this process is also available via the GLISUR methods flag. [GEANT
|
|---|
| 1580 | Detector Description and Simulation Tool, Application Software Group,
|
|---|
| 1581 | Computing and Networks Division, CERN, PHYS260-6 tp 260-7.].
|
|---|
| 1582 | <p></p>
|
|---|
| 1583 | <p></p>
|
|---|
| 1584 | <center>
|
|---|
| 1585 | <table border="2" cellpadding="10">
|
|---|
| 1586 | <tbody>
|
|---|
| 1587 | <tr>
|
|---|
| 1588 | <td>
|
|---|
| 1589 | <pre>G4LogicalVolume* volume_log;<br><br>G4OpticalSurface* OpSurface = new G4OpticalSurface("name");<br><br>G4LogicalSkinSurface* Surface = new<br> G4LogicalSkinSurface("name",volume_log,OpSurface);<br><br>OpSurface -> SetType(dielectric_metal);<br>OpSurface -> SetFinish(ground);<br>OpSurface -> SetModel(glisur);<br><br>G4double polish = 0.8;<br><br>G4MaterialPropertiesTable *OpSurfaceProperty = new G4MaterialPropertiesTable();<br><br>OpSurfaceProperty -> AddProperty("REFLECTIVITY",pp,reflectivity,NUM);<br>OpSurfaceProperty -> AddProperty("EFFICIENCY",pp,efficiency,NUM);<br><br>OpSurface -> SetMaterialPropertiesTable(OpSurfaceProperty);<br></pre>
|
|---|
| 1590 | </td>
|
|---|
| 1591 | </tr>
|
|---|
| 1592 | <tr>
|
|---|
| 1593 | <td align="center"> Source listing 5.2.10<br>
|
|---|
| 1594 | Dielectric metal surface properties defined via the <i>G4OpticalSurface</i>.
|
|---|
| 1595 | </td>
|
|---|
| 1596 | </tr>
|
|---|
| 1597 | </tbody>
|
|---|
| 1598 | </table>
|
|---|
| 1599 | </center>
|
|---|
| 1600 | <p></p>
|
|---|
| 1601 | <p> The program defaults to the GLISUR model and <i>polished</i>
|
|---|
| 1602 | surface finish when no specific model and surface finish is specified
|
|---|
| 1603 | by the user. In the case of a dielectric-metal interface, or when the
|
|---|
| 1604 | GLISUR model is specified, the only surface finish options available
|
|---|
| 1605 | are <i>polished</i> or <i>ground</i>.
|
|---|
| 1606 | For dielectric-metal surfaces, the <tt>G4OpBoundaryProcess</tt> also
|
|---|
| 1607 | defaults to unit reflectivity and zero detection efficiency. In cases
|
|---|
| 1608 | where the user specifies the UNIFIED model, but does not otherwise
|
|---|
| 1609 | specify the model reflection probability constants, the default becomes
|
|---|
| 1610 | Lambertian reflection.</p>
|
|---|
| 1611 | <p>
|
|---|
| 1612 | <br>
|
|---|
| 1613 | <br>
|
|---|
| 1614 | </p>
|
|---|
| 1615 | <hr><a name="5.2.6"></a>
|
|---|
| 1616 | <h2>5.2.6 Parameterization</h2>
|
|---|
| 1617 | In this section we describe how to use the parameterization or
|
|---|
| 1618 | "fast simulation" facilities of GEANT4. Examples are provided in the
|
|---|
| 1619 | <b>examples/novice/N05 directory</b>.
|
|---|
| 1620 | <p><b>5.2.6.1 Generalities:</b> <br>
|
|---|
| 1621 | </p>
|
|---|
| 1622 | <p>The Geant4 parameterization facilities allow you to shortcut the detailed
|
|---|
| 1623 | tracking in a given volume and for given particle types in order for you
|
|---|
| 1624 | to provide your own implementation of the physics and of the detector
|
|---|
| 1625 | response.
|
|---|
| 1626 | <p>
|
|---|
| 1627 | Parameterisations are bound to a <b><code>G4Region</code></b> object, which,
|
|---|
| 1628 | in the case of fast simulation is also called an <b>envelope</b>.
|
|---|
| 1629 | Prior to release 8.0, parameterisations were bound to a
|
|---|
| 1630 | <code>G4LogicalVolume</code>, the root of a volume hierarchy. These root
|
|---|
| 1631 | volumes are now attributes of the <code>G4Region</code>.
|
|---|
| 1632 | Envelopes often correspond to the volumes of sub-detectors: electromagnetic
|
|---|
| 1633 | calorimeters, tracking chambers, etc. With GEANT4 it is also possible to
|
|---|
| 1634 | define envelopes by overlaying a parallel or "ghost" geometry as
|
|---|
| 1635 | discussed in section 5.2.6.7.
|
|---|
| 1636 |
|
|---|
| 1637 | <br><br>
|
|---|
| 1638 | In GEANT4, parameterisations have three main features. You must specify:
|
|---|
| 1639 | </p>
|
|---|
| 1640 | <ul>
|
|---|
| 1641 | <li>the particle types for which your parameterisation is valid;</li>
|
|---|
| 1642 | <li>the dynamics conditions for which your parameterisation is valid
|
|---|
| 1643 | and must be triggered;</li>
|
|---|
| 1644 | <li>the parameterisation itself: where the primary will be killed or
|
|---|
| 1645 | moved, whether or not to create it or create secondaries, etc., and
|
|---|
| 1646 | where the detector response will be computed.</li>
|
|---|
| 1647 | </ul>
|
|---|
| 1648 |
|
|---|
| 1649 | <p>
|
|---|
| 1650 | GEANT4 will message your parameterisation code for each step starting
|
|---|
| 1651 | in any root G4LogicalVolume (including daughters. sub-daughters, etc. of this
|
|---|
| 1652 | volume) of the <code>G4Region</code>. It will proceed by first asking the
|
|---|
| 1653 | available parameterisations for the current particle type if one of them (and
|
|---|
| 1654 | only one) wants to issue a trigger. If so it will invoke its parameterisation.
|
|---|
| 1655 | In this case, the tracking <b><i>will not apply physics</i></b> to the
|
|---|
| 1656 | particle in the step. Instead, the UserSteppingAction will be invoked.
|
|---|
| 1657 | <br><br>
|
|---|
| 1658 | Parameterisations look like a "user stepping action" but are
|
|---|
| 1659 | more advanced because: </p>
|
|---|
| 1660 | <ul>
|
|---|
| 1661 | <li>parameterisation code is messaged only in the <code>G4Region</code> to
|
|---|
| 1662 | which it is bound;</li>
|
|---|
| 1663 | <li>parameterisation code is messaged anywhere in the <code>G4Region</code>,
|
|---|
| 1664 | that is, any volume in which the track is located;</li>
|
|---|
| 1665 | <li>GEANT4 will provide information to your parameterisation code about the
|
|---|
| 1666 | current root volume of the <code>G4Region</code> in which the track is
|
|---|
| 1667 | travelling.</li>
|
|---|
| 1668 | </ul>
|
|---|
| 1669 |
|
|---|
| 1670 | <p>
|
|---|
| 1671 | <b>5.2.6.2 Overview of Parameterisation Components</b> <br>
|
|---|
| 1672 | </p>
|
|---|
| 1673 | <p>The GEANT4 components which allow the implementation and control of
|
|---|
| 1674 | parameterisations are:
|
|---|
| 1675 | </p>
|
|---|
| 1676 | <ul>
|
|---|
| 1677 | <li><code><b>G4VFastSimulationModel</b></code> This is the abstract class for
|
|---|
| 1678 | the implementation of parameterisations. You must inherit from it to
|
|---|
| 1679 | implement your concrete parameterisation model.<br><br>
|
|---|
| 1680 | </li>
|
|---|
| 1681 | <li><code><b>G4FastSimulationManager</b></code> The G4VFastSimulationModel
|
|---|
| 1682 | objects are attached to the <tt>G4Region</tt> through a
|
|---|
| 1683 | G4FastSimulationManager. This object will manage the list of models and
|
|---|
| 1684 | will message them at tracking time.<br><br>
|
|---|
| 1685 | </li>
|
|---|
| 1686 |
|
|---|
| 1687 | <li><code><b>G4Region/Envelope</b></code> As mentioned before, an envelope
|
|---|
| 1688 | in GEANT4 is a <code><b>G4Region</b></code>. The parameterisation is
|
|---|
| 1689 | bound to the <code>G4Region</code> by setting a
|
|---|
| 1690 | <code>G4FastSimulationManager</code> pointer to it.<br><br>
|
|---|
| 1691 |
|
|---|
| 1692 | The figure below shows how the <code>G4VFastSimulationModel</code> and
|
|---|
| 1693 | <code>G4FastSimulationManager</code> objects are bound to the
|
|---|
| 1694 | <code>G4Region</code>. Then for all root G4LogicalVolume's held by the
|
|---|
| 1695 | G4Region, the fast simulation code is active.<br><br>
|
|---|
| 1696 |
|
|---|
| 1697 | <img src="physicsProcessPARAM.src/ComponentsWithRegion.gif" height="291" width="606"> <br>
|
|---|
| 1698 | </li>
|
|---|
| 1699 |
|
|---|
| 1700 | <li><code><b>G4FastSimulationManagerProcess</b></code> This is a
|
|---|
| 1701 | <code>G4VProcess</code>. It provides the interface between the tracking
|
|---|
| 1702 | and the parameterisation. It must be set in the process list of the
|
|---|
| 1703 | particles you want to parameterise.<br><br></li>
|
|---|
| 1704 |
|
|---|
| 1705 | <li><code><b>G4GlobalFastSimulationManager</b></code> This a singleton class
|
|---|
| 1706 | which provides the management of the <code>G4FastSimulationManager</code>
|
|---|
| 1707 | objects and some ghost facilities.</li>
|
|---|
| 1708 | </ul>
|
|---|
| 1709 | <br>
|
|---|
| 1710 | <p>
|
|---|
| 1711 | <b>5.2.6.3 The <code>G4VFastSimulationModel</code> Abstract Class</b>
|
|---|
| 1712 | </p>
|
|---|
| 1713 | <ul>
|
|---|
| 1714 | <li><b>Constructors:</b><br><br>
|
|---|
| 1715 | The <code>G4VFastSimulationModel</code> class has two constructors. The
|
|---|
| 1716 | second one allows you to get started quickly:<br><br>
|
|---|
| 1717 | <ul>
|
|---|
| 1718 | <li><b><code>G4VFastSimulationModel<i>(const G4String& aName</i>):</code></b>
|
|---|
| 1719 | Here <code>aName</code> identifies the parameterisation model.
|
|---|
| 1720 | <br><br></li>
|
|---|
| 1721 | <li><b><code>G4VFastSimulationModel(<i>const G4String& aName, G4Region*, G4bool IsUnique=false</i>):</code></b>
|
|---|
| 1722 | In addition to the model name, this constructor accepts a G4Region
|
|---|
| 1723 | pointer. The needed G4FastSimulationManager object is constructed
|
|---|
| 1724 | if necessary, passing to it the G4Region pointer and the boolean
|
|---|
| 1725 | value. If it already exists, the model is simply added to this
|
|---|
| 1726 | manager. Note that the <i>G4VFastSimulationModel object will not keep
|
|---|
| 1727 | track of the G4Region passed in the constructor</i>.<br>
|
|---|
| 1728 | The boolean argument is there for optimization purposes: if you know
|
|---|
| 1729 | that the G4Region has a unique root G4LogicalVolume, uniquely placed,
|
|---|
| 1730 | you can set the boolean value to "true".<br><br>
|
|---|
| 1731 | </li>
|
|---|
| 1732 | </ul>
|
|---|
| 1733 | </li>
|
|---|
| 1734 | <li><b>Virtual methods:</b><br><br>
|
|---|
| 1735 | The G4VFastSimulationModel has three pure virtual methods which must
|
|---|
| 1736 | be overriden in your concrete class:<br>
|
|---|
| 1737 | <br>
|
|---|
| 1738 | </li>
|
|---|
| 1739 | <ul>
|
|---|
| 1740 | <li><b><code>G4VFastSimulationModel<i>(const G4String& aName</i>):</code></b>
|
|---|
| 1741 | Here aName identifies the parameterisation model.<br>
|
|---|
| 1742 | <br>
|
|---|
| 1743 | </li>
|
|---|
| 1744 |
|
|---|
| 1745 | <li><b><code>G4bool ModelTrigger(<i>const G4FastTrack&</i>):</code></b>
|
|---|
| 1746 | You must return "true" when the dynamic conditions to trigger
|
|---|
| 1747 | your parameterisation are fulfilled. <br>
|
|---|
| 1748 | G4FastTrack provides access to the current G4Track, gives simple
|
|---|
| 1749 | access to the current root G4LogicalVolume related features (its
|
|---|
| 1750 | G4VSolid, and G4AffineTransform references between the global and the
|
|---|
| 1751 | root G4LogicalVolume local coordinates systems) and simple access to
|
|---|
| 1752 | the position and momentum expressed in the root G4LogicalVolume
|
|---|
| 1753 | coordinate system. Using these quantities
|
|---|
| 1754 | and the G4VSolid methods, you can for example easily check how
|
|---|
| 1755 | far you are from the root G4LogicalVolume boundary.
|
|---|
| 1756 | <br>
|
|---|
| 1757 | </li>
|
|---|
| 1758 | </ul>
|
|---|
| 1759 | </li>
|
|---|
| 1760 | <li><b>Virtual methods:</b><br>
|
|---|
| 1761 | <br>
|
|---|
| 1762 | The G4VFastSimulationModel has three pure virtual methods which must be
|
|---|
| 1763 | overriden in your concrete class:<br>
|
|---|
| 1764 | <br>
|
|---|
| 1765 | </li>
|
|---|
| 1766 | <ul>
|
|---|
| 1767 | <li><b><code>G4bool IsApplicable(<i>const G4ParticleDefinition&</i>):</code></b>
|
|---|
| 1768 | In your implementation, you must return "true" when your model is
|
|---|
| 1769 | applicable to the G4ParticleDefinition passed to this method. The
|
|---|
| 1770 | G4ParticleDefinition provides all intrinsic particle information (mass,
|
|---|
| 1771 | charge, spin, name ...).<br>
|
|---|
| 1772 | <br>
|
|---|
| 1773 | If you want to implement a model which is valid only for certain
|
|---|
| 1774 | particle types, it is recommended for efficiency that you use the
|
|---|
| 1775 | static pointer of the corresponding particle classes.<br>
|
|---|
| 1776 | As an example, in a model valid for <i>gamma</i>s only, the
|
|---|
| 1777 | IsApplicable() method should take the form:
|
|---|
| 1778 | <pre>#include "G4Gamma.hh"<br>G4bool MyGammaModel::IsApplicable(const G4ParticleDefinition& partDef)<br>{<br> return &partDef == G4Gamma::GammaDefinition();<br>}<br> </pre>
|
|---|
| 1779 | </li>
|
|---|
| 1780 | <li><b><code>G4bool ModelTrigger(<i>const G4FastTrack&</i>):</code></b>
|
|---|
| 1781 | You must return "true" when the dynamic conditions to trigger your
|
|---|
| 1782 | parameterisation are fulfilled. <br>
|
|---|
| 1783 | The G4FastTrack provides access to the current G4Track, gives simple
|
|---|
| 1784 | access to envelope related features (G4LogicalVolume, G4VSolid, and
|
|---|
| 1785 | G4AffineTransform references between the global and the envelope local
|
|---|
| 1786 | coordinates systems) and simple access to the position and momentum
|
|---|
| 1787 | expressed in the envelope coordinate system. Using these quantities and
|
|---|
| 1788 | the G4VSolid methods, you can for example easily check how far you are
|
|---|
| 1789 | from the envelope boundary. <br>
|
|---|
| 1790 | <br>
|
|---|
| 1791 | </li>
|
|---|
| 1792 | <li><b><code>void DoIt(<i>const G4FastTrack&, G4FastStep&</i>):</code></b>
|
|---|
| 1793 | The details of your parameterisation will be implemented in this
|
|---|
| 1794 | method. The G4FastTrack reference provides the input information, and
|
|---|
| 1795 | the final state of the particles after parameterisation must be
|
|---|
| 1796 | returned through the G4FastStep reference. Tracking for the final state
|
|---|
| 1797 | particles is requested after your parameterisation has been invoked.<br>
|
|---|
| 1798 | <br>
|
|---|
| 1799 | </li>
|
|---|
| 1800 | </ul>
|
|---|
| 1801 | </ul>
|
|---|
| 1802 | <p>
|
|---|
| 1803 | <b>5.2.6.4 The <code>G4FastSimulationManager</code> Class:</b>
|
|---|
| 1804 | </p>
|
|---|
| 1805 | G4FastSimulationManager functionnalities regarding the use of ghost volumes
|
|---|
| 1806 | are explained in section 5.2.6.7.
|
|---|
| 1807 | <ul>
|
|---|
| 1808 | <li><b>Constructor:</b><br><br>
|
|---|
| 1809 | <ul>
|
|---|
| 1810 | <li><code><b>G4FastSimulationManager(<i>G4Region *anEnvelope, G4bool IsUnique=false</i>):</b></code>
|
|---|
| 1811 | This is the only constructor. You specify the G4Region by
|
|---|
| 1812 | providing its pointer. The G4FastSimulationManager
|
|---|
| 1813 | object will bind itself to this G4Region. If you know that this
|
|---|
| 1814 | G4Region has a single root G4LogicalVolume, placed only once, you
|
|---|
| 1815 | can set the IsUnique boolean to
|
|---|
| 1816 | "true" to allow some optimization.<br>
|
|---|
| 1817 | Note that if you choose to use the
|
|---|
| 1818 | G4VFastSimulationModel(const G4String&, G4Region*, G4bool)
|
|---|
| 1819 | constructor for your model, the G4FastSimulationManager will be
|
|---|
| 1820 | constructed using the given G4Region* and G4bool values of
|
|---|
| 1821 | the model constructor.<br><br>
|
|---|
| 1822 | </li>
|
|---|
| 1823 | </ul>
|
|---|
| 1824 | </li>
|
|---|
| 1825 | <li><b>G4VFastSimulationModel object management:</b><br><br>
|
|---|
| 1826 | The following two methods provide the usual management functions.
|
|---|
| 1827 | <br><br>
|
|---|
| 1828 | <ul>
|
|---|
| 1829 | <li><code><b>void AddFastSimulationModel(G4VFastSimulationModel*)</b></code></li>
|
|---|
| 1830 | <li><code><b>RemoveFastSimulationModel(G4VFastSimulationModel*)</b></code><br>
|
|---|
| 1831 | </li>
|
|---|
| 1832 | </ul>
|
|---|
| 1833 | </li>
|
|---|
| 1834 | <br>
|
|---|
| 1835 | <li><b>Interface with the G4FastSimulationManagerProcess:</b><br><br>
|
|---|
| 1836 | This is described in the User's Guide for Toolkit Developers
|
|---|
| 1837 | (section 3.9.6)
|
|---|
| 1838 | </li>
|
|---|
| 1839 | </ul>
|
|---|
| 1840 |
|
|---|
| 1841 |
|
|---|
| 1842 | <p>
|
|---|
| 1843 | <b>5.2.6.5 The <code>G4FastSimulationManagerProcess</code> Class</b>
|
|---|
| 1844 | </p>
|
|---|
| 1845 | This G4VProcess serves as an interface between the tracking and the
|
|---|
| 1846 | parameterisation. At tracking time, it collaborates with the
|
|---|
| 1847 | G4FastSimulationManager of the current volume, if any, to allow the
|
|---|
| 1848 | models to trigger. If no manager exists or if no model issues a
|
|---|
| 1849 | trigger, the tracking goes on normally.
|
|---|
| 1850 | <p><em>In the present implementation, you must set this process in the
|
|---|
| 1851 | G4ProcessManager of the particles you parameterise to enable your
|
|---|
| 1852 | parameterisation.</em>
|
|---|
| 1853 | <p>
|
|---|
| 1854 |
|
|---|
| 1855 | <p>
|
|---|
| 1856 | The processes ordering is:
|
|---|
| 1857 | <pre> [n-3] ...
|
|---|
| 1858 | [n-2] Multiple Scattering
|
|---|
| 1859 | [n-1] G4FastSimulationManagerProcess
|
|---|
| 1860 | [ n ] G4Transportation
|
|---|
| 1861 | </pre>
|
|---|
| 1862 | This ordering is important if you use ghost geometries, since the
|
|---|
| 1863 | G4FastSimulationManagerProcess will provide navigation in the ghost world to
|
|---|
| 1864 | limit the step on ghost boundaries.<br><br>
|
|---|
| 1865 | The G4FastSimulationManager must be added to the process list of a particle
|
|---|
| 1866 | as a continuous and discrete process if you use ghost geometries for this
|
|---|
| 1867 | particle. You can add it as a discrete process if you don't use ghosts.<br>
|
|---|
| 1868 | The following code registers the G4FastSimulationManagerProcess with all the
|
|---|
| 1869 | particles as a discrete and continuous process:
|
|---|
| 1870 | <pre>void MyPhysicsList::addParameterisation()
|
|---|
| 1871 | {
|
|---|
| 1872 | G4FastSimulationManagerProcess*
|
|---|
| 1873 | theFastSimulationManagerProcess = new G4FastSimulationManagerProcess();
|
|---|
| 1874 | theParticleIterator->reset();
|
|---|
| 1875 | while( (*theParticleIterator)() )
|
|---|
| 1876 | {
|
|---|
| 1877 | G4ParticleDefinition* particle = theParticleIterator->value();
|
|---|
| 1878 | G4ProcessManager* pmanager = particle->GetProcessManager();
|
|---|
| 1879 | pmanager->AddProcess(theFastSimulationManagerProcess, -1, 0, 0);
|
|---|
| 1880 | }
|
|---|
| 1881 | }
|
|---|
| 1882 | </pre>
|
|---|
| 1883 | <br>
|
|---|
| 1884 | <p>
|
|---|
| 1885 |
|
|---|
| 1886 | <b>5.2.6.6 The <code>G4GlobalFastSimulationManager</code> Singleton Class</b>
|
|---|
| 1887 | </p>
|
|---|
| 1888 | This class is a singleton which can be accessed as follows:<br><br>
|
|---|
| 1889 |
|
|---|
| 1890 | <pre>#include "G4GlobalFastSimulationManager.hh"
|
|---|
| 1891 | ...
|
|---|
| 1892 | ...
|
|---|
| 1893 | G4GlobalFastSimulationManager* globalFSM;
|
|---|
| 1894 | globalFSM = G4GlobalFastSimulationManager::getGlobalFastSimulationManager();
|
|---|
| 1895 | ...
|
|---|
| 1896 | ...
|
|---|
| 1897 | </pre>
|
|---|
| 1898 |
|
|---|
| 1899 | Presently, you will mainly need to use the GlobalFastSimulationManager if you
|
|---|
| 1900 | use ghost geometries.<br><br><br>
|
|---|
| 1901 |
|
|---|
| 1902 |
|
|---|
| 1903 | <p>
|
|---|
| 1904 | <b>5.2.6.7 Parameterisation Using Ghost Geometries</b>
|
|---|
| 1905 | </p>
|
|---|
| 1906 | In some cases, volumes of the tracking geometry do not allow envelopes to be
|
|---|
| 1907 | defined. This may be the case with a geometry coming from a CAD system. Since
|
|---|
| 1908 | such a geometry is flat, a parallel geometry must be used to define the
|
|---|
| 1909 | envelopes.<br>
|
|---|
| 1910 | Another interesting case involves defining an envelope which groups the
|
|---|
| 1911 | electromagnetic and hadronic calorimeters of a detector into one volume.
|
|---|
| 1912 | This may be useful when parameterizing the interaction of charged pions.
|
|---|
| 1913 | You will very likely not want electrons to see this envelope, which means
|
|---|
| 1914 | that ghost geometries have to be organized by particle flavours.<br><br>
|
|---|
| 1915 |
|
|---|
| 1916 | Using ghost geometries implies some more overhead in the parameterisation
|
|---|
| 1917 | mechanism for the particles sensitive to ghosts, since navigation is provided
|
|---|
| 1918 | in the ghost geometry by the G4FastSimulationManagerProcess. Usually, however,
|
|---|
| 1919 | only a few volumes will be placed in this ghost world, so that the geometry
|
|---|
| 1920 | computations will remain rather cheap.<br><br>
|
|---|
| 1921 | In the existing implementation (temporary implementation with G4Region but
|
|---|
| 1922 | before parallel geometry implementation),
|
|---|
| 1923 | you may only consider ghost G4Regions with just one root G4LogicalVolume. The
|
|---|
| 1924 | G4GlobalFastSimulationManager provides the construction of the ghost geometry
|
|---|
| 1925 | by making first an empty "clone" of the world for tracking
|
|---|
| 1926 | provided by the construct() method of your G4VUserDetectorConstruction
|
|---|
| 1927 | concrete class. You provide the placement of the G4Region root G4LogicalVolume
|
|---|
| 1928 | relative to the ghost world coordinates in the G4FastSimulationManager objects.
|
|---|
| 1929 | A ghost G4Region is recognized by the fact that its associated
|
|---|
| 1930 | G4FastSimulationManager retains a non-empty list of placements.<br>
|
|---|
| 1931 | The G4GlobalFastSimulationManager will then use both those placements and the
|
|---|
| 1932 | IsApplicable() methods of the models attached to the G4FastSimulationManager
|
|---|
| 1933 | objects to build the flavour-dependant ghost geometries.<br>
|
|---|
| 1934 | Then at the beginning of the tracking of a particle, the appropriate ghost
|
|---|
| 1935 | world, if any, will be selected.
|
|---|
| 1936 | <p>
|
|---|
| 1937 | The steps required to build one ghost G4Region are:
|
|---|
| 1938 |
|
|---|
| 1939 | <ol>
|
|---|
| 1940 | <li>built the ghost G4Region : myGhostRegion;</li>
|
|---|
| 1941 | <li>build the root G4LogicalVolume: myGhostLogical, set it to myGhostRegion;</li>
|
|---|
| 1942 | <li>build a G4FastSimulationManager object, myGhostFSManager, giving
|
|---|
| 1943 | myGhostRegion as argument of the constructor;</li>
|
|---|
| 1944 | <li>give to the G4FastSimulationManager the placement of the
|
|---|
| 1945 | myGhostLogical, by invoking for the G4FastSimulationManager
|
|---|
| 1946 | method:
|
|---|
| 1947 | <pre> AddGhostPlacement(G4RotationMatrix*, const G4ThreeVector&);</pre>
|
|---|
| 1948 | or:
|
|---|
| 1949 | <pre> AddGhostPlacement(G4Transform3D*);</pre>
|
|---|
| 1950 | where the rotation matrix and translation vector of the 3-D
|
|---|
| 1951 | transformation describe the placement relative to the ghost
|
|---|
| 1952 | world coordinates.
|
|---|
| 1953 | </li>
|
|---|
| 1954 | <li>build your G4VFastSimulationModel objects and add them to the
|
|---|
| 1955 | myGhostFSManager.<br>
|
|---|
| 1956 | <em>The IsApplicable() methods of your models will be used by the
|
|---|
| 1957 | G4GlobalFastSimulationManager to build the ghost
|
|---|
| 1958 | geometries corresponding to a given particle type.</em>
|
|---|
| 1959 | </li>
|
|---|
| 1960 | <li>Invoke the G4GlobalFastSimulationManager method:
|
|---|
| 1961 | <pre> G4GlobalFastSimulationManager::getGlobalFastSimulationManager()-><br> CloseFastSimulation();<br> </pre>
|
|---|
| 1962 | </li>
|
|---|
| 1963 | </ol>
|
|---|
| 1964 | This last call will cause the G4GlobalFastSimulationManager to build
|
|---|
| 1965 | the flavour-dependent ghost geometries. This call must be done before
|
|---|
| 1966 | the RunManager closes the geometry. (It is foreseen that the run
|
|---|
| 1967 | manager in the future will invoke the CloseFastSimulation() to
|
|---|
| 1968 | synchronize properly with the closing of the geometry).<br>
|
|---|
| 1969 | <br>
|
|---|
| 1970 | <br>
|
|---|
| 1971 | Visualization facilities are provided for ghosts geometries. After the
|
|---|
| 1972 | CloseFastSimulation() invocation, it is possible to ask for the drawing
|
|---|
| 1973 | of ghosts in an interactive session. The basic commands are:
|
|---|
| 1974 | <ul>
|
|---|
| 1975 | <li>/vis/draw/Ghosts particle_name<br>
|
|---|
| 1976 | which makes the drawing of the ghost geometry associated with the
|
|---|
| 1977 | particle specified by name in the command line.</li>
|
|---|
| 1978 | <li>/vis/draw/Ghosts<br>
|
|---|
| 1979 | which draws all the ghost geometries. </li>
|
|---|
| 1980 | </ul>
|
|---|
| 1981 | <br>
|
|---|
| 1982 | <br>
|
|---|
| 1983 | <p>
|
|---|
| 1984 | <b>5.2.6.8 Gflash Parameterization </b>
|
|---|
| 1985 | </p>
|
|---|
| 1986 | This section describes how to use the Gflash library.
|
|---|
| 1987 | Gflash is a concrete parameterization which is based on the equations
|
|---|
| 1988 | and parameters of the original Gflash package from H1(hep-ex/0001020,
|
|---|
| 1989 | Grindhammer & Peters, see physics manual) and uses the "fast
|
|---|
| 1990 | simulation" facilities of GEANT4 described above. Briefly, whenever a
|
|---|
| 1991 | e-/e+ particle enters the calorimeter, it is parameterized if it has a
|
|---|
| 1992 | minimum energy and the shower is expected to be contained in the
|
|---|
| 1993 | calorimeter (or " parameterization envelope").
|
|---|
| 1994 | If this is fulfilled the particle is killed, as well as all
|
|---|
| 1995 | secondaries, and the energy is deposited according to the Gflash equations.
|
|---|
| 1996 | An example, provided in <b>examples/extended/parametrisation/gflash/ </b>,
|
|---|
| 1997 | shows how to interface Gflash to your application. The simulation time
|
|---|
| 1998 | is measured, so the user can immediately see the speed increase
|
|---|
| 1999 | resulting from the use of Gflash.
|
|---|
| 2000 | <br>
|
|---|
| 2001 | <br>
|
|---|
| 2002 | <p>
|
|---|
| 2003 | <b>5.2.6.9 Using the Gflash Parameterisation </b>
|
|---|
| 2004 | </p>
|
|---|
| 2005 | To use Gflash "out of the box" the following steps are necessary:
|
|---|
| 2006 | <ul>
|
|---|
| 2007 | <li> The user must add the fast simulation process to his process manager:
|
|---|
| 2008 |
|
|---|
| 2009 | <pre>void MyPhysicsList::addParameterisation()
|
|---|
| 2010 | {
|
|---|
| 2011 | G4FastSimulationManagerProcess*
|
|---|
| 2012 | theFastSimulationManagerProcess = new G4FastSimulationManagerProcess();
|
|---|
| 2013 | theParticleIterator->reset();
|
|---|
| 2014 | while( (*theParticleIterator)() )
|
|---|
| 2015 | {
|
|---|
| 2016 | G4ParticleDefinition* particle = theParticleIterator->value();
|
|---|
| 2017 | G4ProcessManager* pmanager = particle->GetProcessManager();
|
|---|
| 2018 | pmanager->AddProcess(theFastSimulationManagerProcess, -1, 0, 0);
|
|---|
| 2019 | }
|
|---|
| 2020 | }</pre>
|
|---|
| 2021 | </li>
|
|---|
| 2022 |
|
|---|
| 2023 |
|
|---|
| 2024 | <li> The envelope in which the parameterization should be performed must be
|
|---|
| 2025 | specified (below: G4Region m_calo_region) and the GFlashShowerModel must
|
|---|
| 2026 | be assigned to this region. Furthermore, the classes GFlashParticleBounds
|
|---|
| 2027 | (which provides thresholds for the parameterization like minimal energy etc.),
|
|---|
| 2028 | GflashHitMaker(a helper class to generate hits in the sensitive detector) and
|
|---|
| 2029 | GFlashHomoShowerParamterisation (which does the computations)
|
|---|
| 2030 | must be constructed (by the user at the moment)
|
|---|
| 2031 | and assigned to the GFlashShowerModel. Please note that at the moment only
|
|---|
| 2032 | homogeneous calorimeters are supported.
|
|---|
| 2033 | <pre>
|
|---|
| 2034 | m_theFastShowerModel = new GFlashShowerModel("fastShowerModel",m_calo_region);
|
|---|
| 2035 | m_theParametrisation = new GFlashHomoShowerParamterisation(matManager->getMaterial(mat));
|
|---|
| 2036 | m_theParticleBounds = new GFlashParticleBounds();
|
|---|
| 2037 | m_theHMaker = new GFlashHitMaker();
|
|---|
| 2038 | m_theFastShowerModel->SetParametrisation(*m_theParametrisation);
|
|---|
| 2039 | m_theFastShowerModel->SetParticleBounds(*m_theParticleBounds) ;
|
|---|
| 2040 | m_theFastShowerModel->SetHitMaker(*m_theHMaker);
|
|---|
| 2041 | </pre>
|
|---|
| 2042 | The user must also set the material of the calorimeter, since the computation
|
|---|
| 2043 | depends on the material.
|
|---|
| 2044 | </li>
|
|---|
| 2045 | <BR>
|
|---|
| 2046 | <li>
|
|---|
| 2047 | It is mandatory to use G4VGFlashSensitiveDetector as (additional)
|
|---|
| 2048 | base class for the sensitive detector.
|
|---|
| 2049 | <pre>class ExGflashSensitiveDetector: public G4VSensitiveDetector ,public G4VGFlashSensitiveDetector <br></pre>
|
|---|
| 2050 | Here it is necessary to implement a separate interface, where the
|
|---|
| 2051 | GFlash spots are processed.
|
|---|
| 2052 | <pre> (ProcessHits(G4GFlashSpot*aSpot ,G4TouchableHistory* ROhist))</pre>
|
|---|
| 2053 | A separate interface is used, because the Gflash spots naturally contain
|
|---|
| 2054 | less information than the full simulation.
|
|---|
| 2055 | </li>
|
|---|
| 2056 | </ul>
|
|---|
| 2057 | Since the parameters in the Gflash package are taken from fits to full
|
|---|
| 2058 | simulations with Geant3, some retuning might be necessary for good
|
|---|
| 2059 | agreement with Geant4 showers. For experiment-specific geometries some
|
|---|
| 2060 | retuning might be necessary anyway.
|
|---|
| 2061 | The tuning is quite complicated since there are many parameters (some
|
|---|
| 2062 | correlated) and cannot be described here (see again hep-ex/0001020).
|
|---|
| 2063 | For brave users the Gflash framework already forsees the possibility of
|
|---|
| 2064 | passing a class with the (users) parameters,<b>GVFlashHomoShowerTuning </b>,
|
|---|
| 2065 | to the GFlashHomoShowerParamterisation constructor. The default parameters are
|
|---|
| 2066 | the original Gflash parameters:
|
|---|
| 2067 | <pre>GFlashHomoShowerParameterisation(G4Material * aMat, GVFlashHomoShowerTuning * aPar = 0);<br><br></pre>
|
|---|
| 2068 | Now there is also a preliminary implemenation of a parameterization for
|
|---|
| 2069 | sampling calorimeters.<br>
|
|---|
| 2070 | The user must specify the active and passive material, as well as the
|
|---|
| 2071 | thickness of the active and passive layer. <br>
|
|---|
| 2072 | The sampling structure of the calorimeter is taken into account by
|
|---|
| 2073 | using an "effective medium" to compute the shower shape.<br>
|
|---|
| 2074 | All material properties needed are calculated automatically. If tuning
|
|---|
| 2075 | is required, the user can pass his own parameter set in the <br>
|
|---|
| 2076 | class <b>GFlashSamplingShowerTuning. </b>Here the user can also set
|
|---|
| 2077 | his calorimeter resolution. <br>
|
|---|
| 2078 | All in all the constructor looks the following:<br>
|
|---|
| 2079 | <br>
|
|---|
| 2080 | <pre>GFlashSamplingShowerParamterisation(G4Material * Mat1, G4Material * Mat2,G4double d1,G4double d2,<br>GVFlashSamplingShowerTuning * aPar = 0);</pre>
|
|---|
| 2081 | An implementation of some tools that should help the user to tune the
|
|---|
| 2082 | parameterization is forseen.
|
|---|
| 2083 | <br>
|
|---|
| 2084 | <p>
|
|---|
| 2085 | </p>
|
|---|
| 2086 | <hr><a name="5.2.7"></a>
|
|---|
| 2087 | <h2>5.2.7 Transportation Process</h2>
|
|---|
| 2088 | To be delivered by J. Apostolakis (<a
|
|---|
| 2089 | href="mailto:John.Apostolakis@cern.ch">John.Apostolakis@cern.ch</a>)
|
|---|
| 2090 | <p><br>
|
|---|
| 2091 | <br>
|
|---|
| 2092 | </p>
|
|---|
| 2093 | <hr><a href="../../../../Authors/html/subjectsToAuthors.html"><i>About
|
|---|
| 2094 | the authors</i></a>
|
|---|
| 2095 | </body>
|
|---|
| 2096 | </html>
|
|---|
