Actions

The user can specify how nexus behaves in a per Run / Event / Tracking / Stepping / Stacking basis, via configuration parameters.

These parameters must be set into the .init file, and in case anyone had associated parameters, they should be added in the .config file.

List of actions with their parameters

/nexus/RegisterRunAction

[DefaultRunAction] -> Just prints RUN start / end messages.

/nexus/RegisterEventAction

[DefaultEventAction] -> It prints the number of simulated events and it stores the events whose deposited energy is in a given range.

The way to set the energy limits is by adding in the .config file: /Actions/DefaultEventAction/min_energy 2.3 MeV /Actions/DefaultEventAction/max_energy 3.0 MeV

Notice that, when simulating events that don't deposit any energy (when simulating scintillation photons as primary particles for instance), this option won't store any event. In these cases, one should use the default event action provided by Geant4. This is achieved simply by not specifying any event action in the .init file.

[MuonsEventAction] -> Based on the Default action, and modified to generate control histograms related with muons generation.

/nexus/RegisterTrackingAction

To store particles in the output file is necessary to use one of the following tracking actions. [DefaultTrackingAction] -> It stores all the trajectories except those from optical photons and ionization electrons.

[OpticalTrackingAction] -> It stores all the trajectories, included those from optical photons and ionization electrons. They yield much bigger output files than DefaultTrackingAction option.

[ValidationTrackingAction] -> Based on the Default action, it saves a file with the binned energy of the gammas produced in the simulation. Its purpose is to compare these histograms across different versions of GEANT4.

/nexus/RegisterSteppingAction

[AnalysisSteppingAction] -> It prints the total number of photons detected by all kinds of photosensors at the end of the run.

[SaveAllSteppingAction] -> It stores all the steps information of the specified particles in the specified volumes. It yields huge output files.

The way to set the list of particles and volumes is by adding in the .config file: /Actions/SaveAllSteppingAction/select_particle e- /Actions/SaveAllSteppingAction/select_particle gamma /Actions/SaveAllSteppingAction/select_volume ACTIVE # full match /Actions/SaveAllSteppingAction/select_volume BUFFER # partial match

/nexus/RegisterStackingAction

[DefaultStackingAction] -> Not used at the moment.

Interplay among different actions

If you are using DefaultEventAction, because you want to save only events that deposit energy a given range, you need to use also DefaultTrackingAction, because the calculation of the energy deposition in the former is done using information which is stored in the latter.

Debugging

Optical photons' trajectories are not stored in the simulation when using DefaultTrackingAction, to avoid creating huge output files. If one wants to save them, OpticalTrackingAction should be used instead, only for small productions and debugging.

On the other hand, DefaultEventAction tries to access the trajectory container, to look for the hits associated with every particle and make a cut on the total deposited energy.

As a consequence, the combination of DefaultTrackingAction and DefaultEventAction produces a segmentation fault in simulations of optical photons as primary particles, since no other particles are present in the simulation.

For the same reason, using DefaultEventAction but not DefaultTrackingAction in standard simulations also causes a segmentation fault.