29.4. Reducing Unnecessary Output

Table of Contents

Why Output Can Limit Performance

Geant4 itself is usually fast enough for many problems. A very common bottleneck for beginners is not the physics or geometry, but the amount of information written to the terminal or to files. Printing at every step or storing every detail can slow a simulation by orders of magnitude and can also make it harder to find the information that actually matters.

The goal in this chapter is to show how to keep only the information you really need, at the right level of detail, and to remove or reduce everything else.

A single G4cout per step or per track in a large simulation can slow the code dramatically. Limit printing inside per-step or per-track user actions to exceptional debugging only.

Geant4 Verbosity Levels

Many Geant4 components provide built in verbosity settings. These let you control how much they print without changing your C++ code.

Typical examples include geometry, physics lists, tracking, and run/event managers. For instance, you can control run manager messages with macro commands like:
/run/verbose, /event/verbose, /tracking/verbose.

A typical strategy is to use high verbosity during development and debugging of a small number of events, and very low verbosity or completely silent running for large production runs.

Use high verbosity (1 or higher) only for a small number of events. For long runs, set all verbosity levels to 0 unless you have a specific reason to print.

Verbosity levels usually follow this pattern:

Verbosity level	Typical meaning
0	Silent or minimal errors only
1	Basic progress information
2	Detailed information (events, tracks)
3+	Very detailed debugging, step by step

During a production run, you usually combine:
/run/verbose 0, /event/verbose 0, /tracking/verbose 0, and similar commands to keep the output minimal.

Avoiding Excessive `G4cout` and `G4cerr`

The most common performance issue from output is uncontrolled use of G4cout and G4cerr in user code.

Printing inside SteppingAction, TrackingAction, SensitiveDetector::ProcessHits, or within loops over hits or particles can multiply into millions of lines for even a modest simulation. This is slow because text formatting and terminal output are much more expensive than arithmetic and physics calculations.

Instead of printing at every step, use conditions and counters to limit output. For example, only print for the first few events, for a particular particle type, or when an abnormal situation is detected.

You can implement a simple pattern to control printing in user code. Use a boolean or an integer counter as a gate, and only call G4cout when needed. Once you trust your implementation, disable or remove most print statements.

Rule: Never leave permanent G4cout calls inside per-step or per-hit code that runs for every event. Use them only temporarily for debugging and then remove or guard them.

Message and Tracking Managers

Beyond the top level verbosity commands, several Geant4 subsystems have their own fine grained verbosity controls.

The tracking system is a key example. The /tracking/verbose command controls how much is printed for each track and step. When set to a positive value, the tracking manager prints information for every step, which quickly becomes huge.

For large runs, always check that step level tracking output is disabled. To inspect specific tracks, run a tiny number of events with higher tracking verbosity, then revert to silent running for production.

In some cases you may also use physics related verbose flags to inspect cross sections or process selections for debugging, but those should be used only interactively with a small number of events.

Managing Analysis Output Size

Too much output is not only a terminal issue. Large analysis files can also slow simulation and post processing.

Geant4 analysis through G4AnalysisManager writes histograms and ntuples. Every column you define and every row you fill costs memory and disk space. Saving every step, or every secondary particle, can make files very large.

A practical approach is to decide at design time what you need to analyze: maybe one scalar per event, a few histograms, and limited per hit information. Avoid storing raw step level data unless you truly need it for a narrow study.

You can also reduce the frequency of writing by collecting results in memory and only writing at the end of the run. G4AnalysisManager handles buffering for you, but defining too many histograms or too many ntuple columns still affects both performance and clarity.

Only store information that you will actually analyze. Each extra histogram, column, or per step row increases file size and slows I/O.

Choosing What to Record

A useful way to reduce unnecessary output is to think in terms of derived quantities instead of raw details.

For example, instead of writing every step energy deposit and later summing to obtain the event energy, you can accumulate the sum in memory per event and record only the final total energy per event into an ntuple column.

Similarly, rather than recording every hit ever generated, you might only record hits that satisfy conditions like energy above a threshold, or hits in a specific detector element.

This kind of selection reduces both I/O and later analysis effort. You can implement it in EventAction, SteppingAction, or in your sensitive detector to filter out uninteresting data before it reaches the output layer.

Limiting Hits and Trajectories Visualization

Visualization output, especially of trajectories and hits, can also clutter the display and slow interactive runs, even if it is not written to disk.

Geant4 allows you to control visual output with macro commands in the visualization system. For instance, you can enable or disable drawing of trajectories, set trajectory filtering by particle type or energy, and control which hits collections are displayed.

When debugging geometry or basic behavior, drawing a few trajectories can be very informative. However, drawing trajectories for thousands of events can make the viewer slow and the scene unreadable.

For performance oriented interactive sessions, disable automatic trajectory drawing, and only enable it when testing a small sample of events. Similarly, keep hit visualization to a limited subset when investigating detector response.

Interactive vs Batch Output Settings

It is useful to distinguish between interactive sessions, where you may want more messages and visualization, and batch production runs, where you want minimal output.

You can maintain separate macro files, for example one called interactive.mac with higher verbosity and visualization commands, and another called batch.mac with low verbosity and no visualization.

In batch mode, you usually run Geant4 with a macro that sets all relevant verbosity levels to zero, disables unused visualization drivers, and restricts analysis output to the essential quantities. This keeps the batch run fast and produces concise, manageable output files.

For large batch runs, always use a quiet macro that disables visualization and sets all verbosities to 0, and only writes essential analysis data.

By separating your interactive and batch configurations, you can enjoy detailed feedback while developing, yet still achieve high performance and clean output for final simulations.