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> |
---|