[904] | 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> |
---|