1 | <!-- ******************************************************** --> |
---|
2 | <!-- Docbook Version: For Toolkit Developers Guide --> |
---|
3 | <!-- ******************************************************** --> |
---|
4 | |
---|
5 | <!-- ******************* Section (Level#1) ****************** --> |
---|
6 | <sect1 id="sect.ExtdFuncHadPhys"> |
---|
7 | <title> |
---|
8 | Hadronic Physics |
---|
9 | </title> |
---|
10 | |
---|
11 | <!-- |
---|
12 | This is a verbatim of a paper published in a refereed journal. |
---|
13 | A suggestion by one of the documentation referees to re-write |
---|
14 | completely seems quite inappropriate. |
---|
15 | --> |
---|
16 | |
---|
17 | <!-- ******************* Section (Level#2) ****************** --> |
---|
18 | <sect2 id="sect.ExtdFuncHadPhys.Intro"> |
---|
19 | <title> |
---|
20 | Introduction |
---|
21 | </title> |
---|
22 | |
---|
23 | <para> |
---|
24 | Optimal exploitation of hadronic final |
---|
25 | states played a key role in successes of all recent collider experiment in HEP, |
---|
26 | and the ability to use hadronic final states will continue to be one of the |
---|
27 | decisive issues during the analysis phase of the LHC experiments. |
---|
28 | Monte Carlo programs like Geant4 facilitate the use of |
---|
29 | hadronic final states, and have been developed for many years. |
---|
30 | </para> |
---|
31 | |
---|
32 | <para> |
---|
33 | We give an overview of the Object Oriented frameworks for hadronic generators |
---|
34 | in Geant4, and illustrate the physics models underlying hadronic shower |
---|
35 | simulation on examples, including the three basic types of modeling; |
---|
36 | data-driven, parametrisation-driven, and theory-driven modeling, and their |
---|
37 | possible realisations in the Object Oriented component system of Geant4. |
---|
38 | We put particular focus on the level of extendibility that can and has been |
---|
39 | achieved by our Russian dolls approach to Object Oriented design, and the |
---|
40 | role and importance of the frameworks in a component system. |
---|
41 | </para> |
---|
42 | |
---|
43 | </sect2> |
---|
44 | |
---|
45 | <!-- ******************* Section (Level#2) ****************** --> |
---|
46 | <sect2 id="sect.ExtdFuncHadPhys.PrncCnsd"> |
---|
47 | <title> |
---|
48 | Principal Considerations |
---|
49 | </title> |
---|
50 | |
---|
51 | <para> |
---|
52 | The purpose of this section is to explain the implementation frameworks used |
---|
53 | in and provided by Geant4 for hadronic shower simulation as in the 1.1 |
---|
54 | release of the program. The implementation frameworks follow the Russian dolls |
---|
55 | approach to implementation framework design. |
---|
56 | A top-level, very abstracting implementation framework provides the basic |
---|
57 | interface to the other Geant4 categories, and fulfils the most general |
---|
58 | use-case for hadronic shower simulation. It is refined for more specific |
---|
59 | use-cases by implementing a hierarchy of implementation frameworks, each level |
---|
60 | implementing the common logic of a particular use-case package in a concrete |
---|
61 | implementation of the interface specification of one framework level above, |
---|
62 | this way refining the granularity of abstraction and delegation. This defines |
---|
63 | the Russian dolls architectural pattern. |
---|
64 | Abstract classes are used as the delegation mechanism |
---|
65 | |
---|
66 | <footnote> |
---|
67 | <para> |
---|
68 | The same can be achieved with template specialisations |
---|
69 | with slightly improved CPU performance but at the cost of significantly more |
---|
70 | complex designs and, with present compilers, significantly reduced |
---|
71 | portability. |
---|
72 | </para> |
---|
73 | </footnote> |
---|
74 | . |
---|
75 | </para> |
---|
76 | |
---|
77 | <para> |
---|
78 | All framework functional requirements were obtained through use-case analysis. |
---|
79 | In the following we present for each framework level the compressed use-cases, |
---|
80 | requirements, designs including the flexibility provided, and illustrate the |
---|
81 | framework functionality with examples. All design patterns cited are to |
---|
82 | be read as defined in |
---|
83 | <citation><xref linkend="biblio.Gamma1995" endterm="biblio.Gamma1995.abbrev" /></citation>. |
---|
84 | </para> |
---|
85 | |
---|
86 | </sect2> |
---|
87 | |
---|
88 | <!-- ******************* Section (Level#2) ****************** --> |
---|
89 | <sect2 id="sect.ExtdFuncHadPhys.L1_Proc"> |
---|
90 | <title> |
---|
91 | Level 1 Framework - processes |
---|
92 | </title> |
---|
93 | |
---|
94 | <para> |
---|
95 | There are two principal use-cases of the level 1 framework. A user will |
---|
96 | want to choose the processes used for his particular simulation run, and a |
---|
97 | physicist will want to write code for processes of his own and use these |
---|
98 | together with the rest of the system in a seamless manner. |
---|
99 | </para> |
---|
100 | |
---|
101 | <!-- ******* Bridgehead ******* --> |
---|
102 | <bridgehead renderas='sect4'> |
---|
103 | Requirements |
---|
104 | </bridgehead> |
---|
105 | |
---|
106 | <para> |
---|
107 | <orderedlist spacing="compact"> |
---|
108 | <listitem><para> |
---|
109 | Provide a standard interface to be used by process implementations. |
---|
110 | </para></listitem> |
---|
111 | <listitem><para> |
---|
112 | Provide registration mechanisms for processes. |
---|
113 | </para></listitem> |
---|
114 | </orderedlist> |
---|
115 | </para> |
---|
116 | |
---|
117 | <!-- ******* Bridgehead ******* --> |
---|
118 | <bridgehead renderas='sect4'> |
---|
119 | Design and interfaces |
---|
120 | </bridgehead> |
---|
121 | |
---|
122 | <para> |
---|
123 | Both requirements are implemented in a sub-set of the tracking-physics |
---|
124 | interface in Geant4}. The class diagram is shown in |
---|
125 | <xref linkend="fig.ExtdFuncHadPhys_1" />. |
---|
126 | |
---|
127 | <figure id="fig.ExtdFuncHadPhys_1"> |
---|
128 | <title> |
---|
129 | Level 1 implementation framework of the hadronic category of GEANT4. |
---|
130 | </title> |
---|
131 | <mediaobject> |
---|
132 | <imageobject role="fo"> |
---|
133 | <imagedata fileref="./AllResources/GuideToExtendFunctionality/HadronicPhysics/Level1.jpg" |
---|
134 | format="JPG" contentwidth="10.0cm" align="center" /> |
---|
135 | </imageobject> |
---|
136 | <imageobject role="html"> |
---|
137 | <imagedata fileref="./AllResources/GuideToExtendFunctionality/HadronicPhysics/Level1.jpg" |
---|
138 | format="JPG" contentwidth="120%" align="center" /> |
---|
139 | </imageobject> |
---|
140 | </mediaobject> |
---|
141 | </figure> |
---|
142 | </para> |
---|
143 | |
---|
144 | <para> |
---|
145 | All processes have a common base-class <literal>G4VProcess</literal>, |
---|
146 | from which a set of specialised classes are derived. Three of them are |
---|
147 | used as base classes for hadronic processes for particles at rest |
---|
148 | (<literal>G4VRestProcess</literal>), for interactions in flight |
---|
149 | (<literal>G4VDiscreteProcess</literal>), and for processes like |
---|
150 | radioactive decay where the same implementation can represent both these |
---|
151 | extreme cases (<literal>G4VRestDiscrete-Process</literal>). |
---|
152 | </para> |
---|
153 | |
---|
154 | <para> |
---|
155 | Each of these classes declares two types of methods; one for calculating the |
---|
156 | time to interaction or the physical interaction length, allowing tracking to |
---|
157 | request the information necessary to decide on the process responsible for |
---|
158 | final state production, and one to compute the final state. These are pure |
---|
159 | virtual methods, and have to be implemented in each individual derived class, |
---|
160 | as enforced by the compiler. |
---|
161 | </para> |
---|
162 | |
---|
163 | |
---|
164 | <!-- ******* Bridgehead ******* --> |
---|
165 | <bridgehead renderas='sect4'> |
---|
166 | Framework functionality |
---|
167 | </bridgehead> |
---|
168 | |
---|
169 | <para> |
---|
170 | The functionality provided is through the use of process base-class pointers |
---|
171 | in the tracking-physics interface, and the |
---|
172 | <literal>G4Process-Manager</literal>. |
---|
173 | All functionality is implemented in abstract, and registration of derived process |
---|
174 | classes with the <literal>G4Process-Manager</literal> of an individual particle |
---|
175 | allows for arbitrary combination of both Geant4 provided processes, and |
---|
176 | user-implemented processes. This registration mechanism is a modification on a |
---|
177 | Chain of Responsibility. It is outside the scope of the current paper, and its |
---|
178 | description is available from |
---|
179 | <ulink url="http://geant4.web.cern.ch/geant4/support/userdocuments.shtml"> |
---|
180 | G4Manual</ulink>. |
---|
181 | </para> |
---|
182 | |
---|
183 | </sect2> |
---|
184 | |
---|
185 | <!-- ******************* Section (Level#2) ****************** --> |
---|
186 | <sect2 id="sect.ExtdFuncHadPhys.L2F_CrssSctMdl"> |
---|
187 | <title> |
---|
188 | Level 2 Framework - Cross Sections and Models |
---|
189 | </title> |
---|
190 | |
---|
191 | <para> |
---|
192 | At the next level of abstraction, only processes that occur for particles |
---|
193 | in flight are considered. For these, it is easily observed that the sources |
---|
194 | of cross sections and final state production are rarely the same. Also, |
---|
195 | different sources will come with different restrictions. The principal |
---|
196 | use-cases of the framework are addressing these commonalities. A user might |
---|
197 | want to combine different cross sections and final state or isotope production |
---|
198 | models as provided by Geant4, and a physicist might |
---|
199 | want to implement his own model for particular situation, and add cross-section |
---|
200 | data sets that are relevant for his particular analysis to the system in a |
---|
201 | seamless manner. |
---|
202 | </para> |
---|
203 | |
---|
204 | <!-- ******* Bridgehead ******* --> |
---|
205 | <bridgehead renderas='sect4'> |
---|
206 | Requirements |
---|
207 | </bridgehead> |
---|
208 | |
---|
209 | <para> |
---|
210 | <orderedlist spacing="compact"> |
---|
211 | <listitem><para> |
---|
212 | Flexible choice of inclusive scattering cross-sections. |
---|
213 | </para></listitem> |
---|
214 | <listitem><para> |
---|
215 | Ability to use different data-sets for different parts of |
---|
216 | the simulation, depending on the conditions at the point of interaction. |
---|
217 | </para></listitem> |
---|
218 | <listitem><para> |
---|
219 | Ability to add user-defined data-sets in a seamless manner. |
---|
220 | </para></listitem> |
---|
221 | <listitem><para> |
---|
222 | Flexible, unconstrained choice of final state production models. |
---|
223 | </para></listitem> |
---|
224 | <listitem><para> |
---|
225 | Ability to use different final state production codes |
---|
226 | for different parts of the simulation, depending on the conditions at the |
---|
227 | point of interaction. |
---|
228 | </para></listitem> |
---|
229 | <listitem><para> |
---|
230 | Ability to add user-defined final state production models in |
---|
231 | a seamless manner. |
---|
232 | </para></listitem> |
---|
233 | <listitem><para> |
---|
234 | Flexible choice of isotope production models, to run in |
---|
235 | parasitic mode to any kind of transport models. |
---|
236 | </para></listitem> |
---|
237 | <listitem><para> |
---|
238 | Ability to use different isotope production codes |
---|
239 | for different parts of the simulation, depending on the conditions at the |
---|
240 | point of interaction. |
---|
241 | </para></listitem> |
---|
242 | <listitem><para> |
---|
243 | Ability to add user-defined isotope production models in a seamless manner. |
---|
244 | </para></listitem> |
---|
245 | </orderedlist> |
---|
246 | </para> |
---|
247 | |
---|
248 | |
---|
249 | <!-- ******* Bridgehead ******* --> |
---|
250 | <bridgehead renderas='sect4'> |
---|
251 | Design and interfaces |
---|
252 | </bridgehead> |
---|
253 | |
---|
254 | <para> |
---|
255 | The above requirements are implemented in three framework components, one |
---|
256 | for cross-sections, final state production, and isotope production each. |
---|
257 | The class diagrams are shown in |
---|
258 | <xref linkend="fig.ExtdFuncHadPhys_2" /> |
---|
259 | for the cross-section aspects, |
---|
260 | <xref linkend="fig.ExtdFuncHadPhys_3" /> |
---|
261 | for the final state production aspects, and figure |
---|
262 | <xref linkend="fig.ExtdFuncHadPhys_4" /> |
---|
263 | for the isotope production aspects. |
---|
264 | |
---|
265 | <figure id="fig.ExtdFuncHadPhys_2"> |
---|
266 | <title> |
---|
267 | Level 2 implementation framework of the hadronic category of Geant4; |
---|
268 | cross-section aspect. |
---|
269 | </title> |
---|
270 | <mediaobject> |
---|
271 | <imageobject role="fo"> |
---|
272 | <imagedata fileref="./AllResources/GuideToExtendFunctionality/HadronicPhysics/Level2_1.jpg" |
---|
273 | format="JPG" contentwidth="10.0cm" align="center" /> |
---|
274 | </imageobject> |
---|
275 | <imageobject role="html"> |
---|
276 | <imagedata fileref="./AllResources/GuideToExtendFunctionality/HadronicPhysics/Level2_1.jpg" |
---|
277 | format="JPG" contentwidth="120%" align="center" /> |
---|
278 | </imageobject> |
---|
279 | </mediaobject> |
---|
280 | </figure> |
---|
281 | |
---|
282 | <figure id="fig.ExtdFuncHadPhys_3"> |
---|
283 | <title> |
---|
284 | Level 2 implementation framework of the hadronic category of Geant4; |
---|
285 | final state production aspect. |
---|
286 | </title> |
---|
287 | <mediaobject> |
---|
288 | <imageobject role="fo"> |
---|
289 | <imagedata fileref="./AllResources/GuideToExtendFunctionality/HadronicPhysics/Level2_2.jpg" |
---|
290 | format="JPG" contentwidth="10.0cm" align="center" /> |
---|
291 | </imageobject> |
---|
292 | <imageobject role="html"> |
---|
293 | <imagedata fileref="./AllResources/GuideToExtendFunctionality/HadronicPhysics/Level2_2.jpg" |
---|
294 | format="JPG" contentwidth="120%" align="center" /> |
---|
295 | </imageobject> |
---|
296 | </mediaobject> |
---|
297 | </figure> |
---|
298 | |
---|
299 | <figure id="fig.ExtdFuncHadPhys_4"> |
---|
300 | <title> |
---|
301 | Level 2 implementation framework of the hadronic category of Geant4; |
---|
302 | isotope production aspect |
---|
303 | </title> |
---|
304 | <mediaobject> |
---|
305 | <imageobject role="fo"> |
---|
306 | <imagedata fileref="./AllResources/GuideToExtendFunctionality/HadronicPhysics/Level2_3.jpg" |
---|
307 | format="JPG" contentwidth="10.0cm" align="center" /> |
---|
308 | </imageobject> |
---|
309 | <imageobject role="html"> |
---|
310 | <imagedata fileref="./AllResources/GuideToExtendFunctionality/HadronicPhysics/Level2_3.jpg" |
---|
311 | format="JPG" contentwidth="120%" align="center" /> |
---|
312 | </imageobject> |
---|
313 | </mediaobject> |
---|
314 | </figure> |
---|
315 | </para> |
---|
316 | |
---|
317 | <para> |
---|
318 | The three parts are integrated in the <literal>G4Hadronic-Process</literal> |
---|
319 | class, that serves as base-class for all hadronic processes of particles in flight. |
---|
320 | </para> |
---|
321 | |
---|
322 | |
---|
323 | <!-- ******* Bridgehead ******* --> |
---|
324 | <bridgehead renderas='sect4'> |
---|
325 | Cross-sections |
---|
326 | </bridgehead> |
---|
327 | |
---|
328 | <para> |
---|
329 | Each hadronic process is derived from <literal>G4Hadronic-Process}</literal>, |
---|
330 | which holds a list of ``cross section data sets''. |
---|
331 | The term ``data set'' is |
---|
332 | representing an object that encapsulates methods and data for calculating |
---|
333 | total cross sections for a given process in a certain range of validity. |
---|
334 | The implementations may take any form. It can be a simple equation as well as |
---|
335 | sophisticated parameterisations, or evaluated data. |
---|
336 | All cross section data set classes are derived from the abstract class |
---|
337 | <literal>G4VCrossSection-DataSet}</literal>, which declares methods that allow |
---|
338 | the process inquire, about the applicability of an individual data-set through |
---|
339 | <literal>IsApplicable(const G4DynamicParticle*, const G4Element*)</literal>, |
---|
340 | and to delegate the calculation of the actual cross-section value through |
---|
341 | <literal>GetCrossSection(const G4DynamicParticle*, const G4Element*)</literal>. |
---|
342 | </para> |
---|
343 | |
---|
344 | <!-- ******* Bridgehead ******* --> |
---|
345 | <bridgehead renderas='sect4'> |
---|
346 | Final state production |
---|
347 | </bridgehead> |
---|
348 | |
---|
349 | <para> |
---|
350 | The <literal>G4HadronicInteraction</literal> base class is provided for final state |
---|
351 | generation. It declares a minimal interface of only one pure virtual method: |
---|
352 | <literal>G4VParticleChange* ApplyYourself(const G4Track &, G4Nucleus &)}. |
---|
353 | </literal> |
---|
354 | |
---|
355 | <literal>G4HadronicProcess</literal> provides a registry for final state |
---|
356 | production models inheriting from <literal>G4Hadronic-Interaction</literal>. |
---|
357 | Again, final state production model is meant in very general terms. This can |
---|
358 | be an implementation of a quark gluon string model |
---|
359 | <citation><xref linkend="biblio.QGSM" endterm="biblio.QGSM.abbrev"/></citation>, |
---|
360 | a sampling code for ENDF/B data formats |
---|
361 | <citation><xref linkend="biblio.ENDFForm" endterm="biblio.ENDFForm.abbrev"/></citation>, |
---|
362 | or a parametrisation describing only |
---|
363 | neutron elastic scattering off Silicon up to 300~MeV. |
---|
364 | </para> |
---|
365 | |
---|
366 | <!-- ******* Bridgehead ******* --> |
---|
367 | <bridgehead renderas='sect4'> |
---|
368 | Isotope production |
---|
369 | </bridgehead> |
---|
370 | |
---|
371 | <para> |
---|
372 | For isotope production, a base class (<literal>G4VIsotope-Production</literal>) |
---|
373 | is provided. It declares a method |
---|
374 | <literal>G4IsoResult * GetIsotope(const G4Track &, const G4Nucleus &)</literal> |
---|
375 | that calculates and returns the isotope production information. Any concrete |
---|
376 | isotope production model will inherit from this class, and implement the |
---|
377 | method. Again, the modeling possibilities are not limited, and the |
---|
378 | implementation of concrete production models is not restricted in any way. |
---|
379 | By convention, the <literal>GetIsotope</literal> method returns NULL, if the model |
---|
380 | is not applicable for the current projectile target combination. |
---|
381 | </para> |
---|
382 | |
---|
383 | <!-- ******* Bridgehead ******* --> |
---|
384 | <bridgehead renderas='sect3'> |
---|
385 | Framework functionality: |
---|
386 | </bridgehead> |
---|
387 | |
---|
388 | <para> |
---|
389 | </para> |
---|
390 | |
---|
391 | <!-- ******* Bridgehead ******* --> |
---|
392 | <bridgehead renderas='sect4'> |
---|
393 | Cross Sections |
---|
394 | </bridgehead> |
---|
395 | |
---|
396 | <para> |
---|
397 | <literal>G4HadronicProcess</literal> provides registering possibilities |
---|
398 | for data sets. A default is provided covering all possible |
---|
399 | conditions to some approximation. The process stores and retrieves |
---|
400 | the data sets through a data store that acts like a FILO stack |
---|
401 | (a Chain of Responsibility with a |
---|
402 | First In Last Out decision strategy). This allows the user to map out |
---|
403 | the entire parameter space by overlaying cross section data sets to optimise |
---|
404 | the overall result. Examples are the cross sections for low energy neutron |
---|
405 | transport. If these are registered last by the user, they will be used |
---|
406 | whenever low energy neutrons are encountered. In all other conditions the |
---|
407 | system falls back on the default, or data sets with earlier registration dates. |
---|
408 | The fact that the registration is done through abstract base classes with no |
---|
409 | side-effects allows the user to implement and use his own cross sections. |
---|
410 | Examples are special reaction cross sections of |
---|
411 | κ<superscript>0</superscript>-nuclear interactions |
---|
412 | that might be used for ε/ε' analysis at LHC to control the |
---|
413 | systematic error. |
---|
414 | </para> |
---|
415 | |
---|
416 | <!-- ******* Bridgehead ******* --> |
---|
417 | <bridgehead renderas='sect4'> |
---|
418 | Final state production |
---|
419 | </bridgehead> |
---|
420 | |
---|
421 | <para> |
---|
422 | The <literal>G4HadronicProcess</literal> class provides a |
---|
423 | registration service for classes deriving from |
---|
424 | <literal>G4Hadronic-Interaction</literal>, and delegates final state |
---|
425 | production to the applicable model. |
---|
426 | <literal>G4Hadronic-Interaction</literal>provides the functionality needed |
---|
427 | to define and enforce the applicability of a particular model. |
---|
428 | Models inheriting from <literal>G4Hadronic-Interaction</literal> |
---|
429 | can be restricted in applicability in projectile |
---|
430 | type and energy, and can be activated/deactivated for individual materials and |
---|
431 | elements. This allows a user to use final state production models in |
---|
432 | arbitrary combinations, and to write his own models for |
---|
433 | final state production. The design is a variant of a Chain of Responsibility. |
---|
434 | An example would be the likely CMS scenario - the combination of low energy |
---|
435 | neutron transport with a quantum molecular dynamics |
---|
436 | <citation><xref linkend="biblio.QMD" endterm="biblio.QMD.abbrev"/></citation>, |
---|
437 | invariant phase space decay |
---|
438 | <citation><xref linkend="biblio.CHIPS" endterm="biblio.CHIPS.abbrev"/></citation>, |
---|
439 | and fast parametrised models for calorimeter materials, with user defined |
---|
440 | modeling of interactions of spallation nucleons with the most abundant |
---|
441 | tracker and calorimeter materials. |
---|
442 | </para> |
---|
443 | |
---|
444 | <!-- ******* Bridgehead ******* --> |
---|
445 | <bridgehead renderas='sect4'> |
---|
446 | Isotope production |
---|
447 | </bridgehead> |
---|
448 | |
---|
449 | <para> |
---|
450 | The <literal>G4HadronicProcess</literal> by default calculates the isotope production |
---|
451 | information from the final state given by the transport model. In addition, it |
---|
452 | provides a registering mechanism for isotope production models that run in |
---|
453 | parasitic mode to the transport models and inherit from |
---|
454 | <literal>G4VIsotope-Production</literal>. The registering mechanism behaves like a FILO |
---|
455 | stack, again based on Chain of Responsibility. The models will be asked for |
---|
456 | isotope production information in inverse order of registration. The first |
---|
457 | model that returns a non-NULL value will be applied. In addition, the |
---|
458 | <literal>G4Hadronic-Process</literal> provides the basic infrastructure for accessing and |
---|
459 | steering of isotope-production information. It allows to enable and disable |
---|
460 | the calculation of isotope production information globally, or for individual |
---|
461 | processes, and to retrieve the isotope production information through the |
---|
462 | <literal>G4IsoParticleChange * GetIsotopeProductionInfo()}</literal> |
---|
463 | method at the end of each step. The <literal>G4HadronicProcess</literal> is a finite state |
---|
464 | machine that will ensure the <literal>GetIsotope-ProductionInfo</literal> returns a |
---|
465 | non-zero value only at the first call after isotope production occurred. An |
---|
466 | example of the use of this functionality is the study of activation of a |
---|
467 | Germanium detector in a high precision, low background experiment. |
---|
468 | </para> |
---|
469 | |
---|
470 | </sect2> |
---|
471 | |
---|
472 | |
---|
473 | <!-- ******************* Section (Level#2) ****************** --> |
---|
474 | <sect2 id="sect.ExtdFuncHadPhys.L3F_ThrtMdl"> |
---|
475 | <title> |
---|
476 | Level 3 Framework - Theoretical Models |
---|
477 | </title> |
---|
478 | |
---|
479 | <para> |
---|
480 | <figure id="fig.ExtdFuncHadPhys_5"> |
---|
481 | <title> |
---|
482 | Level 3 implementation framework of the hadronic category of Geant4; |
---|
483 | theoretical model aspect. |
---|
484 | </title> |
---|
485 | <mediaobject> |
---|
486 | <imageobject role="fo"> |
---|
487 | <imagedata fileref="./AllResources/GuideToExtendFunctionality/HadronicPhysics/Level3_1.jpg" |
---|
488 | format="JPG" contentwidth="10.0cm" align="center" /> |
---|
489 | </imageobject> |
---|
490 | <imageobject role="html"> |
---|
491 | <imagedata fileref="./AllResources/GuideToExtendFunctionality/HadronicPhysics/Level3_1.jpg" |
---|
492 | format="JPG" contentwidth="120%" align="center" /> |
---|
493 | </imageobject> |
---|
494 | </mediaobject> |
---|
495 | </figure> |
---|
496 | |
---|
497 | Geant4 provides at present one implementation framework for theory |
---|
498 | driven models. The main use-case is that of a user wishing to use theoretical |
---|
499 | models in general, and to use various intra-nuclear transport or pre-compound |
---|
500 | models together with models simulating the initial interactions at very high |
---|
501 | energies. |
---|
502 | </para> |
---|
503 | |
---|
504 | <!-- ******* Bridgehead ******* --> |
---|
505 | <bridgehead renderas='sect4'> |
---|
506 | Requirements |
---|
507 | </bridgehead> |
---|
508 | |
---|
509 | <para> |
---|
510 | <orderedlist spacing="compact"> |
---|
511 | <listitem><para> |
---|
512 | Allow to use or adapt any string-parton or parton transport |
---|
513 | <citation><xref linkend="biblio.VNI" endterm="biblio.VNI.abbrev"/></citation>, |
---|
514 | </para></listitem> |
---|
515 | <listitem><para> |
---|
516 | Allow to adapt event generators, ex. |
---|
517 | <citation><xref linkend="biblio.PYTHIA7" endterm="biblio.PYTHIA7.abbrev"/></citation>, |
---|
518 | state production in shower simulation. |
---|
519 | </para></listitem> |
---|
520 | <listitem><para> |
---|
521 | Allow for combination of the above with any intra-nuclear transport (INT). |
---|
522 | </para></listitem> |
---|
523 | <listitem><para> |
---|
524 | Allow stand-alone use of intra-nuclear transport. |
---|
525 | </para></listitem> |
---|
526 | <listitem><para> |
---|
527 | Allow for combination of the above with any pre-compound model. |
---|
528 | </para></listitem> |
---|
529 | <listitem><para> |
---|
530 | Allow stand-alone use of any pre-compound model. |
---|
531 | </para></listitem> |
---|
532 | <listitem><para> |
---|
533 | Allow for use of any evaporation code. |
---|
534 | </para></listitem> |
---|
535 | <listitem><para> |
---|
536 | Allow for seamless integration of user defined components for any of the above. |
---|
537 | </para></listitem> |
---|
538 | </orderedlist> |
---|
539 | </para> |
---|
540 | |
---|
541 | <!-- ******* Bridgehead ******* --> |
---|
542 | <bridgehead renderas='sect4'> |
---|
543 | Design and interfaces |
---|
544 | </bridgehead> |
---|
545 | |
---|
546 | <para> |
---|
547 | To provide the above flexibility, the following abstract base classes have been |
---|
548 | implemented: |
---|
549 | |
---|
550 | <itemizedlist spacing="compact"> |
---|
551 | <listitem><para> |
---|
552 | <literal>G4VHighEnergyGenerator</literal> |
---|
553 | </para></listitem> |
---|
554 | <listitem><para> |
---|
555 | <literal>G4VIntranuclearTransportModel</literal> |
---|
556 | </para></listitem> |
---|
557 | <listitem><para> |
---|
558 | <literal>G4VPreCompoundModel</literal> |
---|
559 | </para></listitem> |
---|
560 | <listitem><para> |
---|
561 | <literal>G4VExcitationHandler</literal> |
---|
562 | </para></listitem> |
---|
563 | </itemizedlist> |
---|
564 | </para> |
---|
565 | |
---|
566 | <para> |
---|
567 | In addition, the class <literal>G4TheoFS-Generator</literal> is provided to orchestrate |
---|
568 | interactions between these classes. The class diagram is shown in |
---|
569 | <xref linkend="fig.ExtdFuncHadPhys_5" />. |
---|
570 | </para> |
---|
571 | |
---|
572 | <para> |
---|
573 | <literal>G4VHighEnergy-Generator</literal> serves as base class for parton transport or |
---|
574 | parton string models, and for Adapters to event generators. This class |
---|
575 | declares two methods, <literal>Scatter</literal>, and |
---|
576 | <literal>GetWoundedNucleus</literal>. |
---|
577 | </para> |
---|
578 | |
---|
579 | <para> |
---|
580 | The base class for INT inherits from <literal>G4Hadronic-Interaction</literal>, |
---|
581 | making any concrete implementation usable as a stand-alone model. In doing so, it |
---|
582 | re-declares the <literal>ApplyYourself</literal> interface of |
---|
583 | <literal>G4Hadronic-Interaction</literal>, |
---|
584 | and adds a second interface, <literal>Propagate</literal>, for further propagation |
---|
585 | after high energy interactions. <literal>Propagate</literal> takes as arguments a |
---|
586 | three-dimensional model of a wounded nucleus, and a set of secondaries with |
---|
587 | energies and positions. |
---|
588 | </para> |
---|
589 | |
---|
590 | <para> |
---|
591 | The base class for pre-equilibrium decay models, <literal>G4VPre-CompoundModel</literal>, |
---|
592 | inherits from <literal>G4Hadronic-Interaction</literal>, again making any concrete |
---|
593 | implementation usable as stand-alone model. It adds a pure virtual |
---|
594 | <literal>DeExcite</literal> method for further evolution of the system when |
---|
595 | intra-nuclear transport assumptions break down. |
---|
596 | <literal>DeExcite</literal> takes a <literal>G4Fragment</literal>, |
---|
597 | the Geant4 representation of an excited nucleus, as argument. |
---|
598 | </para> |
---|
599 | |
---|
600 | <para> |
---|
601 | The base class for evaporation phases, <literal>G4VExcitation-Handler</literal>, |
---|
602 | declares an abstract method, <literal>BreakItUP()</literal>, for compound decay. |
---|
603 | </para> |
---|
604 | |
---|
605 | |
---|
606 | <!-- ******* Bridgehead ******* --> |
---|
607 | <bridgehead renderas='sect4'> |
---|
608 | Framework functionality |
---|
609 | </bridgehead> |
---|
610 | |
---|
611 | <para> |
---|
612 | The <literal>G4TheoFSGenerator</literal> class inherits from |
---|
613 | <literal>G4Hadronic-Interaction</literal>, |
---|
614 | and hence can be registered as a model for final state production with a |
---|
615 | hadronic process. It allows a concrete implementation of |
---|
616 | <literal>G4VIntranuclear-TransportModel</literal> and |
---|
617 | <literal>G4VHighEnergy-Generator</literal> to be |
---|
618 | registered, and delegates initial interactions, and intra-nuclear transport |
---|
619 | of the corresponding secondaries to the respective classes. The design is a |
---|
620 | complex variant of a Strategy. The most spectacular application of this |
---|
621 | pattern is the use of parton-string models for string excitation, quark |
---|
622 | molecular dynamics for correlated string decay, and quantum molecular dynamics |
---|
623 | for transport, a combination which promises to result in a coherent |
---|
624 | description of quark gluon plasma in high energy nucleus-nucleus interactions. |
---|
625 | </para> |
---|
626 | |
---|
627 | <para> |
---|
628 | The class <literal>G4VIntranuclearTransportModel</literal> provides |
---|
629 | registering mechanisms for concrete implementations of |
---|
630 | <literal>G4VPreCompound-Model</literal>, and provides |
---|
631 | concrete intra-nuclear transports with the possibility of delegating |
---|
632 | pre-compound decay to these models. |
---|
633 | </para> |
---|
634 | |
---|
635 | <para> |
---|
636 | <literal>G4VPreCompoundModel</literal> provides a registering mechanism |
---|
637 | for compound decay through the |
---|
638 | <literal>G4VExcitation-Handler</literal> interface, and provides concrete |
---|
639 | implementations with the possibility of delegating the decay of a compound |
---|
640 | nucleus. |
---|
641 | </para> |
---|
642 | |
---|
643 | <para> |
---|
644 | The concrete scenario of <literal>G4TheoFS-Generator</literal> using a |
---|
645 | dual parton model |
---|
646 | and a classical cascade, which in turn uses an exciton pre-compound model that |
---|
647 | delegates to an evaporation phase, would be the following: |
---|
648 | <literal>G4TheoFS-Generator</literal> receives the conditions of the interaction; |
---|
649 | a primary particle and a nucleus. It asks the dual parton model to perform the |
---|
650 | initial scatterings, and return the final state, along with the by then |
---|
651 | damaged nucleus. The nucleus records all information on the damage sustained. |
---|
652 | <literal>G4TheoFS-Generator</literal> forwards all information to the classical cascade, |
---|
653 | that propagates the particles in the already damaged nucleus, keeping track of |
---|
654 | interactions, further damage to the nucleus, etc.. Once the cascade assumptions |
---|
655 | break down, the cascade will collect the information of the current state of |
---|
656 | the hadronic system, like excitation energy and number of excited particles, |
---|
657 | and interpret it as a pre-compound system. It delegates the decay of this to |
---|
658 | the exciton model. The exciton model will take the information provided, and |
---|
659 | calculate |
---|
660 | transitions and emissions, until the number of excitons in the system equals |
---|
661 | the mean number of excitons expected in equilibrium for the current excitation |
---|
662 | energy. Then it hands over to the |
---|
663 | evaporation phase. The evaporation phase decays the residual nucleus, and the Chain of |
---|
664 | Command rolls back to <literal>G4TheoFS-Generator</literal>, accumulating the |
---|
665 | information produced in the various levels of delegation. |
---|
666 | </para> |
---|
667 | |
---|
668 | </sect2> |
---|
669 | |
---|
670 | <!-- ******************* Section (Level#2) ****************** --> |
---|
671 | <sect2 id="sect.ExtdFuncHadPhys.L4F_StgPartIntNuc"> |
---|
672 | <title> |
---|
673 | Level 4 Frameworks - String Parton Models and Intra-Nuclear Cascade |
---|
674 | </title> |
---|
675 | |
---|
676 | <para> |
---|
677 | <figure id="fig.ExtdFuncHadPhys_6"> |
---|
678 | <title> |
---|
679 | Level 4 implementation framework of the hadronic category of Geant4; |
---|
680 | parton string aspect. |
---|
681 | </title> |
---|
682 | <mediaobject> |
---|
683 | <imageobject role="fo"> |
---|
684 | <imagedata fileref="./AllResources/GuideToExtendFunctionality/HadronicPhysics/Level4_1.jpg" |
---|
685 | format="JPG" contentwidth="10.0cm" align="center" /> |
---|
686 | </imageobject> |
---|
687 | <imageobject role="html"> |
---|
688 | <imagedata fileref="./AllResources/GuideToExtendFunctionality/HadronicPhysics/Level4_1.jpg" |
---|
689 | format="JPG" contentwidth="120%" align="center" /> |
---|
690 | </imageobject> |
---|
691 | </mediaobject> |
---|
692 | </figure> |
---|
693 | |
---|
694 | <figure id="fig.ExtdFuncHadPhys_7"> |
---|
695 | <title> |
---|
696 | Level 4 implementation framework of the hadronic category of Geant4; |
---|
697 | intra-nuclear transport aspect. |
---|
698 | </title> |
---|
699 | <mediaobject> |
---|
700 | <imageobject role="fo"> |
---|
701 | <imagedata fileref="./AllResources/GuideToExtendFunctionality/HadronicPhysics/Level4_2.jpg" |
---|
702 | format="JPG" contentwidth="10.0cm" align="center" /> |
---|
703 | </imageobject> |
---|
704 | <imageobject role="html"> |
---|
705 | <imagedata fileref="./AllResources/GuideToExtendFunctionality/HadronicPhysics/Level4_2.jpg" |
---|
706 | format="JPG" contentwidth="120%" align="center" /> |
---|
707 | </imageobject> |
---|
708 | </mediaobject> |
---|
709 | </figure> |
---|
710 | </para> |
---|
711 | |
---|
712 | <para> |
---|
713 | The use-cases of this level are related to commonalities and detailed choices |
---|
714 | in string-parton models and cascade models. They are use-cases of an expert |
---|
715 | user wishing to alter details of a model, or a theoretical physicist, wishing |
---|
716 | to study details of a particular model. |
---|
717 | </para> |
---|
718 | |
---|
719 | <!-- ******* Bridgehead ******* --> |
---|
720 | <bridgehead renderas='sect4'> |
---|
721 | Requirements |
---|
722 | </bridgehead> |
---|
723 | |
---|
724 | <para> |
---|
725 | <orderedlist spacing="compact"> |
---|
726 | <listitem><para> |
---|
727 | Allow to select string decay algorithm |
---|
728 | </para></listitem> |
---|
729 | <listitem><para> |
---|
730 | Allow to select string excitation. |
---|
731 | </para></listitem> |
---|
732 | <listitem><para> |
---|
733 | Allow the selection of concrete implementations of three-dimensional |
---|
734 | models of the nucleus |
---|
735 | </para></listitem> |
---|
736 | <listitem><para> |
---|
737 | Allow the selection of concrete implementations of final state and |
---|
738 | cross sections in intra-nuclear scattering. |
---|
739 | </para></listitem> |
---|
740 | </orderedlist> |
---|
741 | </para> |
---|
742 | |
---|
743 | <!-- ******* Bridgehead ******* --> |
---|
744 | <bridgehead renderas='sect4'> |
---|
745 | Design and interfaces |
---|
746 | </bridgehead> |
---|
747 | |
---|
748 | <para> |
---|
749 | To fulfil the requirements on string models, two abstract classes are provided, |
---|
750 | the <literal>G4VParton-StringModel</literal> and the |
---|
751 | <literal>G4VString-Fragmentation</literal>. |
---|
752 | The base class for parton string models, <literal>G4VParton-StringModel</literal>, |
---|
753 | declares the <literal>GetStrings()</literal> pure virtual method. |
---|
754 | <literal>G4VString-Fragmentation</literal>, the pure abstract base class for string |
---|
755 | fragmentation, declares the interface for string fragmentation. |
---|
756 | </para> |
---|
757 | |
---|
758 | <para> |
---|
759 | To fulfill the requirements on intra-nuclear transport, two abstract classes |
---|
760 | are provided, <literal>G4V3DNucleus</literal>, and <literal>G4VScatterer</literal>. |
---|
761 | At this point in time, the usage of these intra-nuclear transport related classes |
---|
762 | by concrete codes is not enforced by designs, as the details of the |
---|
763 | cascade loop are still model dependent, and more experience has to be gathered to achieve |
---|
764 | standardisation. It is within the responsibility of the implementers of concrete |
---|
765 | intra-nuclear transport |
---|
766 | codes to use the abstract interfaces as defined in these classes. |
---|
767 | </para> |
---|
768 | |
---|
769 | <para> |
---|
770 | The class diagram is shown in |
---|
771 | <xref linkend="fig.ExtdFuncHadPhys_6" /> |
---|
772 | for the string parton model aspects, and in |
---|
773 | <xref linkend="fig.ExtdFuncHadPhys_7" /> |
---|
774 | for the intra-nuclear transport. |
---|
775 | </para> |
---|
776 | |
---|
777 | |
---|
778 | <!-- ******* Bridgehead ******* --> |
---|
779 | <bridgehead renderas='sect4'> |
---|
780 | Framework functionality |
---|
781 | </bridgehead> |
---|
782 | |
---|
783 | <para> |
---|
784 | Again variants of Strategy, Bridge and Chain of Responsibility are used. |
---|
785 | <literal>G4VParton-StringModel</literal> implements the initialisation of a |
---|
786 | three-dimensional model of a nucleus, and the logic of scattering. It |
---|
787 | delegates secondary production to string fragmentation through a |
---|
788 | <literal>G4VString-Fragmentation</literal> pointer. It provides a registering service for |
---|
789 | the concrete string fragmentation, and delegates the string excitation to |
---|
790 | derived classes. Selection of string excitation is through selection of |
---|
791 | derived class. Selection of string fragmentation is through registration. |
---|
792 | </para> |
---|
793 | |
---|
794 | </sect2> |
---|
795 | |
---|
796 | <!-- ******************* Section (Level#2) ****************** --> |
---|
797 | <sect2 id="sect.ExtdFuncHadPhys.L5F_StrgDeExc"> |
---|
798 | <title> |
---|
799 | Level 5 Framework - String De-excitation} |
---|
800 | </title> |
---|
801 | |
---|
802 | <para> |
---|
803 | <figure id="fig.ExtdFuncHadPhys_8"> |
---|
804 | <title> |
---|
805 | Level 5 implementation framework of the hadronic category of Geant4; |
---|
806 | string fragmentation aspect. |
---|
807 | </title> |
---|
808 | <mediaobject> |
---|
809 | <imageobject role="fo"> |
---|
810 | <imagedata fileref="./AllResources/GuideToExtendFunctionality/HadronicPhysics/Level5_1.jpg" |
---|
811 | format="JPG" contentwidth="10.0cm" align="center" /> |
---|
812 | </imageobject> |
---|
813 | <imageobject role="html"> |
---|
814 | <imagedata fileref="./AllResources/GuideToExtendFunctionality/HadronicPhysics/Level5_1.jpg" |
---|
815 | format="JPG" contentwidth="120%" align="center" /> |
---|
816 | </imageobject> |
---|
817 | </mediaobject> |
---|
818 | </figure> |
---|
819 | </para> |
---|
820 | |
---|
821 | <para> |
---|
822 | The use-case of this level is that of a user or theoretical physicist wishing |
---|
823 | to understand the systematic effects involved in combining various |
---|
824 | fragmentation functions with individual types of string fragmentation. Note |
---|
825 | that this framework level is meeting the current state of the art, making |
---|
826 | extensions and changes of interfaces in subsequent releases likely. |
---|
827 | </para> |
---|
828 | |
---|
829 | <!-- ******* Bridgehead ******* --> |
---|
830 | <bridgehead renderas='sect4'> |
---|
831 | Requirements |
---|
832 | </bridgehead> |
---|
833 | |
---|
834 | <para> |
---|
835 | <orderedlist spacing="compact"> |
---|
836 | <listitem><para> |
---|
837 | Allow the selection of fragmentation function. |
---|
838 | </para></listitem> |
---|
839 | </orderedlist> |
---|
840 | </para> |
---|
841 | |
---|
842 | <!-- ******* Bridgehead ******* --> |
---|
843 | <bridgehead renderas='sect4'> |
---|
844 | Design and interfaces |
---|
845 | </bridgehead> |
---|
846 | |
---|
847 | <para> |
---|
848 | A base class for fragmentation functions, |
---|
849 | <literal>G4VFragmentation-Function}</literal>, is |
---|
850 | provided. It declares the <literal>GetLightConeZ()</literal> interface. |
---|
851 | </para> |
---|
852 | |
---|
853 | <!-- ******* Bridgehead ******* --> |
---|
854 | <bridgehead renderas='sect4'> |
---|
855 | Framework functionality |
---|
856 | </bridgehead> |
---|
857 | |
---|
858 | <para> |
---|
859 | The design is a basic Strategy. The class diagram is shown in |
---|
860 | <xref linkend="fig.ExtdFuncHadPhys_8" />. |
---|
861 | At this point in time, the usage of the |
---|
862 | <literal>G4VFragmentation-Function</literal> is not enforced by design, |
---|
863 | but made available from the |
---|
864 | <literal>G4VString-Fragmentation</literal> to an implementer of a concrete string |
---|
865 | decay. <literal>G4VString-Fragmentation</literal> provides a registering |
---|
866 | mechanism for the |
---|
867 | concrete fragmentation function. It delegates the calculation of |
---|
868 | z<subscript>f</subscript> of the |
---|
869 | hadron to split of the string to the concrete implementation. Standardisation |
---|
870 | in this area is expected. |
---|
871 | </para> |
---|
872 | |
---|
873 | </sect2> |
---|
874 | </sect1> |
---|