Context Navigation

← Previous Revision
Latest Revision
Next Revision →
Blame
Revision Log

physicsProcess.html @ 1358

Last change on this file since 1358 was 1208, checked in by garnier, 15 years ago
CVS update
File size: 104.7 KB

Line
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.034eV, ......, 4.136eV};<br>G4double rindex[NUMENTRIES] = {1.3435, ......, 1.3608};<br>G4double absorption[NUMENTRIES] = {344.8cm, ......, 1450.0cm];<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.6eV, 6.7eV, 6.8eV, 6.9eV,<br> 7.0eV, 7.1eV, 7.2eV, 7.3eV, 7.4eV };<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.6eV, 6.7eV, 6.8eV, 6.9eV,<br> 7.0eV, 7.1eV, 7.2eV, 7.3eV, 7.4eV };<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.1mm,0.2mm,0.3mm,0.4cm,1.0cm,10cm,1.0m,10.0m,10.0m};<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.038eV, 4.144eV};<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&quot 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(G4GFlashSpotaSpot ,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>

Note: See TracBrowser for help on using the repository browser.

Context Navigation

source: trunk/documents/UserDoc/UsersGuides/ForApplicationDeveloper/html/TrackingAndPhysics/physicsProcess.html @ 1358

Download in other formats: