KAHIBARO
20.2. Run Commands
Table of Contents
`/run/initialize`
In a Geant4 application, /run/initialize is the macro command that prepares the simulation to start, using the current geometry, physics, and user actions. You normally do not call it from C++; instead, you type it in an interactive session or place it in a macro file.
When you execute /run/initialize, Geant4 asks the run manager to perform its initialization step. At this moment the run manager builds or rebuilds the internal data structures required to transport particles through your geometry with the chosen physics list. This includes creating the world geometry from your G4VUserDetectorConstruction, registering processes from the physics list, and preparing user actions such as RunAction and EventAction.
You must execute /run/initialize after you have finished configuring anything that affects geometry or physics, such as changing a detector dimension through a macro command or switching to a different reference physics list. If you change geometry or physics after an initialization, you have to call /run/initialize again to apply those changes. If you forget to reinitialize, the simulation will still run, but it will use the old configuration.
Rule: Call /run/initialize at least once before /run/beamOn.
Rule: If you change geometry or physics through macro commands, call /run/initialize again so that Geant4 rebuilds the setup.
During initialization, Geant4 does not simulate any events or tracks. No particles are generated and no output files are written. Initialization is only the preparation step. Once it finishes successfully, the application is ready to start one or more runs with /run/beamOn.
In a typical macro, you might see
/run/initialize
/run/printProgress 100
/run/beamOn 1000
Here /run/initialize is executed a single time before the first call to /run/beamOn. If you later execute geometry-modifying commands in the same session, you should insert another /run/initialize before starting a new run.
`/run/beamOn`
The /run/beamOn command starts a run and tells Geant4 how many events to simulate. The command takes one integer argument, for example
/run/beamOn 10000
which starts a new run of 10 000 events with the current setup. The primary particle generator (for example your PrimaryGeneratorAction or a configured GPS source) is called once per event, and the physics and tracking are applied to all primaries and secondaries produced in those events.
When you call /run/beamOn, Geant4 creates a new run. It calls the user RunAction begin-of-run method once, then loops over the requested number of events. For each event, it calls the user EventAction and all other registered user actions at the appropriate times. At the end of the loop, it calls the end-of-run method, then returns control to the user interface so you can type more commands or execute another macro.
You can call /run/beamOn multiple times in one session. Each call creates a separate run, but all runs share the same initialized geometry and physics unless you change them and reinitialize. The number of events given in /run/beamOn only affects how many events are processed in that particular run. It does not reset any geometry or physics, and it does not automatically clear your analysis objects; that behavior is defined by your own analysis code.
Rule: Always execute /run/beamOn with a positive integer argument, such as /run/beamOn 1000.
Rule: Do not rely on /run/beamOn to apply geometry or physics changes; use /run/initialize before starting a new run with changed settings.
The argument to /run/beamOn is interpreted as the total number of events to simulate in that run. Geant4 does not accumulate event counts across runs. If you call
/run/beamOn 100
/run/beamOn 200the application will simulate 100 events in the first run and 200 events in the second run. Whether you treat these 300 events together in your analysis depends on how you implement the handling of histograms and ntuples.
In practice, you usually combine /run/beamOn with other run control commands in macros. For example, you might set random seeds, adjust source parameters, or change production cuts, then call /run/beamOn to generate events under those conditions. Repeating this pattern with different settings lets you perform parameter scans without recompiling your code.
Views: 10