GDCP: A custom package for flexible detector setups in Geant4

Geant4 Detector Construction Pattern (GDCP) is a C++ package containing a set of utility classes for developers to utilize during the detector construction phase of a Geant4 application. The main objective of this study is to provide an interface that helps users develop a highly flexible, understandable, and maintainable detector construction code. The package also contains a couple of helper classes facilitating the implementation of optical components in scintillation detectors. Finally, an advanced Geant application has been provided to demonstrate the package's utility. Program summary Program title: GDCP CPC Library link to program files: Licensing provisions: GNU General Public License 3 Programming language: C++ External routines/libraries: Geant4 Nature of problem: Geant4 provides an abstract class, G4VUserDetectorConstruction, that is used for the whole detector construction. This is sufficient for a simple detector setup but implementing a single class for building a complex detector leads to complexity in the code. To solve this issue it is recommended to split the implementation into more methods or classes; however, there is no standard solution published yet and it is entirely left to the users' ability. Solution method: To address this issue, I propose to apply the"Builder design pattern"in the detector construction phase. For this, the elements of the Builder design pattern have been introduced and made available for developers. Keywords: G4VUserDetectorConstruction, Builder design pattern, Detector construction, Component builder, Optical photon, Scintillator


Introduction
GEANT4 [1,2,3] is an object-oriented Monte Carlo simulation toolkit developed for simulating the passage of particles through matter. Although originally developed for nuclear and particle physics experiments, its application domain has spread to fields such as space science, accelerator, and medical physics. The toolkit is regularly updated, developed, and maintained by a worldwide collaboration of scientists. In recent years, it has become the most preferred detector simulation software in the high energy and nuclear physics communities.
The classes comprising the Geant4 software are categorized based on their logical content. Each category is designed as independently as possible. This allows each to be developed in parallel without serious interference. This work falls under the geometry and material category of Geant4 and proposes a new detector construction scheme for achieving more flexible detector setups. ponents, for instance, can be upgraded, replaced by other components, or totally removed from the system. More importantly, such change requests should be made by extending the code rather than breaking it, so that different versions of detectors become comparable. This necessitates a highly flexible detector production code.
In order to circumvent all these complications and have a clear implementation structure, this work proposes a component-based detector construction strategy for flexible detector setups. The strategy involves applying the "Builder design pattern", which is commonly used in object-oriented programming for creating complex objects step-by-step, to the detector construction phase. However, in the context of Geant4 geometry construction, I call it "Geant4 Detector Construction Pattern" 1 . The following section publicizes participants in this pattern and describes its implementation in detail.

Utility classes for geometry construction
The Builder design pattern is applied to the detector construction process in two stages. The first stage involves creating detector components as single or multiple parts, and the second involves assembling those components in a volume that represents the entire detector geometry. The following introduces elements of this pattern: • Abstract builder classes: VComponentBuilder and VMul-tiComponentBuilder. The first is used to build a single detector component, and the second is used to build a multiple detector component. These two classes declare product construction steps.
• User builder classes: These are the concrete classes to be derived by users. Two kinds of builder classes are derived, one for detector components and one for the detector itself. I further provide ready-to-use concrete component builder classes for the most commonly used shapes in Geant4: BoxComponentBuilder, TubsComponent-Builder and TrdComponentBuilder. When an object of one of these classes is created, a few user interface commands are defined automatically for the modification of the material and size of that component.
• Director class: DetectorDirector. This class defines the order in which to execute the building steps, while the detector builder class provides the implementation for those steps. The usage of this class is optional.
• Product class: SmartComponent. All builder classes produce the same type of product. A product is an object of type SmartComponent encapsulating G4LogicalVolume and G4VPhysicalVolume objects. So, depending on its content, it may represent a single detector component, a multi-component, or the detector itself. It also keeps a list of locations where it is positioned in the detector geometry. 1 This is also where the package gets its name. Fig. 1 summarizes in a UML [8] diagram the structure of the classes provided for applying the Builder design pattern to the detector construction process of a Geant4 application.
The following steps explain how to set up a complex detector in a highly flexible manner using the supplied classes: • Make a list of all the components to be employed in the detector construction.
• • Create a concrete material factory class as described in Sec. 2.3. If a material is employed just for one component, it can be defined simply within the CreateMaterial() method of the relevant builder class. If employed for more than one component, it can be defined either in a member method within the concrete material factory class or in a new material builder class created for that material.
In the second case, the object of the material is called from the CreateMaterial() method.
• After the above three steps are completed, proceed to the assembly phase of the components. For this, derive the detector builder class from VMultiComponentBuilder 2 and implement its construction steps. Listing 1 shows an example derivation of the detector builder class.
• The last step is the implementation of the Geant4 detector construction class. This class makes use of UserDetec-torBuilder and optionally DetectorDirector class for the construction of the detector. Listing 2 shows an example implementation of the detector construction class.
The advantages of using this pattern are summarized below: • It provides flexibility for change requests that may arise during the detector development process.
• It provides reusability of detector components. As detector components are treated as self-contained pieces, a component developed for a particular detector could be used in various detector constructions.
• It allows developers to create a messenger class per component.

Utility classes for scintillation detectors
This section concerns the construction of scintillation detectors. One of the crucial steps in the implementation process of scintillation detectors is to specify the optical properties of the materials employed and the optical surfaces defined. Geant4 provides G4MaterialPropertiesTable and G4OpticalSurface classes for this purpose. The former is used to assign new properties to pre-defined materials or surfaces, while the latter is used to describe optical properties of medium boundaries.
Optical properties are stored as entries in a G4MaterialPropertiesTable, and each entry consists of a key and a value pair. These properties may be energyindependent or energy-dependent. In the first case, the value is a constant, and in the second case, it is a list of energy-value pairs.
The usual approach is to put these energy-value pairs inside the detector construction file as elements of std::vector or C-style arrays. However, the presence of various datasets in a typical application and their direct embedding into the source file results in long lines of code and reduces code readability.
Moreover, the parameters defining the properties of materials and surfaces are frequently changed in studies where the effect of these parameters is investigated. This requires changing the source code repeatedly.
To overcome these challenges and perform the entire implementation process through user interface commands, I propose using two new classes. The first one is OpticalSurface class 3 , which is derived from G4OpticalSurface. The only functionality added to this subclass is that its implementation can be conducted by user interface commands. The second one is MaterialPropertiesHelper class, which is a subclass of G4MaterialPropertiesTable. This class provides additional methods to receive data from users. Fig. 2 summarizes, in a UML class diagram, the provided classes and their relationships with the Geant4 classes.
To illustrate, I take the code snippet shown in Listing 3 from the examples of Geant4 4 and compare it to the implementations of MaterialPropertiesHelper and OpticalSurface classes ( Listings 4 and 5), which fulfill the same task.

Utility classes for material construction
This section introduces two new abstract classes, VMateri-alBuilder and VMaterialFactory, that developers can utilize in the detector construction phase of a Geant4 application. The first offers an interface for developers to create custom material classes, while the second serves as interface for creating material objects from a single place in an application. Fig. 3 shows the UML class diagram of these two abstract classes.
To create a concrete material builder class, users inherit from VMaterialBuilder and implement its CreateMaterial() method. This class utilizes MaterialPropertiesHelper to assign additional properties to the materials to be defined. To get the resulting material object from the builder, the method GetProduct() is invoked. Listing 6 shows an example concrete implementation of VMaterialBuilder class.
To derive a concrete material factory class, users inherit from VMaterialFactory and implement its GetMaterial() method. This method is used to create objects of user-defined materials. However, it is not invoked directly by users to obtain a material object; instead, the FindOrCreateMaterial() method is invoked. This method first searches the desired material in GEANT4's material database. If the material is not found, it invokes the GetMaterial() to search among the user-defined materials. If it is not found there as well, it throws an exception. Listing 7 depicts an example usage of VMateri-alFactory class.
The benefits of these two classes can be summarized as: • Providing reusability of materials. Encapsulating a material construction code into a class makes it available to other developers. This is particularly significant for materials that are troublesome to implement. For example, to implement a scintillator, its atomic composition, scintillation character, and all-optical properties should be defined. This requires an extensive literature review followed by conversion of the collected data into the desired format. Once a scintillator is implemented by a developer, it can be used by others as well. VMaterialBuilder class acts as an interface for producing ready-to-use material classes.
• Improving code readability by encapsulating material construction code.
• Preventing code duplication by allowing users to access material objects from different sections of the code.

Structure of GDCP
The GDCP package is a collection of C++ classes developed for designing flexible detector setups in Geant4 applications. The provided classes are collected and organized in directories according to their dependencies and functionalities. The package consists of the following three directories: • gdcp/: This directory includes header and implementation files of GDCP.
• scntDetector/: This directory includes various utility classes for the implementation of scintillation detectors.
• g4Example/: This directory includes an advanced geant4 application that demonstrates the usage of the provided classes. The application also uses the NuSD framework [10] that we previously developed for modeling segmented scintillation detectors. The detector construction interface in this framework is updated using the GDCP in order to enhance the framework's flexibility and maintainability. The application includes the installation of PANDA [11,12] and SOLID [13,14,15] experiments as examples. uImanager -> A p p l y C o m m a n d ( " / control / execute path / to / macro / " + name + " . mac " ) ; // Implement your material definitio n here using the provided Geant4 classes . 17 // As an example , EJ200 s c i n t i l l a t o r is implemen t ed using data sheet provided by the m a n u f a c t u r e r .

Conclusions
In this study, a new custom package GDCP developed to create flexible detector installations in Geant4 applications is introduced. The classes in the package are grouped into three categories based on their roles and responsibilities. The first set of classes offers a detector construction interface based on independent detector components for flexible detector setups. This interface forces to apply the Builder design pattern to the detector construction phase in two steps: 1) for the construction of the detector components and 2) for the assembly of those components. For this, the elements of the Builder design pattern are introduced and made available for users.
The second set of classes provides an interface to obtain custom material classes. This is particularly significant for materials that implementation necessitates extensive data collection from the literature. Including a material construction code in a class allows other developers to easily use that material.
The third group of classes is related to scintillation detectors and makes a dual contribution to the implementation process of optical components. This both provides an easier interface for defining properties of optical materials and allows that interface to be implemented through the user interface commands.