LDMX-Software
Add TS SiPMs as G4 volumes
Is your feature request related to a problem? Please describe. As a step leading up to radiation studies for the TS, we should add SiPMs as volumes. The idea is that we can export Geant4 geometries to FLUKA for these studies.
Describe the solution you'd like
Add a piece of silicon corresponding to a 2x3 (? dimensions TBC) SiPM at the far end of each light pipe. If we make them Sensitive Detectors, we could even study what hits them already in ldmx-sw (especially check for neutrons).
Describe alternatives you've considered N/A
Additional context Add any other context or screenshots about the feature request here.
SiPM specs: https://drive.google.com/file/d/1brglsz5YRwCForbn9zg2p67zKofDmSiW/view
I've been working on a solution for improving the implementation of the current TSPads as well as including the light pipes and the SiPMs as sensitive volumes for v15.
The current implementation has three loops in two files to define the individual TSPads (two in trig_scint.gdml and one in target.gdml). Due to this, any time we want to make changes to the TSPads, we have to do it in three places. By adding the light pipes and SiPMs, this would result in 9 components which may need to be updated with new positioning etc.
I attempted to modularize the TSPad structure by placing it in a separate file and then importing the entire structure as a GDML assembly, similar to the ecal motherboards. However unlike the ecal motherboards, we also want the TSPads to be sensitive detectors, and the TSPads are hardcoded to be logically distinct (we have 3 collections for 3 volumes). As far as I know, there's no way to modify the internal components of a GDML assembly after importing it, and so there's no way to make the TSPad components logically distinct when using the same assembly multiple times.
The current solution is to add a python script, makeassemblyfiles.py, to the v15 geometry directory, and to modify CMakeLists.txt in the Detectors directory to call this script prior to generating build files. This script contains some of the parameters for the TSPads, including the scintillating bars, the light pipes, and the SiPMs. The other parameters, such as those used for positioning, are still defined elsewhere, such as constants.gdml. Upon execution, this script automatically generates 3 assembly files, with logically distinct internal components. These are named tspadN_assembly.gdml, where N is a number from 1 to 3.
As for making the light pipes and the SiPMs sensitive detectors: I've modified sensitive_detectors.py and simulator.py in Simcore to include these as TrigScintSDs. There's a set of three SDs for the light pipes attached to each pad, as well as a set of three for the SiPMs on the end of each light pipe, resulting in 6 new SimHits collections. I did not add these components to the digitization/cluster/track producing chains, or give them ScoringPlaneSD classes, because they aren't truly active components (well the SiPMs are, but you know what I mean) and so I think the SimHits data will be sufficient for any studies we want to do about accidental activation of these components. I considered making it possible to toggle these collections independently from the collections for the scintillating bars, but doing so would mean defining two new classes of SDs.
At present, I have a branch of ldmx-sw with these modifications, and it's able to simulate the full tracking sequence seemingly without issues. I think this is ready for unit testing. More documentation on the specifics can be found in comments within the new script and within the other modified files. Also, injecting python scripts into the pre-init phase of the compiler could be something with more uses - just a thought.
I would welcome any comments or suggestions before I continue any further with this. Thanks in advance!
i think this solution sounds good (and it solves the longstanding nuisance of three-fold repetition of the TS geometry). i agree we don't need separate SDs for the SiPMs and lightpipes: as long as we get distinct output collections, we can always choose to drop those SimHits in all cases where we don't study the radiation hitting those components (much like the MagnetScoringPlaneHits are almost always dropped).
@cjbarton151 can you push to your branch and make a PR so we can see the implementation in code?