GODDeSS: a Geant4 extension for easy modelling of optical detector components

Scintillator- and fibre-based particle detectors with SiPM readout are an indispensable tool in high-energy particle physics, medical physics and other fields of application. For designing and understanding these detectors, very detailed simulations are necessary, which require an accurate modelling of the optical physics (optics, scintillation, wavelength-shifting effects, ... ), of the optical material properties, and of the geometry. To allow for a reliable usage also by less experienced users, the necessary complexity and flexibility of a suitable simulation framework must not lead to an increasing danger of user mistakes. Additionally, the required effort for creating or modifying a detailed simulation has to be minimised in order to allow for the fast creation of flexible simulation setups. These challenges have been addressed by developing GODDeSS (Geant4 Objects for Detailed Detectors with Scintillators and SiPMs). It is an extension of the particle-physics simulation tool Geant4 and allows for the easy simulation of optical detector components, especially combinations of scintillators, optical fibres, and photodetectors. GODDeSS enables the user to create extensive setups for Geant4 simulations with a few lines of source code. At the same time, GODDeSS helps to avoid typical user mistakes. This paper introduces the basic concepts of the GODDeSS framework, its object classes, and its functionality. Furthermore, test measurements with prototype modules will be presented, which were performed to validate simulation results of the GODDeSS framework.

. Simulated optical fibre in a scintillator tile (or optical glue volume): with its end faces parallel to the faces of the scintillator tile (left) and for being tilted against the tile (right). In the first case, the complete fibre can simply be assembled from a few parts (represented by the different colours) to avoid overlaps. Obviously, this is not possible in the second case.
1. Geometrical challenges within Geant4 that can make the creation or modification of complex geometric setups challenging and laborious. One of these is the fact that the positions and rotations for placing the volumes have to be specified relative to the mother volume.1 This can require complex calculations by the user, if the desired position and rotation are only known relative to another volume (e.g. if a silicon photomultiplier (SiPM) is to be positioned relative to an optical fibre).
Another geometrical challenge is the fact that no overlaps are allowed in the geometry. The rather simple example of a scintillator tile with a wavelength-shifting (WLS) fibre illustrates that this may be problematic. If the fibre protrudes from the tile on one or both ends, the fibre has to be assembled piece-wise by two or three cylinders, respectively, instead of one (cf. left part of figure 1). Furthermore, if the fibre is tilted with respect to the tile (cf. right part of figure 1), this simple solution is not possible any more. Instead, the fibre has to be cut into two or three parts via boolean operations in this case. If additionally the scintillator is to be be wrapped and the fibre has one or two claddings, setup is again more complicated. If the user furthermore wants to keep the geometric setup flexible, in order to be able to quickly change e.g. the fibre position or any other specification, this is not a trivial task and results in a significant effort, even before starting with the first simulation.
2. There are several peculiarities with respect to the optical physics in Geant4. They are presented in detail in [12] and [13], respectively. In short, the most important concerning the simulation of optical detector components are: • By default, the processing of the (mother) particle is postponed in Geant4 at the point of time when it creates new G4OpticalPhotons (e.g. via scintillation) [14]. This can lead to double counting and wrong data acquisition, due to the fact that it might appear to the user as if there are several independent trajectories (i.e. mother particles), which actually form the trajectory of the same particle when being combined.
• G4OpticalSurfaces can be defined in two ways: around one volume (G4LogicalSkin-Surface) or between two volumes (G4LogicalBorderSurface). These options can 1In Geant4 the "mother volume" is the volume which should contain the new volume.

JINST 12 P04026
also be combined for a single surface and compete against each other in this case. The effective G4OpticalSurface, which is responsible for the properties of a specific surface, depends on the combination of G4OpticalSurfaces. Therefore, it is e.g. a bad idea to use G4LogicalBorderSurfaces to define the optical properties of the surface between outer cladding of an optical fibre and its surroundings. If the fibre is positioned in such a way that it touches the outer surface of its mother volume (e.g. for fibres directly at the surface of a scintillator tile or optical glue volume), a surface is formed between the fibre and a volume different from the mother volume. This surface only possesses the desired properties, if a G4LogicalSkinSurface is used instead of a G4LogicalBorderSurface.
• The optical property variables can have different meanings, depending on the object they are referred to, e.g. refractive index (material property) vs. complex refractive index (surface property) and REFLECTIVITY variable vs. TRANSMITTANCE variable for direct specification of the reflectivity of G4OpticalSurfaces (cf. [12,13]). As a consequence, if not considering this, the user might end up simulating a totally different setup than desired and thus obtaining wrong results.
• SensitiveDetectors can be assigned to simulated volumes, to specify user-defined actions that are to be performed if a particle reaches the corresponding volume. In contrast to all other particles, SensitiveDetectors are not only activated by optical photons that enter the corresponding volume, but also by optical photons that are reflected at the surface of this volume.
• All optical properties have to be specified as a function of photon energy instead of wavelength.
• By default, the rise time variables of the scintillation process are deactivated and the WLS decay time spectrum is a δ-function rather than an exponential spectrum.
• The way to specify the Birks' constant (for considering saturation effects during the creation of scintillation light, cf. [15]) is different than the way to specify the other optical material properties.
These challenges for the simulation of optical detector components have not been addressed by any available Geant4 extension. Therefore, the simulation framework GODDeSS2 was developed. The aim was to address and solve the main challenges that limit Geant4's flexibility regarding the simulation of optical detector components and, thus, to minimise the required effort for creating or modifying a detailed simulation, to lower the Geant4 skill level that is necessary for creating or modifying such a simulation, and to reduce the danger of user mistakes. For this purpose, GODDeSS reduces the complexity of Geant4, automatically deals with the challenges of Geant4, and automatically ensures the correct usage of the optical processes and their variables. The following section introduces the basic concepts of the GODDeSS framework as well as its object classes.  Figure 2. Workflow of a Geant4 simulation using GODDeSS. The "Geant4 framework objects" (orange circles) are classes that are used to set up the Geant4 framework and to define the simulation parameters. All other objects belong to the GODDeSS package.

The GODDeSS framework
The GODDeSS framework is an extension of Geant4 (version 10.00.p02), which focusses on the simulation of optical detector components and adds new C++ object classes. It is publicly available [16], including the source code of a simple example simulation and the documentation. The example simulation demonstrates the basic application of GODDeSS and can also be used as a basis for a new user-specific simulation. Additionally, since the GODDeSS framework is C++/Geant4-based, it is of course also possible to adapt the source code of the GODDeSS object classes to the user's needs. Figure 2 illustrates how GODDeSS integrates into the Geant4 framework. The diagram shows that the user only has to create basic GODDeSS objects and to provide some parameters (e.g. the property files to be used), whereas the rest (e.g. processing the property files or creating the volumes and calculating their translation and rotation) is done automatically by GODDeSS. Starting from the main function of the simulation (which is used for setting up the Geant4 framework, e.g. defining the physics list and initialising the detector construction), the user only has to fulfil four additional tasks: 1. Implementing and initialising the necessary object constructor classes of GODDeSS.
2. Passing the previously defined physics list to the object constructor classes of GODDeSS, which will extend it if necessary.
-4 -3. Implementing and initialising the GODDeSS messenger and register the created object constructor classes of GODDeSS.
4. Passing the GODDeSS messenger to the detector construction.
Thereafter, the object constructor classes of GODDeSS can be used within the detector construction to create the corresponding GODDeSS objects. The rest is done automatically by GODDeSS, e.g. processing files containing the desired properties of the objects, creating and placing the objects (including the materials and surfaces), creating sensitive detectors, and obtaining and providing simulation data on event-per-event base. As a result of this high degree of automation, GODDeSS can easily be implemented into an existing Geant4 simulation. Of course, the user can always modify the GODDeSS code and change the actions that are taken internally, if necessary. GODDeSS allows for a simple and fast creation or modification of complex optical detector setups, including their geometry and material properties. Thus, particularly less experienced users, can quickly perform detailed Geant4 simulations of optical detector components. The main features are: • New object classes that allow for an easy creation of scintillator tiles, optical fibres, wrappings and paints, and photodetectors. These object classes take care of the correct usage of Geant4's optical property variables. Additionally, they solve potential geometrical problems and provide an easier and more intuitive way of positioning objects.
• All material properties of the optical detector components are specified via human readable text files. An example of such a property file can be found in [13]. This approach makes it easy to define the various properties without the need to change the Geant4 source code. Consequently, it also allows for the modification of properties without recompiling the simulation source code and thus easy batch processing.
• The object classes feature the automatic registration of the physics processes they need. This is done by extending the user-defined PhysicsList, if necessary. Thus, to a certain extent, the user does not have to pay attention to the registration of the physics processes. If necessary, the physics that is used by the GODDeSS objects can be adapted by the user.
• The object classes follow an object-oriented design. Therefore, it is possible to include GODDeSS into existing detector simulations. Besides that, the simple example simulation, which is included in the public GODDeSS package, can serve as a basis for a new simulation.
• The internal data storage takes care of the bookkeeping of particle tracks, preventing multiplecounting of particles that created optical photons.
• The internal management of the GODDeSS framework is designed for as much automation as possible. Thus, the user only has to deal with few upper-level-classes.
The parts that GODDeSS consists of will be described in detail below.

Object classes
Scintillator tile (G4ScintillatorTile). A G4ScintillatorTile can be constructed by specifying its geometric dimensions,3 its material property file, and a reference to the mother volume. In the case of scintillators, a property file contains the scintillator's material properties (chemical composition, refractive index spectrum, absorption spectrum), surface properties (roughness, impact of the different reflection models), and scintillation properties (light yield, emission spectrum, rise and decay time). The G4ScintillatorTile can be placed by specifying its position and orientation relative to any volume. This reference volume does not necessarily have to be the mother volume, but can e.g. be another G4ScintillatorTile, belonging to the setup. Additionally, a parametrised placement is possible, i.e. a certain number of G4ScintillatorTiles with the same properties are positioned with a specified translation and rotation between two consecutive tiles. A graphical illustration of a G4ScintillatorTile with an optical fibre can be found in the left part of figure 3. If desired, a sensitive detector is created automatically for each tile. By default, it collects the data of each primary particle entering the specific G4ScintillatorTile, as well as the (ionising) energy deposition of each particle within the tile. The data is stored in a data storage class and can be obtained for analysis purpose after each event.
All physics processes, which are required for a correct simulation of the tiles, are registered to Geant4 automatically.
Optical fibre (G4Fibre). G4Fibres are also constructed by providing material properties and a reference to the mother volume, similar to G4ScintillatorTiles. The material property file contains the fibre's material properties (chemical composition, refractive index spectrum, absorption spectrum), profile and edge length or radius, and the number and respective thickness of claddings. Additionally, the corresponding emission spectrum and decay time constant have to be included for WLS fibres, whereas for scintillating fibres the scintillation properties have to be defined. If  . An optical fibre protruding from the edge of a scintillator tile, which is its mother volume. This requires a complex separation of the fibre into parts inside (light-blue) and outside (dark-blue) the scintillator tile. Due to the orientation of the fibre with respect to the tile, dividing the fibre is not possible in a trivial way, e.g. by assembling it from two cylinders instead of one (left, cf. figure 1). When using GODDeSS, the fibre is automatically separated at the edges of the tile (right). desired, also the properties of an absorbing or reflecting coating can be specified, which is placed around the fibre like an additional, opaque cladding.
The G4Fibre can be placed by specifying its length, position and orientation or by providing a starting and an end point. In both cases, the values can be specified relative to any reference volume. Like for G4ScintillatorTiles, parametrised placement is possible. Additionally, round or square fibres, straight or bent fibres, and cut (i.e. perfectly plane), mirrored, or roughened fibre ends can be chosen and the fibre can be wrapped with an absorbing or reflecting coating with modifiable gap in between. Figure 3 illustrates a rather complex fibre setup within a scintillator tile (left) and the profile of a simulated round multi-cladding-fibre (right).
Furthermore, a sensitive detector can record the particles reaching the G4Fibre. This detector can be extended to record more information.
The PhysicsList that is registered to Geant4 is extended by the optical physics processes, if required.
In comparison to other optical detector components, the simulation of optical fibres often poses an extraordinary challenge: optical fibres are likely to protrude from their mother volume, e.g. if they are combined with scintillators (cf. figures 3). This might result in geometrical problems, i.e. overlaps (cf. section 1), and makes the handling of optical fibres challenging, when using the basic Geant4 classes. Depending on how complicated the fibre setup is (e.g. a fibre protruding from a scintillator tile in one of its edges), dividing the optical fibre is not trivial. As a major improvement of the GOD-DeSS extension of Geant4, the user does not have to pay attention to this any more. The G4Fibres are automatically divided into single pieces and distributed to the different mother volumes. This is illustrated in figure 4. More precisely, G4Fibres are only distributed to their mother volume, their "grandmother" volume (the mother volume of their mother volume), and their "aunt" volumes (all volumes having the "grandmother" volume as mother volume). This restriction is due to the fact that it is not possible in Geant4 to obtain the translation and rotation between two arbitrary volumes.  G4PhotonDetector object class, which can be understood as a pseudo-photodetector, as it detects photons with 100 % efficiency and does not suffer from any noise or saturation effects. Therefore, it can be used to determine the number and properties of the optical photons, reaching a photon detection device in a simulated setup. This is very useful when comparing different setups, e.g. in order to optimise the detector design for maximum signals or for fast signals. Of course, the results cannot be compared to measured data directly. If this is needed, a more sophisticated photodetector has to be simulated, e.g. like the SiPM described in the next paragraph. The structure of the G4PhotonDetector is illustrated in figure 5.
A G4PhotonDetector can be constructed by specifying its edge length and mother volume. It can be placed via its position and viewing direction relative to any volume (e.g. a scintillator tile or optical fibre).
For every G4PhotonDetector that is constructed, a sensitive detector is created automatically. It collects the data of each optical photon hitting the sensitive area of a G4PhotonDetector, saves the data to the data storage class, and "kills" the optical photons. Afterwards, the data can be passed to a dedicated simulation, to study or optimise the photon detection itself. For example, different types of photodetectors or SiPM models with different cell configurations can be simulated (cf. next paragraph) and exposed to the photons recorded by a G4PhotonDetector, in order to choose a suitable photodetector for the previously simulated detector geometry.

Silicon photomultiplier (G4SiPM).
A detailed SiPM simulation can be performed with the external G4SiPM software package [17,18]. It allows for the realistic simulation of the SiPM's behaviour concerning geometry and housing as well as temperature and over-voltage dependency (photon detection efficiency (PDE), thermal and correlated noise, recovery time). This is illustrated in figure 5. As a result, the user can either obtain a list of cell triggers for further processing in his own electronics simulation or a voltage trace similarly to an oscilloscope reading for further analysis. The properties of the SiPM can be provided by a text file. Wrapping (G4Wrapping). The G4Wrapping can be applied to a G4ScintillatorTile. To construct a wrapping volume, its property file and a reference to the corresponding G4ScintillatorTile have to be specified. A wrapping property file contains the number and thickness of wrapping layers, their material properties (chemical composition, refractive index spectrum, absorption spectrum) and surface properties (roughness, impact of different reflection models), as well as the thickness of a potential air gap. If a G4ScintillatorTile is to be wrapped, the wrapping layers are automatically placed around it. All other volumes, which have been created at this stage and are overlapping with the wrapping, are automatically cut out of the wrapping volume(s). This is illustrated for a wrapped scintillator tile with a photodetector in figure 6.
If desired, a sensitive detector is created, by default saving the data of traversing primary particles.
Other object classes of GODDeSS. There are several other object classes of GODDeSS that do not represent parts of a detector: • GODDeSS messenger: this class is used internally to handle classes and settings and to allow for user access to the GODDeSS framework.
• Property tools: a class for parsing the properties files.
• Data storage class: the purpose of this class is to internally save the data recorded by the sensitive detectors. The data is sorted according to the TrackID of the G4Tracks, which is unique to each particle of a G4Event. Thus, this class also deals with the fact that the particle trajectories may appear to consist of several G4Tracks instead of only one (danger of double -9 -counting and wrong data acquisition, cf. section 1). The data can be retrieved by the user after each event.
• General particle source: the user is free to choose the particle type, the position and dimensions of the source, as well as the direction and energy distribution of the particles. This input can also be supplied by a text file.
• Photon source: this source "re-plays" the photons recorded beforehand by a G4Photon-Detector, e.g. to study diverse photodetectors and optical couplings.

Validation against measurements with prototype modules
In order to validate the performance of the GODDeSS framework with respect to the results of simulations of complete optical detectors consisting of several optical detector elements, hodoscope measurements were performed. The hodoscope consists of two trigger detectors, which are horizontal scintillator tiles with photomultiplier tube readout, as well as of four silicon strip detectors, each two of them combined perpendicularly to a detector layer of the hodoscope. The former allow for triggering on traversing cosmic muons, the latter allow for the reconstruction of the particle trajectory by determining two of its points. Detailed information on the setup and on the working principle of the hodoscope can be found in [19] and the references therein. Using the hodoscope, measurements of the response of scintillator-based detector prototype modules as a function of the particle incidence position were performed. These measurements have then been compared to the results of simulations of the corresponding modules with GODDeSS. The material properties, which have been used for modelling the optical detector components in the simulations, can be found in [13]. Additionally, further consistency checks and validation efforts are described there.

Experimental procedure
The modules, which have been used in the measurements, are presented in figure 7. Detailed information on their setup can be found in [19] and [20]. Module F4 consists of a 100×100×3 mm 3 scintillator tile (BC-404) with Teflon wrapping. The scintillation light is collected with straight WLS fibres (BCF-92, round, 1 mm diameter, double-clad) at two opposite lateral surfaces of the scintillator tile and guided to 1×1 mm 2 -SiPMs (Hamamatsu S10362-11-100C) at one end of each fibre. The other fibre ends, which are not connected to an SiPM, are mirrored with aluminium paint. The fibres are optically coupled to the scintillating material and to the SiPMs with optical cement (BC-630) and have a total length of 230 mm. In contrast, module D4 consists of a 100×100×5 mm 3 scintillator tile (BC-404) with Teflon wrapping. It is read out directly via two 3×3 mm 2 -SiPMs (Hamamatsu S10362-33-100C), which are centred on one of the lateral surfaces with a distance of 4 cm between each other and optically coupled to the scintillating material with silicone rubber pads (made out of RT 604, cf. [20]).
The sensitive area of the hodoscope is 80 mm×90 mm and thus smaller than the scintillator tile within the used prototype modules (100 mm×100 mm). Therefore, four measurements of each 4"F" stands for fibre readout, "D" indicates direct readout.
-10 - In the simulations, the mirroring of the WLS fibres was realised by applying a reflectivity of 90 % to the respective fibre ends and the wrapping was simulated with an air gap between scintillator and wrapping material. 100,000 minimum-ionising muons (with a βγ of 3.5) were shot perpendicularly and homogeneously distributed onto the top surfaces of the prototype modules. For each muon, the incidence position on the scintillator tile as well as the optical photons that reached the G4PhotonDetectors were recorded.

Analysis and comparison
Adding up the individual measurements, 800,000 cosmic muon events were recorded for each prototype module. In order to guarantee a high purity of the events contributing to the final results, the criteria of containing an unambiguously reconstructible muon trajectory, i.e. exactly one hit in each of the four silicon strip modules, was applied. As a result, about 70,000 of the recorded events fulfilled the requested criteria. Figure 8 illustrates the combined measurement results for one of the two SiPMs of module D. The limited PDE of the SiPMs for large incidence angles, which can be observed in figure 8, is a result of the overall reflection at the multiple optical surfaces between the scintillator material, the optical coupling, the window of the SiPM and its silicon substrate [21].
Whereas the signal of the prototype modules was measured in units of the total charge of the fired cells of the SiPMs in a certain time window, the simulations return the signal in units of photons. Thus, a relative comparison of measurement and simulation was performed. For this purpose, the absolute distributions that were obtained from the measurements and simulations have to be transformed into relative distributions by normalising them. Suitable bin-regions were defined as a basis for the normalisation and their average bin entry was used as value to normalise the distributions to. These bin-regions were chosen in a way to avoid extreme cases. This means that no bins from the edge of the scintillator tile were chosen as well as no bins close to the SiPMs or fibres were used. In the following plots, the chosen bin-regions are always marked by a black rectangle. The results of the normalisation are exemplarily presented in figure 9.
For comparing the results of measurement and simulation, the relative distribution of the measurement results was subtracted from the relative distribution of the corresponding simulation. Thus, a space-resolved distribution of the relative deviation between measurement and simulation is obtained. This means, bins significantly differing from zero represent deviations between the relative results of measurement and simulation. Positive deviations represent too large signals in the      simulation (with respect to the reference bin-region), negative deviations stand for too low signals in the simulation. The left plot of figure 10 presents the result for one SiPM5 of module D.
The agreement is good in the reference bin-region but there are significant deviations in triangular regions left and right of the SiPM (marked by white dashed lines) and in the bins next to the SiPM position, especially the two bins directly in front. The reason for these significant deviations is the usage of the G4PhotonDetector in the simulation of the prototype module. As described in section 2.1, the G4PhotonDetector detects every photon that reaches its sensitive surface. This especially means that neither the geometry of the SiPM (fill factor, window6) and its 5The results for the second SiPM are qualitatively mirror-symmetric to the presented results. 6The optical surface between the scintillator material and the window of the SiPM and the resulting total reflection for large incidence angles causes the triangular structures in the deviation distributions.    PDE are considered, nor the effects of pulse form, gate length, noise, saturation (in case of multiple photons hitting the same cell), and optical coupling of the SiPM. Additionally, high signals during the measurements reach the saturation of the pre-amplifier in the readout electronics of module D. This is especially the case for events next to the SiPM, as they tend to cause the highest signals.
- 14 -In order to verify the impact of these factors, the geometry and the PDE of the SiPM as well as the saturation effects of the SiPM and the pre-amplifier were taken into account in another simulation step by using G4SiPM and by applying a maximum value to the signal height, respectively. The results are presented in figure 11. The simulation of module D shows a very good agreement with the measurements. Considering additional effects like the pulse form of the SiPM, the gate length during the measurement, noise effects of the SiPM, and especially the correct optical coupling of the SiPM to the scintillator, which would all be possible with GODDeSS and G4SiPM, material might result in even better results.
A thing that can be noticed in all space-resolved deviation distributions is that there seems to be a tendency to higher (positive) deviations at the edges and especially in the corners of the scintillator tile. This means that the simulation tends to result in higher (relative) signals for particle transitions at the edges and in the corners than the measurement does. A reason for this effect might be the fact that the probability of photons to undergo total reflection at the surface of the scintillator is lower for photons created in the edges than for photons created far off the edges.7 As a consequence, the influence of differences between the simulated and the real wrapping is higher in the edges. Another possible reason might be a not perfectly uniform wrapping, especially at the edges of the real scintillator tile.
The same analysis procedure as described above for module D, was also applied to the results of module F (besides the pre-amplifier saturation, which did not occur in case of module F, because of a different applied gain). Figure 12 illustrates the resulting distributions. It can clearly be seen that there is a large deviation next to the fibre, which decreases with increasing distance to the fibre. This means that the simulation results in a less steep (relative) increase of the mean signal height towards the fibre position than the measurement does. This could possibly indicate a lower (overall) reflectivity of the wrapping in the measurements than assumed in the simulation: neglecting absorption, every photon would reach one of the fibres after some time in a perfect module without any light losses. A decreasing reflectivity would lead to increasing light losses and thus the probability of the photons to reach the fibre decreases. The influence of this effect depends on the distance (path length) the photons have to cover before reaching a fibre. Thus, signals from muons that traverse the scintillator tile at a larger distance are more effectively suppressed by a lower reflectivity.
To check the assumption of a deviating reflectivity, the simulation was repeated for a reduced reflectivity value of 90 % (instead of 99 %) and analysed with the same procedure as the original simulation. The results are summarised in figure 13. They show a much better agreement between the simulation and the measurement. Reasons for the low effective reflectivity could be an inhomogeneous or damaged wrapping of the prototype module.8 In contrast, a reduction of the simulated reflectivity of module D does not improve the agreement between simulation and measurement but leads to increasing deviations (cf. figure 14).
Apart from these minor deviations, which illustrate the general challenge of accurately defining optical properties for detailed simulations, the comparison between measurement and simulation demonstrates that the GODDeSS framework works properly and allows for correctly simulating 7For photons created in the edges, the probability to hit a surface of the scintillator with a small incidence angle is higher (just because there are additional surfaces next to the initial position of the photons).
8It was already demonstrated before that the signal height of the prototype modules could significantly change when re-wrapping them [20]. not only single optical components but also complete optical detectors consisting of several optical detector elements.

Summary
For several reasons, the detailed simulation of typical optical detector components with Geant4 is not trivial. To allow for a reliable usage also by less experienced users, the necessary complexity and flexibility of a suitable simulation framework must not lead to an increasing danger of user mistakes. Additionally, the required effort for creating or modifying a detailed simulation has to be minimised in order to allow for the fast creation of flexible simulation setups.
These challenges have been addressed by developing the general simulation framework GOD-DeSS. It is an extension of Geant4 and allows for the easy simulation of optical detector components, especially combinations of scintillators, optical fibres, and photodetectors. To achieve this, the creation of simulated setups is automated as much as possible: the material properties of the optical detector components are specified via human-readable text files and new object classes allow for an easy creation of scintillator tiles, optical fibres, reflective wrappings and paints, and photodetectors with basically a single line of code per created object. Thus, the user can create extensive setups with a few lines of C++ code and typical mistakes are avoided, as the peculiarities of Geant4 regarding the configuration of the optical physics processes are treated automatically by GODDeSS. All this makes GODDeSS an excellent framework to simplify the detailed simulations of optical detector components, which are necessary for designing modern particle detectors and for understanding their response.

JINST 12 P04026
The functionality and the object classes of GODDeSS have been introduced in this paper. Additionally, the comparison between measurements and simulations with GODDeSS were presented, as an example of the performed validation efforts. A more extensive discussion of peculiarities in the usage of Geant4 (especially with respect to the simulation of optical physics), the GODDeSS framework, its consistency checks and validation efforts, as well as detailed simulation studies performed with GODDeSS can be found in [12] and [13], respectively.