1 | <!-- ******************************************************** --> |
---|
2 | <!-- --> |
---|
3 | <!-- [History] --> |
---|
4 | <!-- Converted to DocBook: Katsuya Amako, Aug-2006 --> |
---|
5 | <!-- Changed by: Dennis Wright, 29-Nov-2001 --> |
---|
6 | <!-- Changed by: Katsuya Amako, 9-Jul-1998 --> |
---|
7 | <!-- Changed by: Katsuya Amako, 30-Nov-1998 --> |
---|
8 | <!-- Proof read by: Joe Chuma, 28-Jun-1999 --> |
---|
9 | <!-- --> |
---|
10 | <!-- ******************************************************** --> |
---|
11 | |
---|
12 | |
---|
13 | <!-- ******************* Section (Level#1) ****************** --> |
---|
14 | <sect1 id="sect.Run"> |
---|
15 | <title> |
---|
16 | Run |
---|
17 | </title> |
---|
18 | |
---|
19 | <!-- ******************* Section (Level#2) ****************** --> |
---|
20 | <sect2 id="sect.Run.Basic"> |
---|
21 | <title> |
---|
22 | Basic concept of <emphasis>Run</emphasis> |
---|
23 | </title> |
---|
24 | |
---|
25 | <para> |
---|
26 | In Geant4, <emphasis>Run</emphasis> is the largest unit of simulation. A run |
---|
27 | consists of a sequence of events. Within a run, the detector |
---|
28 | geometry, the set up of sensitive detectors, and the physics |
---|
29 | processes used in the simulation should be kept unchanged. A run is |
---|
30 | represented by a <emphasis>G4Run</emphasis> class object. A run starts with |
---|
31 | <literal>BeamOn()</literal> method of <emphasis>G4RunManager</emphasis>. |
---|
32 | </para> |
---|
33 | |
---|
34 | |
---|
35 | <!-- ******************* Section (Level#3) ****************** --> |
---|
36 | <sect3 id="sect.Run.Basic.Rep"> |
---|
37 | <title> |
---|
38 | Representation of a run |
---|
39 | </title> |
---|
40 | |
---|
41 | <para> |
---|
42 | <emphasis>G4Run</emphasis> represents a run. It has a run identification |
---|
43 | number, which should be set by the user, and the number of events |
---|
44 | simulated during the run. Please note that the run identification |
---|
45 | number is not used by the Geant4 kernel, and thus can be |
---|
46 | arbitrarily assigned at the user's convenience. |
---|
47 | </para> |
---|
48 | |
---|
49 | <para> |
---|
50 | <emphasis>G4Run</emphasis> has pointers to the tables |
---|
51 | <emphasis>G4VHitsCollection</emphasis> |
---|
52 | and <emphasis>G4VDigiCollection</emphasis>. These tables are associated |
---|
53 | in case <emphasis>sensitive detectors</emphasis> and |
---|
54 | <emphasis>digitizer modules</emphasis> are |
---|
55 | simulated, respectively. The usage of these tables will be |
---|
56 | mentioned in <xref linkend="sect.Hits" /> and <xref linkend="sect.Digi" />. |
---|
57 | </para> |
---|
58 | |
---|
59 | </sect3> |
---|
60 | |
---|
61 | <!-- ******************* Section (Level#3) ****************** --> |
---|
62 | <sect3 id="sect.Run.Basic.Manage"> |
---|
63 | <title> |
---|
64 | Manage the run procedures |
---|
65 | </title> |
---|
66 | |
---|
67 | <para> |
---|
68 | <emphasis>G4RunManager</emphasis> manages the procedures of a run. In the |
---|
69 | constructor of <emphasis>G4RunManager</emphasis>, all of the manager classes in |
---|
70 | Geant4 kernel, except for some static managers, are constructed. |
---|
71 | These managers are deleted in the destructor of |
---|
72 | <emphasis>G4RunManager</emphasis>. <emphasis>G4RunManager</emphasis> |
---|
73 | must be a singleton, and |
---|
74 | the pointer to this singleton object can be obtained by the |
---|
75 | <literal>getRunManager()</literal> static method. |
---|
76 | </para> |
---|
77 | |
---|
78 | <para> |
---|
79 | As already mentioned in <xref linkend="sect.HowToDefMain" />, all of the |
---|
80 | <emphasis>user initialization</emphasis> classes and |
---|
81 | <emphasis>user action</emphasis> classes |
---|
82 | defined by the user should be assigned to <emphasis>G4RunManager</emphasis> |
---|
83 | before starting initialization of the Geant4 kernel. The |
---|
84 | assignments of these user classes are done by |
---|
85 | <literal>SetUserInitialization()</literal> and <literal>SetUserAction()</literal> |
---|
86 | methods. All user classes defined by the Geant4 kernel will be |
---|
87 | summarized in <xref linkend="chap.UserActions" />. |
---|
88 | </para> |
---|
89 | |
---|
90 | <para> |
---|
91 | <emphasis>G4RunManager</emphasis> has several public methods, which are listed |
---|
92 | below. |
---|
93 | |
---|
94 | <variablelist><title></title> |
---|
95 | <varlistentry> |
---|
96 | <term><literal>Initialize()</literal></term> |
---|
97 | <listitem> |
---|
98 | All initializations required by the Geant4 kernel are triggered |
---|
99 | by this method. Initializations are: |
---|
100 | |
---|
101 | <itemizedlist spacing="compact"> |
---|
102 | <listitem><para> |
---|
103 | construction of the detector geometry and set up of sensitive |
---|
104 | detectors and/or digitizer modules, |
---|
105 | </para></listitem> |
---|
106 | <listitem><para> |
---|
107 | construction of particles and physics processes, |
---|
108 | </para></listitem> |
---|
109 | <listitem><para> |
---|
110 | calculation of cross-section tables. |
---|
111 | </para></listitem> |
---|
112 | </itemizedlist> |
---|
113 | |
---|
114 | This method is thus mandatory before proceeding to the first run. |
---|
115 | This method will be invoked automatically for the second and later |
---|
116 | runs in case some of the initialized quantities need to be updated. |
---|
117 | </listitem> |
---|
118 | </varlistentry> |
---|
119 | <varlistentry> |
---|
120 | <term><literal>BeamOn(G4int numberOfEvent)</literal></term> |
---|
121 | <listitem> |
---|
122 | This method triggers the actual simulation of a run, that is, |
---|
123 | an event loop. It takes an integer argument which represents the |
---|
124 | number of events to be simulated. |
---|
125 | </listitem> |
---|
126 | </varlistentry> |
---|
127 | <varlistentry> |
---|
128 | <term><literal>GetRunManager()</literal></term> |
---|
129 | <listitem> |
---|
130 | This static method returns the pointer to the |
---|
131 | <emphasis>G4RunManager</emphasis> singleton object. |
---|
132 | </listitem> |
---|
133 | </varlistentry> |
---|
134 | <varlistentry> |
---|
135 | <term><literal>GetCurrentEvent()</literal></term> |
---|
136 | <listitem> |
---|
137 | This method returns the pointer to the <emphasis>G4Event</emphasis> object |
---|
138 | which is currently being simulated. This method is available only |
---|
139 | when an event is being processed. At this moment, the application |
---|
140 | state of Geant4, which is explained in the following sub-section, |
---|
141 | is <emphasis>"EventProc"</emphasis>. When Geant4 is in a state other than |
---|
142 | <emphasis>"EventProc"</emphasis>, this method returns |
---|
143 | <literal>null</literal>. |
---|
144 | Please note that the return value of this method is |
---|
145 | <literal>const G4Event *</literal> and thus you cannot modify the |
---|
146 | contents of the object. |
---|
147 | </listitem> |
---|
148 | </varlistentry> |
---|
149 | <varlistentry> |
---|
150 | <term><literal>SetNumberOfEventsToBeStored(G4int nPrevious)</literal></term> |
---|
151 | <listitem> |
---|
152 | When simulating the "pile up" of more than one event, it is |
---|
153 | essential to access more than one event at the same moment. By |
---|
154 | invoking this method, <emphasis>G4RunManager</emphasis> keeps <literal>nPrevious |
---|
155 | G4Event</literal> objects. This method must be invoked before proceeding |
---|
156 | to <literal>BeamOn()</literal>. |
---|
157 | </listitem> |
---|
158 | </varlistentry> |
---|
159 | <varlistentry> |
---|
160 | <term><literal>GetPreviousEvent(G4int i_thPrevious)</literal></term> |
---|
161 | <listitem> |
---|
162 | The pointer to the <literal>i_thPrevious G4Event</literal> object can be |
---|
163 | obtained through this method. A pointer to a <literal>const</literal> object |
---|
164 | is returned. It is inevitable that <literal>i_thPrevious</literal> events |
---|
165 | must have already been simulated in the same run for getting the |
---|
166 | <literal>i_thPrevious</literal> event. Otherwise, this method returns |
---|
167 | <literal>null</literal>. |
---|
168 | </listitem> |
---|
169 | </varlistentry> |
---|
170 | <varlistentry> |
---|
171 | <term><literal>AbortRun()</literal></term> |
---|
172 | <listitem> |
---|
173 | This method should be invoked whenever the processing of a run |
---|
174 | must be stopped. It is valid for <emphasis>GeomClosed</emphasis> and |
---|
175 | <emphasis>EventProc</emphasis> states. Run processing will be safely aborted even |
---|
176 | in the midst of processing an event. However, the last event of the |
---|
177 | aborted run will be incomplete and should not be used for further |
---|
178 | analysis. |
---|
179 | </listitem> |
---|
180 | </varlistentry> |
---|
181 | </variablelist> |
---|
182 | </para> |
---|
183 | |
---|
184 | </sect3> |
---|
185 | |
---|
186 | |
---|
187 | <!-- ******************* Section (Level#3) ****************** --> |
---|
188 | <sect3 id="sect.Run.Basic.UserRunAction"> |
---|
189 | <title> |
---|
190 | <emphasis>G4UserRunAction</emphasis> |
---|
191 | </title> |
---|
192 | |
---|
193 | <para> |
---|
194 | <emphasis>G4UserRunAction</emphasis> is one of the <emphasis>user action</emphasis> |
---|
195 | classes from which you can derive your own concrete class. This base class |
---|
196 | has two virtual methods, as follows: |
---|
197 | |
---|
198 | |
---|
199 | <variablelist><title></title> |
---|
200 | <varlistentry> |
---|
201 | <term><literal>BeginOfRunAction()</literal></term> |
---|
202 | <listitem> |
---|
203 | This method is invoked at the beginning of the |
---|
204 | <literal>BeamOn()</literal> method but after confirmation of the conditions |
---|
205 | of the Geant4 kernel. Likely uses of this method include: |
---|
206 | |
---|
207 | <itemizedlist spacing="compact"> |
---|
208 | <listitem><para> |
---|
209 | setting a run identification number, |
---|
210 | </para></listitem> |
---|
211 | <listitem><para> |
---|
212 | booking histograms, |
---|
213 | </para></listitem> |
---|
214 | <listitem><para> |
---|
215 | setting run specific conditions of the sensitive detectors |
---|
216 | and/or digitizer modules (e.g., dead channels). |
---|
217 | </para></listitem> |
---|
218 | </itemizedlist> |
---|
219 | </listitem> |
---|
220 | </varlistentry> |
---|
221 | <varlistentry> |
---|
222 | <term><literal>EndOfRunAction()</literal></term> |
---|
223 | <listitem> |
---|
224 | This method is invoked at the very end of the <literal>BeamOn()</literal> |
---|
225 | method. Typical use cases of this method are |
---|
226 | |
---|
227 | <itemizedlist spacing="compact"> |
---|
228 | <listitem><para> |
---|
229 | store/print histograms, |
---|
230 | </para></listitem> |
---|
231 | <listitem><para> |
---|
232 | manipulate run summaries. |
---|
233 | </para></listitem> |
---|
234 | </itemizedlist> |
---|
235 | </listitem> |
---|
236 | </varlistentry> |
---|
237 | </variablelist> |
---|
238 | </para> |
---|
239 | |
---|
240 | </sect3> |
---|
241 | </sect2> |
---|
242 | |
---|
243 | <!-- ******************* Section (Level#2) ****************** --> |
---|
244 | <sect2 id="sect.Run.StateMac"> |
---|
245 | <title> |
---|
246 | Geant4 as a state machine |
---|
247 | </title> |
---|
248 | |
---|
249 | <para> |
---|
250 | Geant4 is designed as a state machine. Some methods in Geant4 are |
---|
251 | available for only a certain state(s). <emphasis>G4RunManager</emphasis> controls |
---|
252 | the state changes of the Geant4 application. States of Geant4 are |
---|
253 | represented by the enumeration <emphasis>G4ApplicationState</emphasis>. It has |
---|
254 | six states through the life cycle of a Geant4 application. |
---|
255 | |
---|
256 | |
---|
257 | <variablelist><title></title> |
---|
258 | <varlistentry> |
---|
259 | <term><emphasis>G4State_PreInit</emphasis> state</term> |
---|
260 | <listitem> |
---|
261 | A Geant4 application starts with this state. The application |
---|
262 | needs to be initialized when it is in this state. The application |
---|
263 | occasionally comes back to this state if geometry, physics |
---|
264 | processes, and/or cut-off have been changed after processing a |
---|
265 | run. |
---|
266 | </listitem> |
---|
267 | </varlistentry> |
---|
268 | <varlistentry> |
---|
269 | <term><emphasis>G4State_Init</emphasis> state</term> |
---|
270 | <listitem> |
---|
271 | The application is in this state while the |
---|
272 | <literal>Initialize()</literal> method of <emphasis>G4RunManager</emphasis> |
---|
273 | is being invoked. Methods defined in any |
---|
274 | <emphasis>user initialization</emphasis> classes |
---|
275 | are invoked during this state. |
---|
276 | </listitem> |
---|
277 | </varlistentry> |
---|
278 | <varlistentry> |
---|
279 | <term><emphasis>G4State_Idle</emphasis> state</term> |
---|
280 | <listitem> |
---|
281 | The application is ready for starting a run. |
---|
282 | </listitem> |
---|
283 | </varlistentry> |
---|
284 | <varlistentry> |
---|
285 | <term><emphasis>G4State_GeomClosed</emphasis> state</term> |
---|
286 | <listitem> |
---|
287 | When <literal>BeamOn()</literal> is invoked, the application proceeds to |
---|
288 | this state to process a run. Geometry, physics processes, and |
---|
289 | cut-off cannot be changed during run processing. |
---|
290 | </listitem> |
---|
291 | </varlistentry> |
---|
292 | <varlistentry> |
---|
293 | <term><emphasis>G4State_EventProc</emphasis> state</term> |
---|
294 | <listitem> |
---|
295 | A Geant4 application is in this state when a particular event |
---|
296 | is being processed. <literal>GetCurrentEvent()</literal> and |
---|
297 | <literal>GetPreviousEvent()</literal> methods of |
---|
298 | <emphasis>G4RunManager</emphasis> are |
---|
299 | available only at this state. |
---|
300 | </listitem> |
---|
301 | </varlistentry> |
---|
302 | <varlistentry> |
---|
303 | <term><emphasis>G4State_Quit</emphasis> state</term> |
---|
304 | <listitem> |
---|
305 | When the destructor of <emphasis>G4RunManager</emphasis> is invoked, the |
---|
306 | application comes to this "dead end" state. Managers of the Geant4 |
---|
307 | kernel are being deleted and thus the application cannot come back |
---|
308 | to any other state. |
---|
309 | </listitem> |
---|
310 | </varlistentry> |
---|
311 | <varlistentry> |
---|
312 | <term><emphasis>G4State_Abort</emphasis> state</term> |
---|
313 | <listitem> |
---|
314 | When a <emphasis>G4Exception</emphasis> occurs, the application comes to this |
---|
315 | "dead end" state and causes a core dump. The user still has a hook |
---|
316 | to do some "safe" opperations, e.g. storing histograms, by |
---|
317 | implementing a user concrete class of <emphasis>G4VStateDependent</emphasis>. The |
---|
318 | user also has a choice to suppress the occurence of |
---|
319 | <emphasis>G4Exception</emphasis> by a UI command |
---|
320 | <emphasis>/control/suppressAbortion</emphasis>. When abortion is suppressed, you |
---|
321 | will still get error messages issued by G4Exception, and there is |
---|
322 | NO guarantee of a correct result after the G4Exception error |
---|
323 | message. |
---|
324 | </listitem> |
---|
325 | </varlistentry> |
---|
326 | </variablelist> |
---|
327 | |
---|
328 | <emphasis>G4StateManager</emphasis> belongs to the <emphasis>intercoms</emphasis> |
---|
329 | category. |
---|
330 | </para> |
---|
331 | |
---|
332 | </sect2> |
---|
333 | |
---|
334 | |
---|
335 | <!-- ******************* Section (Level#2) ****************** --> |
---|
336 | <sect2 id="sect.Run.UserHook"> |
---|
337 | <title> |
---|
338 | User's hook for state change |
---|
339 | </title> |
---|
340 | |
---|
341 | <para> |
---|
342 | In case the user wants to do something at the moment of state |
---|
343 | change of Geant4, the user can create a concrete class of the |
---|
344 | <emphasis>G4VStateDependent</emphasis> base class. For example, the user can |
---|
345 | store histograms when G4Exception occurs and Geant4 comes to the |
---|
346 | <emphasis>Abort</emphasis> state, but before the actual core dump. |
---|
347 | </para> |
---|
348 | |
---|
349 | <para> |
---|
350 | The following is an example user code which stores histograms |
---|
351 | when Geant4 becomes to the <emphasis>Abort</emphasis> state. This class object |
---|
352 | should be mabe in, for example <emphasis>main()</emphasis>, by the user code. |
---|
353 | This object will be automatically registered to |
---|
354 | <emphasis>G4StateManager</emphasis> at its construction. |
---|
355 | </para> |
---|
356 | |
---|
357 | <example id="programlist_Run_1"> |
---|
358 | <title> |
---|
359 | Header file of UserHookForAbortState |
---|
360 | </title> |
---|
361 | <programlisting> |
---|
362 | #ifndef UserHookForAbortState_H |
---|
363 | #define UserHookForAbortState_H 1 |
---|
364 | |
---|
365 | #include "G4VStateDependent.hh" |
---|
366 | |
---|
367 | class UserHookForAbortState : public G4VStateDependent |
---|
368 | { |
---|
369 | public: |
---|
370 | UserHookForAbortState(); // constructor |
---|
371 | ~UserHookForAbortState(); // destructor |
---|
372 | |
---|
373 | virtual G4bool Notify(G4ApplicationState requiredState); |
---|
374 | }; |
---|
375 | </programlisting> |
---|
376 | </example> |
---|
377 | |
---|
378 | |
---|
379 | <example id="programlist_Run_2"> |
---|
380 | <title> |
---|
381 | Source file of UserHookForAbortState |
---|
382 | </title> |
---|
383 | <programlisting> |
---|
384 | #include "UserHookForAbortState.hh" |
---|
385 | |
---|
386 | UserHookForAbortState::UserHookForAbortState() {;} |
---|
387 | UserHookForAbortState::~UserHookForAbortState() {;} |
---|
388 | |
---|
389 | G4bool UserHookForAbortState::Notify(G4ApplicationState requiredState) |
---|
390 | { |
---|
391 | if(requiredState!=Abort) return true; |
---|
392 | |
---|
393 | // Do book keeping here |
---|
394 | |
---|
395 | return true; |
---|
396 | } |
---|
397 | </programlisting> |
---|
398 | </example> |
---|
399 | |
---|
400 | </sect2> |
---|
401 | |
---|
402 | |
---|
403 | <!-- ******************* Section (Level#2) ****************** --> |
---|
404 | <sect2 id="sect.Run.Custom"> |
---|
405 | <title> |
---|
406 | Customizing the Run Manager |
---|
407 | </title> |
---|
408 | |
---|
409 | |
---|
410 | <!-- ******************* Section (Level#3) ****************** --> |
---|
411 | <sect3 id="sect.Run.Custom.VirMeth"> |
---|
412 | <title> |
---|
413 | Virtual Methods in the Run Manager |
---|
414 | </title> |
---|
415 | |
---|
416 | <para> |
---|
417 | <literal>G4RunManager</literal> is a concrete class with a complete set of |
---|
418 | functionalities for managing the Geant4 kernel. It is the only |
---|
419 | manager class in the Geant4 kernel which must be constructed in the |
---|
420 | <literal>main()</literal> method of the user's application. Thus, instead of |
---|
421 | constructing the <literal>G4RunManager</literal> provided by Geant4, you are |
---|
422 | free to construct your own <literal>RunManager</literal>. It is recommended, |
---|
423 | however, that your <literal>RunManager</literal> inherit |
---|
424 | <literal>G4RunManager</literal>. For this purpose, <literal>G4RunManager</literal> has |
---|
425 | various virtual methods which provide all the functionalities |
---|
426 | required to handle the Geant4 kernel. Hence, your customized run |
---|
427 | manager need only override the methods particular to your needs; |
---|
428 | the remaining methods in <literal>G4RunManager</literal> base class can still |
---|
429 | be used. A summary of the available methods is presented here: |
---|
430 | |
---|
431 | |
---|
432 | <variablelist><title></title> |
---|
433 | <varlistentry> |
---|
434 | <term><literal>public: virtual void Initialize();</literal></term> |
---|
435 | <listitem> |
---|
436 | main entry point of Geant4 kernel initialization |
---|
437 | </listitem> |
---|
438 | </varlistentry> |
---|
439 | <varlistentry> |
---|
440 | <term><literal>protected: virtual void InitializeGeometry();</literal></term> |
---|
441 | <listitem> |
---|
442 | geometry construction |
---|
443 | </listitem> |
---|
444 | </varlistentry> |
---|
445 | <varlistentry> |
---|
446 | <term><literal>protected: virtual void InitializePhysics();</literal></term> |
---|
447 | <listitem> |
---|
448 | physics processes construction |
---|
449 | </listitem> |
---|
450 | </varlistentry> |
---|
451 | <varlistentry> |
---|
452 | <term><literal>public: virtual void BeamOn(G4int n_event);</literal></term> |
---|
453 | <listitem> |
---|
454 | main entry point of the event loop |
---|
455 | </listitem> |
---|
456 | </varlistentry> |
---|
457 | <varlistentry> |
---|
458 | <term><literal>protected: virtual G4bool ConfirmBeamOnCondition();</literal></term> |
---|
459 | <listitem> |
---|
460 | check the kernel conditions for the event loop |
---|
461 | </listitem> |
---|
462 | </varlistentry> |
---|
463 | <varlistentry> |
---|
464 | <term><literal>protected: virtual void RunInitialization();</literal></term> |
---|
465 | <listitem> |
---|
466 | prepare a run |
---|
467 | </listitem> |
---|
468 | </varlistentry> |
---|
469 | <varlistentry> |
---|
470 | <term><literal>protected: virtual void DoEventLoop(G4int n_events);</literal></term> |
---|
471 | <listitem> |
---|
472 | manage an event loop |
---|
473 | </listitem> |
---|
474 | </varlistentry> |
---|
475 | <varlistentry> |
---|
476 | <term><literal>protected: virtual G4Event* GenerateEvent(G4int i_event);</literal></term> |
---|
477 | <listitem> |
---|
478 | generation of <emphasis>G4Event</emphasis> object |
---|
479 | </listitem> |
---|
480 | </varlistentry> |
---|
481 | <varlistentry> |
---|
482 | <term><literal>protected: virtual void AnalyzeEvent(G4Event* anEvent);</literal></term> |
---|
483 | <listitem> |
---|
484 | storage/analysis of an event |
---|
485 | </listitem> |
---|
486 | </varlistentry> |
---|
487 | <varlistentry> |
---|
488 | <term><literal>protected: virtual void RunTermination();</literal></term> |
---|
489 | <listitem> |
---|
490 | terminate a run |
---|
491 | </listitem> |
---|
492 | </varlistentry> |
---|
493 | <varlistentry> |
---|
494 | <term><literal>public: virtual void DefineWorldVolume(G4VPhysicalVolume * worldVol);</literal></term> |
---|
495 | <listitem> |
---|
496 | set the world volume to <emphasis>G4Navigator</emphasis> |
---|
497 | </listitem> |
---|
498 | </varlistentry> |
---|
499 | <varlistentry> |
---|
500 | <term><literal>public: virtual void AbortRun();</literal></term> |
---|
501 | <listitem> |
---|
502 | abort the run |
---|
503 | </listitem> |
---|
504 | </varlistentry> |
---|
505 | </variablelist> |
---|
506 | </para> |
---|
507 | |
---|
508 | </sect3> |
---|
509 | |
---|
510 | <!-- ******************* Section (Level#3) ****************** --> |
---|
511 | <sect3 id="sect.Run.Custom.EventLoop"> |
---|
512 | <title> |
---|
513 | Customizing the Event Loop |
---|
514 | </title> |
---|
515 | |
---|
516 | <para> |
---|
517 | In <literal>G4RunManager</literal> the event loop is handled by the |
---|
518 | virtual method <literal>DoEventLoop()</literal>. This method is implemented |
---|
519 | by a <literal>for</literal> loop consisting of the following steps: |
---|
520 | |
---|
521 | <orderedlist spacing="compact"> |
---|
522 | <listitem><para> |
---|
523 | construct a <literal>G4Event</literal> object and assign to it primary |
---|
524 | vertex(es) and primary particles. This is done by the virtual |
---|
525 | <literal>GeneratePrimaryEvent()</literal> method. |
---|
526 | </para></listitem> |
---|
527 | <listitem><para> |
---|
528 | send the <literal>G4Event</literal> object to <literal>G4EventManager</literal> |
---|
529 | for the detector simulation. <emphasis>Hits</emphasis> and |
---|
530 | <emphasis>trajectories</emphasis> will |
---|
531 | be associated with the <literal>G4Event</literal> object as a |
---|
532 | consequence. |
---|
533 | </para></listitem> |
---|
534 | <listitem><para> |
---|
535 | perform bookkeeping for the current <literal>G4Event</literal> object. |
---|
536 | This is done by the virtual <literal>AnalyzeEvent()</literal> method. |
---|
537 | </para></listitem> |
---|
538 | </orderedlist> |
---|
539 | </para> |
---|
540 | |
---|
541 | <para> |
---|
542 | <literal>DoEventLoop()</literal> performs the entire simulation of an |
---|
543 | event. However, it is often useful to split the above three steps |
---|
544 | into isolated application programs. If, for example, you wish to |
---|
545 | examine the effects of changing discriminator thresholds, ADC gate |
---|
546 | widths and/or trigger conditions on simulated events, much time can |
---|
547 | be saved by performing steps 1 and 2 in one program and step 3 in |
---|
548 | another. The first program need only generate the hit/trajectory |
---|
549 | information once and store it, perhaps in a database. The second |
---|
550 | program could then retrieve the stored <literal>G4Event</literal> objects and |
---|
551 | perform the digitization (analysis) using the above threshold, gate |
---|
552 | and trigger settings. These settings could then be changed and the |
---|
553 | digitization program re-run without re-generating the |
---|
554 | <literal>G4Event</literal>s. |
---|
555 | </para> |
---|
556 | |
---|
557 | </sect3> |
---|
558 | |
---|
559 | <!-- ******************* Section (Level#3) ****************** --> |
---|
560 | <sect3 id="sect.Run.Custom.Geometry"> |
---|
561 | <title> |
---|
562 | Changing the Detector Geometry |
---|
563 | </title> |
---|
564 | |
---|
565 | <para> |
---|
566 | The detector geometry defined in your |
---|
567 | <emphasis>G4VUserDetectorConstruction</emphasis> concrete class can be changed |
---|
568 | during a run break (between two runs). Two different cases are |
---|
569 | considered. |
---|
570 | </para> |
---|
571 | |
---|
572 | <para> |
---|
573 | The first is the case in which you want to delete the entire |
---|
574 | structure of your old geometry and build up a completely new set of |
---|
575 | volumes. For this case, you need to set the new world physical |
---|
576 | volume pointer to the <emphasis>RunManager</emphasis>. Thus, you should proceed |
---|
577 | in the following way. |
---|
578 | |
---|
579 | <informalexample> |
---|
580 | <programlisting> |
---|
581 | G4RunManager* runManager = G4RunManager::GetRunManager(); |
---|
582 | runManager->DefineWorldVolume( newWorldPhys ); |
---|
583 | </programlisting> |
---|
584 | </informalexample> |
---|
585 | |
---|
586 | Presumably this case is rather rare. The second case is more |
---|
587 | frequent for the user. |
---|
588 | </para> |
---|
589 | |
---|
590 | <para> |
---|
591 | The second case is the following. Suppose you want to move |
---|
592 | and/or rotate a particular piece of your detector component. This |
---|
593 | case can easily happen for a beam test of your detector. It is |
---|
594 | obvious for this case that you need not change the world volume. |
---|
595 | Rather, it should be said that your world volume (experimental hall |
---|
596 | for your beam test) should be big enough for moving/rotating your |
---|
597 | test detector. For this case, you can still use all of your |
---|
598 | detector geometries, and just use a <literal>Set</literal> method of a |
---|
599 | particular physical volume to update the transformation vector as |
---|
600 | you want. Thus, you don't need to re-set your world volume pointer |
---|
601 | to <emphasis>RunManager</emphasis>. |
---|
602 | </para> |
---|
603 | |
---|
604 | <para> |
---|
605 | If you want to change your geometry for every run, you can |
---|
606 | implement it in the <literal>BeginOfRunAction()</literal> method of |
---|
607 | <emphasis>G4UserRunAction</emphasis> class, which will be invoked at the |
---|
608 | beginning of each run, or, derive the <literal>RunInitialization()</literal> |
---|
609 | method. Please note that, for both of the above mentioned cases, |
---|
610 | you need to let <emphasis>RunManager</emphasis> know "the geometry needs to be |
---|
611 | closed again". Thus, you need to invoke |
---|
612 | |
---|
613 | <informalexample> |
---|
614 | <programlisting> |
---|
615 | runManager->GeometryHasBeenModified(); |
---|
616 | </programlisting> |
---|
617 | </informalexample> |
---|
618 | |
---|
619 | before proceeding to the next run. An example of changing geometry |
---|
620 | is given in a Geant4 tutorial in Geant4 Training kit #2. |
---|
621 | </para> |
---|
622 | |
---|
623 | </sect3> |
---|
624 | |
---|
625 | <!-- ******************* Section (Level#3) ****************** --> |
---|
626 | <sect3 id="sect.Run.Custom.SwitchPhys"> |
---|
627 | <title> |
---|
628 | Switch physics processes |
---|
629 | </title> |
---|
630 | |
---|
631 | <para> |
---|
632 | In the <literal>InitializePhysics()</literal> method, |
---|
633 | <literal>G4VUserPhysicsList::Construct</literal> is invoked in order to |
---|
634 | define particles and physics processes in your application. |
---|
635 | Basically, you can not add nor remove any particles during |
---|
636 | execution, because particles are static objects in Geant4 (see |
---|
637 | <xref linkend="sect.HowToSpecParti" /> and |
---|
638 | <xref linkend="sect.Parti" /> for details). |
---|
639 | In addition, it is very difficult to add and/or remove physics |
---|
640 | processes during execution, because registration procedures are |
---|
641 | very complex, except for experts (see <xref linkend="sect.HowToSpecPhysProc" /> |
---|
642 | and <xref linkend="sect.PhysProc" />). |
---|
643 | This is why the <literal>initializePhysics()</literal> method is assumed |
---|
644 | to be invoked at once in Geant4 kernel initialization. |
---|
645 | </para> |
---|
646 | |
---|
647 | <para> |
---|
648 | However, you can switch on/off physics processes defined in your |
---|
649 | <emphasis>G4VUserPhysicsList</emphasis> concrete class and also change parameters |
---|
650 | in physics processes during the run break. |
---|
651 | </para> |
---|
652 | |
---|
653 | <para> |
---|
654 | You can use <literal>ActivateProcess()</literal> and |
---|
655 | <literal>InActivateProcess()</literal> methods of <emphasis>G4ProcessManager</emphasis> |
---|
656 | anywhere outside the event loop to switch on/off some process. You |
---|
657 | should be very careful to switch on/off processes inside the event |
---|
658 | loop, though it is not prohibited to use these methods even in the |
---|
659 | <emphasis>EventProc</emphasis> state. |
---|
660 | </para> |
---|
661 | |
---|
662 | <para> |
---|
663 | It is a likely case to change cut-off values in a run. You can |
---|
664 | change <literal>defaultCutValue</literal> in |
---|
665 | <emphasis>G4VUserPhysicsList</emphasis> |
---|
666 | during the <emphasis>Idle</emphasis> state. In this case, all cross section |
---|
667 | tables need to be recalculated before the event loop. You should use the |
---|
668 | <literal>CutOffHasBeenModified()</literal> method when you change cut-off |
---|
669 | values so that the <literal>SetCuts</literal> method of your |
---|
670 | <emphasis>PhysicsList</emphasis> concrete class will be invoked. |
---|
671 | </para> |
---|
672 | |
---|
673 | |
---|
674 | </sect3> |
---|
675 | </sect2> |
---|
676 | </sect1> |
---|