The Developed Software Framework

A software framework was developed during this project for the management, process-ing, reconstruction, analysis and presentation of data from the beam test and from the MC simulations. It is of a modular design and it is object-oriented, such that it should be simple to extend the software with the following purposes in mind: to enable analysis of data from multiple sources such as the next-generation readout electronics and different

4.2 The Developed Software Framework 67 MC simulation software tools; to give the user a broad selection of different geometrical, physical and reconstruction models; to include a more extensive proton CT simulation with complex phantoms and positional trackers before and after the phantom or patient;

and to facilitate further development and usage of the software by making it available as a analysis library.

The software framework is called the Digital Tracking Calorimeter Toolkit, and it is available for download at GitHub (Pettersen, 2015). The software is written inC++

and ROOT, with some auxiliary tools written inPythonand user scripts written inbash. Several hands-on teaching workshops have been held at the University of Bergen in order to demonstrate the usage of the software, and summaries of these are available at the GitHub project page. In total the framework, including tools consists of approximately 20 000 lines of code.

Some of the functionality in the code was already available in the existing ALICE-FoCal prototype framework designed by Reicher (2016). However, due to the differences between the data analysis requirements for electromagnetic showers and curved-path proton tracking, between the MC simulations and the desired output, and due to the fact that it is simpler to write code from scratch than to modify large parts of existing code, this framework was developed. In addition, the process was very helpful in developing appropriate analysis tools.

4.2.1 Overview over the Software Framework

The design of the software framework reflects the geometry of the detector, the structure of the data readout as well as the different parts of the analysis workflow, as shown in Fig. 4.3. The estimation of the proton path through the patient or phantom (the so-called Most Likely Path, or MLP) has not yet been implemented in the project as all the available experimental results were acquired without imaging phantoms. The so-called “simplified analysis” is a shortcut for validating the results by applying the MC generated proton identification tags for perfect track reconstruction, and is used extensively in Chapter 5.

As an overview of the framework structure, the most used classes and their functionality are listed below:

• TheDataInterfaceclass: The interface to the beam test data in the data format specified in Section 3.2.2 as well as to the output ROOT files generated by the GATE software. Returns the data either asHitobjects or as histograms representing the sensor layers.

• The Layer andCalorimeterFrame are collections of histograms of hitmap data

68 4. Benchmarking the Digital Tracking Calorimeter Prototype

Figure 4.3:The analysis chain in the software framework. The estimation of the proton path through the patient or phantom (the so-called Most Likely Path, or MLP), has not yet been implemented in the project.

from a single layer and the complete calorimeter, respectively. A method is imple-mented to find all activated pixels in the histogram, returningHitobjects.

• TheHitclass: An object representing a hit, a single activated pixel. The object includes the 3-dimensional position and (if originating from MC) the ID and the energy deposited by the activating proton. The available class methods are so-called “getters” and “setters” such asHit::getX()andHit::setEventID(int). A container classHitsis available with organizational and optimization features, and methods to implement the hit clustering algorithm described in Section 4.3.7.

• TheClusterclass: While theHit object is a single activated pixel, theCluster object represents a spatially connected group (called a cluster) of activated pix-els. In addition to the spatial (positional) information of the center-of-gravity of all connectedHitobjects, its member variables also include information about the numberof pixels representing the cluster. The charge diffusion model, as described

4.2 The Developed Software Framework 69 in Section 4.3, is implemented in theClusterclass. A container class for multiple Clusterobjects is available, it is called theClustersclass. Various track recon-struction algorithms have been implemented in theClustersclass.

• TheTrackclass: AllClusterobjects from a single physical (or simulated) proton track are collected in a singleTrackobject. It is here that the many track analyses are implemented: The estimation of track properties such as scattering angles and interaction types (slowing-down or inelastic collision), the implementation of the Bragg curve model fit from Section 4.6.2 to calculate the residual range and thus the initial energy of the track and extraction of the initial vectors of the track.

• TheTracksclass implements some optimizations which need such as removal of un-physical paths, tracks ending in known dead areas of a chip, tracks leaving the detector laterally and resolving colliding tracks (λ-shaped track segments).

By using the classes listed above, it is possible to write relatively compact user func-tions to perform all parts of the analysis. Tools that automate the track reconstruction have been developed, and different parts of the analysis are fully customizable using the Constants.hconfiguration file.

The automation tools enable a multi-threaded version of the code, working on sep-arate data sets, through simultaneous execution of the program while altering both the program input and output. The automation tools are provided asbashscript files.

See Appendix C for the different program files described together with their main functions. See Appendix D for examples of code, how to read the data files and how some of the algorithms are implemented.

4.2.2 The Modularity of the Framework

The framework is built as a class library in order to simplify the usage of and increase the readability of the analysis code. By using the inherent functionality of the ROOT framework, the most common objects have a rich I/O functionality. As an example, after the track reconstruction procedure, theTracksobject is automatically saved to disk, and the user may choose to load this file next time instead of performing the same track reconstruction multiple times. This is especially useful then analyzing a set of multiple tracks many times with small perturbations to the analysis technique.

Most of the implemented algorithms were originally developed for this project. As a result of this, there may be more than one applicable approach. In Section 4.3, multiple models for performing the charge diffusion are presented. Likewise, there are different ways to perform the track reconstruction described in Section 4.4.1. In the configuration

70 4. Benchmarking the Digital Tracking Calorimeter Prototype

Figure 4.4:The Python GUI for the creation of different DTC geometries. Based on the applied settings, a GATE.macmacro file is generated for the simulation of the defined ge-ometry. The program code is available in the GitHub repository for the software frame-work (Pettersen, 2015).

file Constants.h the user is given the possibility of choosing between all the differ-ent implemdiffer-ented models. Differdiffer-ent geometries are also available, such as the Forward Calorimeter and the many different optimized geometries presented in Chapter 5.

4.2.3 Software Tools

Some of the auxiliary software tools developed for this project are described in this sec-tion:

Automatic Geometry Creation

A time-consuming task in GATE (and any MC program) is the definition of the geom-etry files. Small changes to e.g. the energy absorber thickness must be propagated to the other modules in the geometry, since they are sequentially defined in the same co-ordinate system. To that end, aPythonprogram has been developed to automatically generate geometry files for the DTC. This is based on simple input variables such as en-ergy absorber material and thickness, the number of layers and the thicknesses of other modules. A usage example of the program is shown in Fig. 4.4.

Energy Loss Calculations

One important calculation routinely performed is that of the proton’s energy loss in dif-ferent media. This calculation is used for finding the energy loss from components in

4.2 The Developed Software Framework 71

Figure 4.5:Time requirements of the full MC processing including data retrieval, track reconstruction, track fitting and visualization. The time requirements for two different MC simulations are shown, both simulations are applying the 3.5 mm aluminum absorber geometry from Chapter 5.

front of the detector, such as the scintillators or the initial energy absorber, or inside the sensor chips. These energy loss values are later used to correct the initial energy estimate of the individual tracks.

An accurate calculation of the energy loss requires full knowledge of all parameters that enters into the Bethe equation, Eq. (1.1), and then by performing a numerical inte-gration. Alternatively, energy dependent stopping power values for a range of different media may be acquired from the PSTAR database (Berger et al., 2005).

APythonprogram was written for the simplification of this process: Look-up-tables (LUTs) of the energy loss values of different materials from PSTAR are loaded into the memory, and 3^rd degree polynomial splines are made in order to perform accurate in-terpolations between the data values. In the program, the user defines the geometry and materials, and the range or energy loss is then calculated by numerically integrating the LUT values. The program is available on GitHub (Pettersen, 2017a).

4.2.4 Computational Efficiency

The software framework has been developed during the project to accommodate the re-quirements of the analysis workflow. Efforts have been made regarding the computa-tional efficiency of the code. A typical track reconstruction task with MC data in an optimized geometry as will be described in Chapter 5 consists of a 160 MeV beam

in-72 4. Benchmarking the Digital Tracking Calorimeter Prototype teracting with 22 sensor layers before stopping. The time required for the concurrent analysis of 200 protons is about 0.7 seconds. Of these, 0.6 seconds are spent on the track reconstruction and the rest on visualization, data retrieval and analysis. See Fig. 4.5 for the dependency of the number of protons in the analysis on the reconstruction time. The numbers are found on a Xeon E5520 CPU at 2.27 GHz, utilizing a single core for the task.

The reconstruction task can be executed in parallel on several CPU cores, decreasing the required time spent on the analysis.