Chapter III: UCNA Simulations
3.3 The UCNA Apparatus in Simulation
3.3.4 Particle Tracking Classes
The remainder of this section on the GEANT4 simulation discusses the non-essential tracker classes. These classes allow the user different access points into the simula- tion in order to interrogate various physical parameters from the simulation. We use the initial kinematics set in section 3.3.3, propagate it through the detector geometry set in section 3.3.1, and subject it to physics processes set in section 3.3.2. In the subsequent sections, we start with the broadest level of particle tracking and move towards finer grain tracking towards the end. We note that in these various classes, there are potential redundancies where multiple classes may interrogate the simula- tion for the same physical quantity — we illustrate where our particular simulation chooses to output stored quantities.
(a)
(b)
Figure 3.2: (a) Comparison between new kinematics generation of UCNA𝛽-decay events (red) and the original𝛽-decay event kinematics used in the 2010 asymmetry analysis (blue). (b) The fractional residuals of the comparison of Monte Carlo generated kinematics spectra in (a). The error bars are statistical and propagated them forward with standard error propagation [HH10]. A constant line is fitted to the residuals (black) from 200 keV to 650 keV, consistent with the energy range used in the final Fierz extraction.
Figure 3.3: Simulated initial momentum direction distribution of 𝛽-decay electron events along the z-axis shown in raw counts (a total of 108 events were sampled).
This causes a modification to the initial decay kinematics generated in figure 3.2, with a PDG value of 𝐴
0=−0.1184 (as of 2015).
3.3.4.1 Run Action
At the coarsest level, the run action is a class that executes at the beginning and end of each simulation, after a fixed number of primary particles have been simulated.
In our GEANT4 implementation, we only use the run action for standard print-out and diagnostics, as well as tracking the number of events aborted. Some events need to be aborted in the simulation due to long transit times. For example, if the particle’s initial momentum is nearly perpendicular to the magnetic field, there would be an extremely long transit time that is not recorded in the actual electronics of the data-taking runs. Fewer than 1 in 105events were aborted either due to this phenomenon or any other effect that caused particles to be “trapped”.
In principle, the run action class is what controls parallelization in GEANT4. With some additional programming work, GEANT4 simulations can be parallelized and the run action oversees the distribution of batch programs to other computer cores.
Within the simulation software, run action would track the progress of each sub- program and aggregate the results afterwards. There was an attempt to utilize this
Figure 3.4: Two different initial 𝛽-decay electron energy spectra. The one cor- responding to 𝑏 = 0 represents the Standard Model kinematics and is shown as a standalone in figure 3.2. The remaining maximal𝑏is shown after running our initial kinematics generation and introducing a𝑏 coefficient of the form in equation 3.2.
Normalization is implicitly done by setting a fixed number of events generated (here we used 108total events).
automatic parallelization procedure in GEANT4. However, due to complications with file input/output, this path towards parallelization was ultimately abandoned.
Instead, we note that GEANT4 is easily batched by nature; since the simulation runs a set number of events one at a time, we could instead start multiple instances of simulations with a subset of events. In practice, we achieved a “manual paralleliza- tion” by running bash scripts that started N instances of simulations with 𝑁1 total events each, where N was the number of cores we wished to run on.
3.3.4.2 Event Action
The next-level of particle tracking is called the event action which executes at the beginning of each event. An event for our typical purposes was defined as an electron generated within the decay trap, traveling until it is stopped by materials in the UCNA apparatus (typically the plastic scintillator) or some maximum time has elapsed and the event is deemed “trapped” and hence aborted. Within the
event action, we are able to track many kinematic parameters that are useful on a per-event basis. In particular, in event action the initial kinematics of the particle can be stored and compared with the final deposited energies within the GEANT4 simulated geometry for a single event.
It is important to discuss that in GEANT4 particles travel through volumes and interact with materials and fields. Nominally, these interactions are not stored and hence after the particle step is resolved, these interactions are lost. The user may define in the code a series of “sensitive detectors” (SDs). These are volumes (or objects in the OOP sense) in the GEANT4 simulation that will record the various kinematics that pass through them and can be extracted at the completion of the event (or total run, if desired). In our event action, we register four volumes as SDs:
the East/West scintillators and East/West MWPCs. In event action, we define an output file that stores the initial event kinematics and final read out parameters of the GEANT4 simulation (described below). We also implement a clock to decide if an event is “trapped” and needs to be aborted.
At the end of an event, all the kinematic variables that are stored in the SDs are accessible and printed to an output file. In addition, some programming overhead are also printed to the file, as well as the initial event kinematics for comparison studies. Below is a list of the key parameters printed to file. When applicable, these are recorded for both the East and West scintillators and wirechambers.
1. Name of the SD volume 2. Energy [keV]
3. Quenched energy [keV]3
4. Time the particle entered the SD [ns]
5. Energy weighted by position in x, y, z [keV×cm]
6. Energy weighted by position squared in x, y, z [keV×cm2]
7. Angle the particle entered the SD from as measured by the surface normal [degrees]
3A discussion of the quenching factor is included in [Men14; Bro18]. Essentially, the light output of the plastic scintillator “quenches” at higher light yields and so a non-linear factor must be applied in order to properly account for the light yield as a function of energy deposited. In the GEANT4 simulation, this is done by adjusting the energy deposited with this additional quenching factor, described by “Birk’s law”. Both quantities are stored and outputted by the simulation.
8. Angle the particle exited the SD from as measured by the surface normal [degrees]
9. The incoming kinetic energy of the particle [keV]
10. The outgoing kinetic energy of the particle [keV]
3.3.4.3 Tracker
Within the GEANT4 simulation, the finest grain of resolution in the simulation comes from the TrackerHit class and the TrackerSD class. Within the simulation, each “track” is a fixed distance in the world volume that a particle travels. When a particle starts its track and ends it, the list of physical processes that can occur are sampled, in some order on the backend of the GEANT4 libraries, via Monte Carlo sampling. Then, when any physical processes that change the kinematics of the tracked particle occur, the kinematics are updated and the differences in energy and momenta are either lost or recorded in a sensitive detector located within the simulation. The TrackerHit class maintains a record of variables for each “track”
the particle travels through. The TrackerSD class records the kinematics that the particle loses within a particular SD volume.
In essence, the TrackerHit class stores different variables as class parameters (in the OOP sense) that are accessible while the particle traverses the geometry. These variables are listed below - we restrict ourselves to only the ones with physical relevance and interpretation, as well as some standard programming bookkeeping for future reference.
1. TrackID - a unique ID for this track.
2. Incident kinetic energy when particle enters into this track.
3. Energy deposited in this region (by definition, a SD).
4. Quenched energy deposited in this region.
5. Hit time - the time of entry of the particle into the volume.
6. Hit position - where the particle entered the volume.
7. Energy deposition weighted by position and position squared. These are relevant for calculating an energy reconstruction based on scintillator position.
8. Incident momentum - the momentum the particle had when entering the volume.
9. Exit momentum - the momentum the particle had when exiting the volume.
10. Particle species ID - a flag that indicated 𝛽-decay electrons as opposed to photons or other particles.
11. Process name - the name of the physics process which created this track. In certain physical processes, a cascade of tracks can be created and GEANT4 records each one and resolves those secondary particles automatically.
12. Volume name - the name of the volume where the track is located.
13. Creator volume name - the name of the volume where the track was created.
Within TrackerSD, a collection of tracker hits is created and stored for each SD. In the original asymmetry simulation, there were≈ 12 SDs for use in calibration and analysis. For the Fierz analysis, only four SDs were used: the East and West plastic scintillators and the East and West MWPCs. This was due to the simplified analysis requirements of the Fierz interference extraction and studying the UCNA detector response after one analysis had already been completed (publication [Men+13]).
After the hits collection is created, each tracker hit associated with a SD is stored within the hits collection. Then, once a particle is completed within a SD volume, a final function is called that accumulates all the kinematics from all the tracker hits within the SD. This, for example, sets the track ID, gets the particle ID, adds up all the energy deposited within the SD of this name, applies a quenching factor, and so on. The integrated kinematic parameters stored in the SDs are then accessible and printed out at the end of an event in the Event Action (discussed above in section 3.3.4.2).