KAHIBARO
14.1. RunAction
Table of Contents
Beginning of a run
A RunAction class gives you a central place to react when a Geant4 run starts and ends. It connects the technical start of /run/beamOn to your own bookkeeping, analysis, and output.
You create it by deriving from G4UserRunAction, for example:
class RunAction : public G4UserRunAction {
public:
RunAction();
~RunAction() override;
void BeginOfRunAction(const G4Run* run) override;
void EndOfRunAction(const G4Run* run) override;
};
Geant4 calls BeginOfRunAction once at the start of every run, after /run/initialize and just before the first event of that run is processed. At this moment the random engine is ready, the geometry and physics are fixed for the run, and you can safely prepare anything that depends on them.
Inside BeginOfRunAction you typically perform three kinds of tasks.
First, you reset or initialize run level counters and accumulators. For example, you may set total energy deposition, number of detected events, or any other quantity you plan to sum over events in this run, back to zero. The actual accumulation is usually done in EventAction or SteppingAction, but the clean reset belongs in RunAction.
Second, you prepare your analysis output for the new run. With the Geant4 analysis manager, this is a natural place to create or open an output file, create histograms and ntuples if they depend on run specific information, and enable storing of data. For example, you might open a ROOT or CSV file whose name includes the run ID so that different runs do not overwrite each other.
Third, you can print basic information about the run. For instance, you can obtain the run ID via run->GetRunID() and write a short message to the screen or a log file. This helps when you later examine logs from several runs.
In multithreaded applications, BeginOfRunAction is called in each worker thread for that thread’s local run. Geant4 also has a separate master RunAction (if you define one) that receives BeginOfRunAction and EndOfRunAction only in the master thread, without events. For absolute beginners it is enough to remember that run level initialization that must be identical in each thread should be done in each worker RunAction, and any merging of data across threads should be left for the end of the run.
In BeginOfRunAction, always reset per run accumulators and open or initialize analysis objects that you will fill during the run. This avoids mixing data from different runs and prevents writing into closed or uninitialized output files.
End of a run
Geant4 calls EndOfRunAction once after all events in the run have finished, but before the next run starts or the program exits. No more tracking occurs during this call, so it is safe to finalize and write out all results that depend on completed events.
At this point, any quantities that you accumulated during the run, such as total energy deposition or number of hits, are ready to be summarized. A common pattern is that EventAction sends per event results to some run level storage (often through a pointer to RunAction or to a dedicated analysis object). EndOfRunAction then reads these run level values, computes averages, efficiencies, or other derived quantities, and prints or stores them.
Typical work inside EndOfRunAction includes computing run statistics, such as mean energy deposition, standard deviation, or detector efficiency, formatting them, and printing them to the console or a log file. If you use G4AnalysisManager, this is the place where you write histograms and ntuples to disk and close the output file. This ensures that all buffered data from the run are safely stored.
In a multithreaded job, each worker thread may produce its own partial results. Geant4 and the analysis manager can merge these worker outputs into a single master output at the end of the run. The master EndOfRunAction is then a good location to print final statistics that are based on the merged data.
Because EndOfRunAction marks a clear boundary between runs, it is useful to keep it free from event or step level logic. All detailed work should already be done by then, so this method can remain short, predictable, and focused on summarizing and closing.
In EndOfRunAction, always finalize run statistics, write and close analysis output files, and avoid changing geometry or physics. The run is finished, so use this hook only to summarize, merge, and safely store results from the completed run.
Views: 10