1 | |
---|
2 | \chapter{Hadronic Physics} |
---|
3 | |
---|
4 | % This is a verbatim of a paper published in a refereed journal. |
---|
5 | % A suggestion by one of the documentation referees to re-write completely |
---|
6 | % seems quite inappropriate. |
---|
7 | |
---|
8 | \section{Introduction} |
---|
9 | Optimal exploitation of hadronic final |
---|
10 | states played a key role in successes of all recent collider experiment in HEP, |
---|
11 | and the ability to use hadronic final states will continue to be one of the |
---|
12 | decisive issues during the analysis phase of the LHC experiments. |
---|
13 | Monte Carlo programs like {\sc Geant4\cite{Geant4}} facilitate the use of |
---|
14 | hadronic final states, and have been developed for many years. |
---|
15 | |
---|
16 | We give an overview of the Object Oriented frameworks for hadronic generators |
---|
17 | in {\sc Geant4}, and illustrate the physics models underlying hadronic shower |
---|
18 | simulation on examples, including the three basic types of modeling; |
---|
19 | data-driven, parametrisation-driven, and theory-driven modeling, and their |
---|
20 | possible realisations in the Object Oriented component system of {\sc Geant4}. |
---|
21 | We put particular focus on the level of extendibility that can and has been |
---|
22 | achieved by our Russian dolls approach to Object Oriented design, and the |
---|
23 | role and importance of the frameworks in a component system. |
---|
24 | |
---|
25 | \section{Principal Considerations} |
---|
26 | The purpose of this section is to explain the implementation frameworks used |
---|
27 | in and provided by {\sc Geant4} for hadronic shower simulation as in the 1.1 |
---|
28 | release of the program. The implementation frameworks follow the Russian dolls |
---|
29 | approach to implementation framework design. |
---|
30 | A top-level, very abstracting implementation framework provides the basic |
---|
31 | interface to the other {\sc Geant4} categories, and fulfils the most general |
---|
32 | use-case for hadronic shower simulation. It is refined for more specific |
---|
33 | use-cases by implementing a hierarchy of implementation frameworks, each level |
---|
34 | implementing the common logic of a particular use-case package in a concrete |
---|
35 | implementation of the interface specification of one framework level above, |
---|
36 | this way refining the granularity of abstraction and delegation. This defines |
---|
37 | the Russian dolls architectural pattern. |
---|
38 | Abstract classes are used as the delegation |
---|
39 | mechanism\footnote{The same can be achieved with template specialisations |
---|
40 | with slightly improved CPU performance but at the cost of significantly more |
---|
41 | complex designs and, with present compilers, significantly reduced |
---|
42 | portability.}. |
---|
43 | All framework functional requirements were obtained through use-case analysis. |
---|
44 | In the following we present for each framework level the compressed use-cases, |
---|
45 | requirements, designs including the flexibility provided, and illustrate the |
---|
46 | framework functionality with examples. All design patterns cited are to |
---|
47 | be read as defined in \cite{Patterns}. |
---|
48 | |
---|
49 | \section{Level 1 Framework - processes} |
---|
50 | There are two principal use-cases of the level 1 framework. A user will |
---|
51 | want to choose the processes used for his particular simulation run, and a |
---|
52 | physicist will want to write code for processes of his own and use these |
---|
53 | together with the rest of the system in a seamless manner. |
---|
54 | |
---|
55 | \paragraph{Requirements} |
---|
56 | \begin{enumerate} |
---|
57 | \item \label{L1R1} Provide a standard interface to be used by process implementations. |
---|
58 | \item \label{L1R2} Provide registration mechanisms for processes. |
---|
59 | \end{enumerate} |
---|
60 | \paragraph{Design and interfaces} |
---|
61 | Both requirements are implemented in a sub-set of the tracking-physics |
---|
62 | interface in {\sc Geant4}. The class diagram is shown in figure \ref{Level1}. |
---|
63 | |
---|
64 | \begin{figure}[htbp] % fig 1 |
---|
65 | %\includegraphics[scale=0.75]{GuideToExtendFunctionality/HadronicPhysics/Level1.ps} |
---|
66 | \includegraphics[width=14cm]{GuideToExtendFunctionality/HadronicPhysics/Level1.eps} |
---|
67 | %% \centerline{\epsfig{file=GuideToExtendFunctionality/HadronicPhysics/Level1.eps,scale=0.8,angle=0}} |
---|
68 | \caption{Level 1 implementation framework of the hadronic category |
---|
69 | of {\sc Geant4}.} |
---|
70 | \label{Level1} |
---|
71 | \end{figure} |
---|
72 | |
---|
73 | All processes have a common base-class {\tt G4VProcess}, from which a set of |
---|
74 | specialised classes are derived. Three of them are used as base classes for |
---|
75 | hadronic processes for particles at rest ({\tt G4VRestProcess}), for |
---|
76 | interactions in flight ({\tt G4VDiscreteProcess}), and for processes like |
---|
77 | radioactive decay where the same implementation can represent both these |
---|
78 | extreme cases ({\tt G4VRestDiscrete\-Process}). |
---|
79 | |
---|
80 | Each of these classes declares two types of methods; one for calculating the |
---|
81 | time to interaction or the physical interaction length, allowing tracking to |
---|
82 | request the information necessary to decide on the process responsible for |
---|
83 | final state production, and one to compute the final state. These are pure |
---|
84 | virtual methods, and have to be implemented in each individual derived class, |
---|
85 | as enforced by the compiler. |
---|
86 | |
---|
87 | \paragraph{Framework functionality} |
---|
88 | The functionality provided is through the use of process base-class pointers |
---|
89 | in the tracking-physics interface, and the {\tt G4Process\-Manager}. All |
---|
90 | functionality is implemented in abstract, and registration of derived process |
---|
91 | classes with the {\tt G4Process\-Manager} of an individual particle allows for |
---|
92 | arbitrary combination of both {\sc Geant4} provided processes, and |
---|
93 | user-implemented processes. This registration mechanism is a modification on a |
---|
94 | Chain of Responsibility. It is outside the scope of the current paper, and its |
---|
95 | description is available from \cite{G4Manual}. |
---|
96 | |
---|
97 | \section{Level 2 Framework - Cross Sections and Models} |
---|
98 | |
---|
99 | At the next level of abstraction, only processes that occur for particles |
---|
100 | in flight are considered. For these, it is easily observed that the sources |
---|
101 | of cross sections and final state production are rarely the same. Also, |
---|
102 | different sources will come with different restrictions. The principal |
---|
103 | use-cases of the framework are addressing these commonalities. A user might |
---|
104 | want to combine different cross sections and final state or isotope production |
---|
105 | models as provided by {\sc Geant4}, and a physicist might |
---|
106 | want to implement his own model for particular situation, and add cross-section |
---|
107 | data sets that are relevant for his particular analysis to the system in a |
---|
108 | seamless manner. |
---|
109 | \paragraph{Requirements} |
---|
110 | \begin{enumerate} |
---|
111 | \item Flexible choice of inclusive scattering cross-sections. |
---|
112 | \item Ability to use different data-sets for different parts of |
---|
113 | the simulation, depending on the conditions at the point of interaction. |
---|
114 | \item Ability to add user-defined data-sets in a seamless manner. |
---|
115 | \item Flexible, unconstrained choice of final state production models. |
---|
116 | \item Ability to use different final state production codes |
---|
117 | for different parts of the simulation, depending on the conditions at the |
---|
118 | point of interaction. |
---|
119 | \item Ability to add user-defined final state production models in |
---|
120 | a seamless manner. |
---|
121 | \item Flexible choice of isotope production models, to run in |
---|
122 | parasitic mode to any kind of transport models. |
---|
123 | \item Ability to use different isotope production codes |
---|
124 | for different parts of the simulation, depending on the conditions at the |
---|
125 | point of interaction. |
---|
126 | \item Ability to add user-defined isotope production models in a |
---|
127 | seamless manner. |
---|
128 | \end{enumerate} |
---|
129 | |
---|
130 | \paragraph{Design and interfaces} |
---|
131 | The above requirements are implemented in three framework components, one |
---|
132 | for cross-sections, final state production, and isotope production each. |
---|
133 | The class diagrams are shown in figure \ref{Level2_1} for the cross-section |
---|
134 | aspects, figure \ref{Level2_2} for the final state production aspects, |
---|
135 | and figure \ref{Level2_3} for the isotope production aspects. |
---|
136 | |
---|
137 | \begin{figure}[htbp] % fig 2 |
---|
138 | %\includegraphics[scale=0.75]{GuideToExtendFunctionality/HadronicPhysics/Level2_1.ps} |
---|
139 | \includegraphics[width=14cm]{GuideToExtendFunctionality/HadronicPhysics/Level2_1.eps} |
---|
140 | %% \centerline{\epsfig{file=GuideToExtendFunctionality/HadronicPhysics/Level2_1.ps,scale=0.8,angle=0}} |
---|
141 | \caption{Level 2 implementation framework of the hadronic category |
---|
142 | of {\sc Geant4}; cross-section aspect.} |
---|
143 | \label{Level2_1} |
---|
144 | \end{figure} |
---|
145 | |
---|
146 | \begin{figure}[htbp] % fig 3 |
---|
147 | %\includegraphics[scale=0.75]{GuideToExtendFunctionality/HadronicPhysics/Level2_2.ps} |
---|
148 | \includegraphics[width=14cm]{GuideToExtendFunctionality/HadronicPhysics/Level2_2.eps} |
---|
149 | %% \centerline{\epsfig{file=GuideToExtendFunctionality/HadronicPhysics/Level2_2.ps,scale=0.8,angle=0}} |
---|
150 | \caption{Level 2 implementation framework of the hadronic category |
---|
151 | of {\sc Geant4}; final state production aspect.} |
---|
152 | \label{Level2_2} |
---|
153 | \end{figure} |
---|
154 | |
---|
155 | \begin{figure}[htbp] % fig 4 |
---|
156 | %\includegraphics[scale=0.75]{GuideToExtendFunctionality/HadronicPhysics/Level2_3.ps} |
---|
157 | \includegraphics[width=14cm]{GuideToExtendFunctionality/HadronicPhysics/Level2_3.eps} |
---|
158 | %% \centerline{\epsfig{file=GuideToExtendFunctionality/HadronicPhysics/Level2_3.ps,scale=0.8,angle=0}} |
---|
159 | \caption{Level 2 implementation framework of the hadronic category |
---|
160 | of {\sc Geant4}; isotope production aspect} |
---|
161 | \label{Level2_3} |
---|
162 | \end{figure} |
---|
163 | |
---|
164 | The three parts are integrated in the {\tt G4Hadronic\-Process} class, that |
---|
165 | serves as base-class for all hadronic processes of particles in flight. |
---|
166 | \paragraph{Cross-sections} |
---|
167 | Each hadronic process is derived from {\tt G4Hadronic\-Process}, which |
---|
168 | holds a list of ``cross section data sets''. |
---|
169 | The term ``data set'' is |
---|
170 | representing an object that encapsulates methods and data for calculating |
---|
171 | total cross sections for a given process in a certain range of validity. |
---|
172 | The implementations may take any form. It can be a simple equation as well as |
---|
173 | sophisticated parameterisations, or evaluated data. |
---|
174 | All cross section data set classes are derived from the abstract class |
---|
175 | {\tt G4VCrossSection\-DataSet}, which declares methods that allow |
---|
176 | the process inquire, about the applicability of an individual data-set through |
---|
177 | \\ |
---|
178 | {\tt IsApplicable(const G4DynamicParticle*, const G4Element*)}, |
---|
179 | \\ |
---|
180 | and to de\-le\-gate the calculation of the actual cross-section value through |
---|
181 | \\ |
---|
182 | {\tt GetCrossSection(const G4DynamicParticle*, const G4Element*)}. |
---|
183 | \paragraph{Final state production} |
---|
184 | The {\tt G4HadronicInteraction} base class is provided for final state |
---|
185 | generation. It declares a minimal interface of only one pure virtual method: |
---|
186 | \\ |
---|
187 | {\tt G4VParticleChange* ApplyYourself(const G4Track \&, G4Nucleus \&)}. |
---|
188 | \\ |
---|
189 | {\tt G4HadronicProcess} provides a registry for final state |
---|
190 | production models inheriting from {\tt G4Hadronic\-Interaction}. Again, final |
---|
191 | state production model is meant in very general terms. This can be an |
---|
192 | implementation of a quark gluon string model\cite{QGSM}, a sampling code for |
---|
193 | ENDF/B data formats \cite{ENDFForm}, or a parametrisation describing only |
---|
194 | neutron elastic scattering off Silicon up to 300~MeV. |
---|
195 | \paragraph{Isotope production} |
---|
196 | For isotope production, a base class ({\tt G4VIsotope\-Production}) is |
---|
197 | provided. It declares a method \\ |
---|
198 | {\tt G4IsoResult * GetIsotope(const G4Track \&, const G4Nucleus \&)} \\ |
---|
199 | that calculates and returns the isotope production information. Any concrete |
---|
200 | isotope production model will inherit from this class, and implement the |
---|
201 | method. Again, the modeling possibilities are not limited, and the |
---|
202 | implementation of concrete production models is not restricted in any way. |
---|
203 | By convention, the {\tt GetIsotope} method returns NULL, if the model |
---|
204 | is not applicable for the current projectile target combination. |
---|
205 | \paragraph{Framework functionality:} |
---|
206 | \paragraph{Cross Sections} |
---|
207 | {\tt G4HadronicProcess} provides registering possibilities for data sets. |
---|
208 | A default is provided covering all possible conditions to some approximation. |
---|
209 | The process stores and retrieves the data sets through a data store that acts |
---|
210 | like a FILO stack (a Chain of Responsibility with a |
---|
211 | First In Last Out decision strategy). This allows the user to map out |
---|
212 | the entire parameter space by overlaying cross section data sets to optimise |
---|
213 | the overall result. Examples are the cross sections for low energy neutron |
---|
214 | transport. If these are registered last by the user, they will be used |
---|
215 | whenever low energy neutrons are encountered. In all other conditions the |
---|
216 | system falls back on the default, or data sets with earlier registration dates. |
---|
217 | The fact that the registration is done through abstract base classes with no |
---|
218 | side-effects allows the user to implement and use his own cross sections. |
---|
219 | Examples are special reaction cross sections of $K^0$-nuclear interactions |
---|
220 | that might be used for $\epsilon/\epsilon '$ analysis at LHC to control the |
---|
221 | systematic error. |
---|
222 | \paragraph{Final state production} |
---|
223 | The {\tt G4HadronicProcess} class provides a registration service for classes |
---|
224 | deriving from {\tt G4Hadronic\-Interaction}, and delegates final state |
---|
225 | production to the applicable model. |
---|
226 | {\tt G4Hadronic\-Interaction} provides the functionality needed to define and |
---|
227 | enforce the applicability of a particular model. Models inheriting from |
---|
228 | {\tt G4Hadronic\-Interaction} can be restricted in applicability in projectile |
---|
229 | type and energy, and can be activated/deactivated for individual materials and |
---|
230 | elements. This allows a user to use final state production models in |
---|
231 | arbitrary combinations, and to write his own models for |
---|
232 | final state production. The design is a variant of a Chain of Responsibility. |
---|
233 | An example would be the likely CMS scenario - the combination of low energy |
---|
234 | neutron transport with a quantum molecular dynamics\cite{QMD} or chiral |
---|
235 | invariant phase space decay\cite{CHIPS} model in the case of tracker materials |
---|
236 | and fast parametrised models for calorimeter materials, with user defined |
---|
237 | modeling of interactions of spallation nucleons with the most abundant |
---|
238 | tracker and calorimeter materials. |
---|
239 | \paragraph{Isotope production} |
---|
240 | The {\tt G4HadronicProcess} by default calculates the isotope production |
---|
241 | information from the final state given by the transport model. In addition, it |
---|
242 | provides a registering mechanism for isotope production models that run in |
---|
243 | parasitic mode to the transport models and inherit from |
---|
244 | {\tt G4VIsotope\-Production}. The registering mechanism behaves like a FILO |
---|
245 | stack, again based on Chain of Responsibility. The models will be asked for |
---|
246 | isotope production information in inverse order of registration. The first |
---|
247 | model that returns a non-NULL value will be applied. In addition, the |
---|
248 | {\tt G4Hadronic\-Process} provides the basic infrastructure for accessing and |
---|
249 | steering of isotope-production information. It allows to enable and disable |
---|
250 | the calculation of isotope production information globally, or for individual |
---|
251 | processes, and to retrieve the isotope production information through the |
---|
252 | \\ |
---|
253 | {\tt G4IsoParticleChange * GetIsotopeProductionInfo()} |
---|
254 | \\ |
---|
255 | method at the end of each step. The {\tt G4HadronicProcess} is a finite state |
---|
256 | machine that will ensure the {\tt GetIsotope\-ProductionInfo} returns a |
---|
257 | non-zero value only at the first call after isotope production occurred. An |
---|
258 | example of the use of this functionality is the study of activation of a |
---|
259 | Germanium detector in a high precision, low background experiment. |
---|
260 | \section{Level 3 Framework - Theoretical Models} |
---|
261 | \begin{figure}[htbp] % fig 5 |
---|
262 | %\includegraphics[scale=0.75]{GuideToExtendFunctionality/HadronicPhysics/Level3_1.ps} |
---|
263 | \includegraphics[width=14cm]{GuideToExtendFunctionality/HadronicPhysics/Level3_1.eps} |
---|
264 | %% \centerline{\epsfig{file=GuideToExtendFunctionality/HadronicPhysics/Level3_1.ps,scale=1.0,angle=-90}} |
---|
265 | \caption{Level 3 implementation framework of the hadronic category |
---|
266 | of {\sc Geant4}; theoretical model aspect.} |
---|
267 | \label{Level3_1} |
---|
268 | \end{figure} |
---|
269 | {\sc Geant4} provides at present one implementation framework for theory |
---|
270 | driven models. The main use-case is that of a user wishing to use theoretical |
---|
271 | models in general, and to use various intra-nuclear transport or pre-compound |
---|
272 | models together with models simulating the initial interactions at very high |
---|
273 | energies. |
---|
274 | \paragraph{Requirements} |
---|
275 | \begin{enumerate} |
---|
276 | \item Allow to use or adapt any string-parton or parton transport\cite{VNI} |
---|
277 | model. |
---|
278 | \item Allow to adapt event generators, ex. PYTHIA\cite{PYTHIA7} for final |
---|
279 | state production in shower simulation. |
---|
280 | \item Allow for combination of the above with any intra-nuclear transport |
---|
281 | (INT). |
---|
282 | \item Allow stand-alone use of intra-nuclear transport. |
---|
283 | \item Allow for combination of the above with any pre-compound model. |
---|
284 | \item Allow stand-alone use of any pre-compound model. |
---|
285 | \item Allow for use of any evaporation code. |
---|
286 | \item Allow for seamless integration of user defined components for any of the above. |
---|
287 | \end{enumerate} |
---|
288 | \paragraph{Design and interfaces} |
---|
289 | To provide the above flexibility, the following abstract base classes have been |
---|
290 | implemented: |
---|
291 | \begin{itemize} |
---|
292 | \item {\tt G4VHighEnergyGenerator} |
---|
293 | \item {\tt G4VIntranuclearTransportModel} |
---|
294 | \item {\tt G4VPreCompoundModel} |
---|
295 | \item {\tt G4VExcitationHandler} |
---|
296 | \end{itemize} |
---|
297 | In addition, the class {\tt G4TheoFS\-Generator} is provided to orchestrate |
---|
298 | interactions between these classes. The class diagram is shown in |
---|
299 | Fig. \ref{Level3_1}. |
---|
300 | |
---|
301 | {\tt G4VHighEnergy\-Generator} serves as base class for parton transport or |
---|
302 | parton string models, and for Adapters to event generators. This class |
---|
303 | declares two methods, {\tt Scatter}, and {\tt GetWoundedNucleus}. |
---|
304 | |
---|
305 | The base class for INT inherits from {\tt G4Hadronic\-Interaction}, making any |
---|
306 | concrete implementation usable as a stand-alone model. In doing so, it |
---|
307 | re-declares the {\tt ApplyYourself} interface of {\tt G4Hadronic\-Interaction}, |
---|
308 | and adds a second interface, {\tt Propagate}, for further propagation |
---|
309 | after high energy interactions. {\tt Propagate} takes as arguments a |
---|
310 | three-dimensional model of a wounded nucleus, and a set of secondaries with |
---|
311 | energies and positions. |
---|
312 | |
---|
313 | The base class for pre-equilibrium decay models, {\tt G4VPre\-CompoundModel}, |
---|
314 | inherits from {\tt G4Hadronic\-Interaction}, again making any concrete |
---|
315 | implementation usable as stand-alone model. It adds a pure virtual |
---|
316 | {\tt DeExcite} method for further evolution of the system when intra-nuclear |
---|
317 | transport assumptions break down. {\tt DeExcite} takes a {\tt G4Fragment}, |
---|
318 | the {\sc Geant4} representation of an excited nucleus, as argument. |
---|
319 | |
---|
320 | The base class for evaporation phases, {\tt G4VExcitation\-Handler}, declares |
---|
321 | an abstract method, {\tt BreakItUP()}, for compound decay. |
---|
322 | |
---|
323 | \paragraph{Framework functionality} |
---|
324 | The {\tt G4TheoFSGenerator} class inherits from {\tt G4Hadronic\-Interaction}, |
---|
325 | and hence can be registered as a model for final state production with a |
---|
326 | hadronic process. It allows a concrete implementation of |
---|
327 | {\tt G4VIntranuclear\-TransportModel} and {\tt G4VHighEnergy\-Generator} to be |
---|
328 | registered, and delegates initial interactions, and intra-nuclear transport |
---|
329 | of the corresponding secondaries to the respective classes. The design is a |
---|
330 | complex variant of a Strategy. The most spectacular application of this |
---|
331 | pattern is the use of parton-string models for string excitation, quark |
---|
332 | molecular dynamics for correlated string decay, and quantum molecular dynamics |
---|
333 | for transport, a combination which promises to result in a coherent |
---|
334 | description of quark gluon plasma in high energy nucleus-nucleus interactions. |
---|
335 | |
---|
336 | The class {\tt G4VIntranuclearTransportModel} provides registering mechanisms |
---|
337 | for concrete implementations of {\tt G4VPreCompound\-Model}, and provides |
---|
338 | concrete intra-nuclear transports with the possibility of delegating |
---|
339 | pre-compound decay to these models. |
---|
340 | |
---|
341 | {\tt G4VPreCompoundModel} provides a registering mechanism for compound decay |
---|
342 | through the {\tt G4VExcitation\-Handler} interface, and provides concrete |
---|
343 | implementations with the possibility of delegating the decay of a compound |
---|
344 | nucleus. |
---|
345 | |
---|
346 | The concrete scenario of {\tt G4TheoFS\-Generator} using a dual parton model |
---|
347 | and a classical cascade, which in turn uses an exciton pre-compound model that |
---|
348 | delegates to an evaporation phase, would be the following: |
---|
349 | {\tt G4TheoFS\-Generator} receives the conditions of the interaction; a |
---|
350 | primary particle and a nucleus. It asks the dual parton model to perform the |
---|
351 | initial scatterings, and return the final state, along with the by then |
---|
352 | damaged nucleus. The nucleus records all information on the damage sustained. |
---|
353 | {\tt G4TheoFS\-Generator} forwards all information to the classical cascade, |
---|
354 | that propagates the particles in the already damaged nucleus, keeping track of |
---|
355 | interactions, further damage to the nucleus, etc.. Once the cascade assumptions |
---|
356 | break down, the cascade will collect the information of the current state of |
---|
357 | the hadronic system, like excitation energy and number of excited particles, |
---|
358 | and interpret it as a pre-compound system. It delegates the decay of this to |
---|
359 | the exciton model. The exciton model will take the information provided, and |
---|
360 | calculate |
---|
361 | transitions and emissions, until the number of excitons in the system equals the mean number of |
---|
362 | excitons expected in equilibrium for the current excitation energy. Then it hands over to the |
---|
363 | evaporation phase. The evaporation phase decays the residual nucleus, and the Chain of |
---|
364 | Command rolls back to {\tt G4TheoFS\-Generator}, accumulating the information produced in |
---|
365 | the various levels of delegation. |
---|
366 | \section{Level 4 Frameworks - String Parton Models and Intra-Nuclear Cascade} |
---|
367 | |
---|
368 | \begin{figure}[htbp] % fig 1 |
---|
369 | %\includegraphics[scale=0.75]{GuideToExtendFunctionality/HadronicPhysics/Level4_1.ps} |
---|
370 | \includegraphics[width=14cm]{GuideToExtendFunctionality/HadronicPhysics/Level4_1.eps} |
---|
371 | %% \centerline{\epsfig{file=GuideToExtendFunctionality/HadronicPhysics/Level4_1.ps,scale=0.8,angle=0}} |
---|
372 | \caption{Level 4 implementation framework of the hadronic category |
---|
373 | of {\sc Geant4}; parton string aspect.} |
---|
374 | \label{Level4_1} |
---|
375 | \end{figure} |
---|
376 | |
---|
377 | \begin{figure}[htbp] % fig 1 |
---|
378 | %\includegraphics[scale=0.75]{GuideToExtendFunctionality/HadronicPhysics/Level4_2.ps} |
---|
379 | \includegraphics[width=14cm]{GuideToExtendFunctionality/HadronicPhysics/Level4_2.eps} |
---|
380 | %% \centerline{\epsfig{file=GuideToExtendFunctionality/HadronicPhysics/Level4_2.ps,scale=0.8,angle=0}} |
---|
381 | \caption{Level 4 implementation framework of the hadronic category |
---|
382 | of {\sc Geant4}; intra-nuclear transport aspect.} |
---|
383 | \label{Level4_2} |
---|
384 | \end{figure} |
---|
385 | The use-cases of this level are related to commonalities and detailed choices |
---|
386 | in string-parton models and cascade models. They are use-cases of an expert |
---|
387 | user wishing to alter details of a model, or a theoretical physicist, wishing |
---|
388 | to study details of a particular model. |
---|
389 | \paragraph{Requirements} |
---|
390 | \begin{enumerate} |
---|
391 | \item Allow to select string decay algorithm |
---|
392 | \item Allow to select string excitation. |
---|
393 | \item Allow the selection of concrete implementations of three-dimensional |
---|
394 | models of the nucleus |
---|
395 | \item Allow the selection of concrete implementations of final state and |
---|
396 | cross sections in intra-nuclear scattering. |
---|
397 | \end{enumerate} |
---|
398 | \paragraph{Design and interfaces} |
---|
399 | To fulfil the requirements on string models, two abstract classes are provided, |
---|
400 | the {\tt G4VParton\-StringModel} and the {\tt G4VString\-Fragmentation}. |
---|
401 | The base class for parton string models, {\tt G4VParton\-StringModel}, |
---|
402 | declares the {\tt GetStrings()} pure virtual method. |
---|
403 | {\tt G4VString\-Fragmentation}, the pure abstract base class for string |
---|
404 | fragmentation, declares the interface for string fragmentation. |
---|
405 | |
---|
406 | To fulfill the requirements on intra-nuclear transport, two abstract classes |
---|
407 | are provided, {\tt G4V3DNucleus}, and {\tt G4VScatterer}. |
---|
408 | At this point in time, the usage of these intra-nuclear transport related classes |
---|
409 | by concrete codes is not enforced by designs, as the details of the |
---|
410 | cascade loop are still model dependent, and more experience has to be gathered to achieve |
---|
411 | standardisation. It is within the responsibility of the implementers of concrete |
---|
412 | intra-nuclear transport |
---|
413 | codes to use the abstract interfaces as defined in these classes. |
---|
414 | |
---|
415 | The class diagram is shown in figure \ref{Level4_1} for the string parton model aspects, and |
---|
416 | in figure \ref{Level4_2} for the intra-nuclear transport. |
---|
417 | |
---|
418 | \paragraph{Framework functionality} |
---|
419 | Again variants of Strategy, Bridge and Chain of Responsibility are used. |
---|
420 | {\tt G4VParton\-StringModel} implements the initialisation of a |
---|
421 | three-dimensional model of a nucleus, and the logic of scattering. It |
---|
422 | delegates secondary production to string fragmentation through a |
---|
423 | {\tt G4VString\-Fragmentation} pointer. It provides a registering service for |
---|
424 | the concrete string fragmentation, and delegates the string excitation to |
---|
425 | derived classes. Selection of string excitation is through selection of |
---|
426 | derived class. Selection of string fragmentation is through registration. |
---|
427 | |
---|
428 | \section{Level 5 Framework - String De-excitation} |
---|
429 | |
---|
430 | \begin{figure}[htbp] % fig 1 |
---|
431 | %\includegraphics[scale=0.75]{GuideToExtendFunctionality/HadronicPhysics/Level5_1.ps} |
---|
432 | \includegraphics[width=14cm]{GuideToExtendFunctionality/HadronicPhysics/Level5_1.eps} |
---|
433 | %% \centerline{\epsfig{file=GuideToExtendFunctionality/HadronicPhysics/Level5_1.ps,scale=0.8,angle=0}} |
---|
434 | \caption{Level 5 implementation framework of the hadronic category |
---|
435 | of {\sc Geant4}; string fragmentation aspect.} |
---|
436 | \label{Level5_1} |
---|
437 | \end{figure} |
---|
438 | The use-case of this level is that of a user or theoretical physicist wishing |
---|
439 | to understand the systematic effects involved in combining various |
---|
440 | fragmentation functions with individual types of string fragmentation. Note |
---|
441 | that this framework level is meeting the current state of the art, making |
---|
442 | extensions and changes of interfaces in subsequent releases likely. |
---|
443 | \paragraph{Requirements} |
---|
444 | \begin{enumerate} |
---|
445 | \item Allow the selection of fragmentation function. |
---|
446 | \end{enumerate} |
---|
447 | \paragraph{Design and interfaces} |
---|
448 | A base class for fragmentation functions, {\tt G4VFragmentation\-Function}, is |
---|
449 | provided. It declares the {\tt GetLightConeZ()} interface. |
---|
450 | \paragraph{Framework functionality} |
---|
451 | The design is a basic Strategy. The class diagram is shown in |
---|
452 | Fig. \ref{Level5_1}. At this point in time, the usage of the |
---|
453 | {\tt G4VFragmentation\-Function} is not enforced by design, but made available |
---|
454 | from the {\tt G4VString\-Fragmentation} to an implementer of a concrete string |
---|
455 | decay. {\tt G4VString\-Fragmentation} provides a registering mechanism for the |
---|
456 | concrete fragmentation function. It delegates the calculation of $z_f$ of the |
---|
457 | hadron to split of the string to the concrete implementation. Standardisation |
---|
458 | in this area is expected. |
---|
459 | |
---|
460 | \begin{latexonly} |
---|
461 | \begin{thebibliography}{999} |
---|
462 | \bibitem{Geant4} The GEANT~4 Collaboration, \\ |
---|
463 | CERN/DRDC/94--29, DRDC/P58 1994. |
---|
464 | \bibitem{Patterns} E. Gamm et al., Design Patterns, Addison-Wesley Professional |
---|
465 | Computing Series, 1995. |
---|
466 | \bibitem{G4Manual} |
---|
467 | {\scriptsize http://cern.ch/wwwasd/geant4/G4UsersDocuments/Overview/html/index.html} |
---|
468 | \bibitem{QGSM} Kaidalov A. B., Ter-Martirosyan K. A., Phys. Lett. {\bf B117} |
---|
469 | 247 (1982); |
---|
470 | \bibitem{ENDFForm} |
---|
471 | Data Formats and Procedures for the Evaluated Nuclear Data File, National |
---|
472 | Nuclear Data Center, Brookhaven National Laboratory, Upton, NY, USA. |
---|
473 | \bibitem{QMD} For example: VUU and (R)QMD model of high-energy heavy ion |
---|
474 | collisions. H. Stocker et al., Nucl. Phys. A538, 53c-64c (1992) |
---|
475 | \bibitem{CHIPS} P.V. Degtyarenko, M.V. Kossov, H.P. Wellisch, |
---|
476 | Eur. Phys J. A 8, 217-222 (2000) |
---|
477 | \bibitem{VNI} VNI 3.1, Klaus Geiger (Brookhaven), BNL-63762, |
---|
478 | Comput. Phys. Commun. 104, 70-160 (1997) |
---|
479 | \bibitem{PYTHIA7} M. Bertini, L. L\"onnblad, T. Sj\"orstrand, Pythia version |
---|
480 | 7-0.0 -- a proof-of-concept version, LU-TP 00-23, hep-ph/0006152, May 2000 |
---|
481 | |
---|
482 | \end{thebibliography} |
---|
483 | \end{latexonly} |
---|
484 | |
---|
485 | \begin{htmlonly} |
---|
486 | \section{Bibliography} |
---|
487 | \begin{enumerate} |
---|
488 | |
---|
489 | \item The GEANT~4 Collaboration, \\ |
---|
490 | CERN/DRDC/94--29, DRDC/P58 1994. |
---|
491 | \item E. Gamm et al., Design Patterns, Addison-Wesley Professional |
---|
492 | Computing Series, 1995. |
---|
493 | \item |
---|
494 | {\scriptsize http://cern.ch/wwwasd/geant4/G4UsersDocuments/Overview/html/index.html} |
---|
495 | \item Kaidalov A. B., Ter-Martirosyan K. A., Phys. Lett. <b>B117</b> 247 |
---|
496 | (1982); |
---|
497 | \item |
---|
498 | Data Formats and Procedures for the Evaluated Nuclear Data File, National |
---|
499 | Nuclear Data Center, Brookhaven National Laboratory, Upton, NY, USA. |
---|
500 | \item For example: VUU and (R)QMD model of high-energy heavy ion |
---|
501 | collisions. H. Stocker et al., Nucl. Phys. A538, 53c-64c (1992) |
---|
502 | \item P.V. Degtyarenko, M.V. Kossov, H.P. Wellisch, |
---|
503 | Eur. Phys J. A 8, 217-222 (2000) |
---|
504 | \item VNI 3.1, Klaus Geiger (Brookhaven), BNL-63762, |
---|
505 | Comput. Phys. Commun. 104, 70-160 (1997) |
---|
506 | \item M. Bertini, L. L\"onnblad, T. Sj\"orstrand, Pythia version |
---|
507 | 7-0.0 -- a proof-of-concept version, LU-TP 00-23, hep-ph/0006152, May 2000 |
---|
508 | |
---|
509 | \end{enumerate} |
---|
510 | \end{htmlonly} |
---|