New DRC sensitive detector using RegEx

[SanghyunKo]

BEGINRELEASENOTES

• Update the DRC sensitive detector with the new Geant4RegexSensitivesConstruction to avoid large memory consumption.

ENDRELEASENOTES

This is a draft PR for the update on the DRC sensitive detector using the new Geant4RegexSensitivesConstruction introduced in DD4hep recently. By using this, we can avoid large memory consumption caused by the creation of SD objects for every fiber.

Note that this is not free, the cost of memory consumption is transferred to the overhead time for matching regex pattern. By trying appropriate pattern, we can suppress the overhead time caused by the Geant4RegexSensitivesConstruction down to a few minutes scale. However, this can easily explode up to an hour with complex patterns (so one needs to pay attention). The example steering file can be found in the DRCfastSDsteer.py.

Aside from the introduction of Geant4RegexSensitivesConstruction, the default behavior of SD is now modified to skip optical photon propagation for scintillation channels. For scintillation channels, we switched to the default Geant4Calorimeter::Hit (with Birks constant) and retrieve energy deposits from it. For Cherenkov channels, we check whether the optical photon has consecutive total internal reflection. If it has, then we count the photon and kill it to save CPU time. With these, the CPU consumption is now suppressed down to a few seconds per event.

The tricky part is retrieving cellID. Since each individual fiber is not a unique SD anymore, cellID now must be retrieved using the segmentation based on the volumeID of the mother tower. To do this, I assigned volumeID for each tower at the detector construction step, then navigate G4VTouchable object during the SD process. For this I strictly assumed world->detector->tower hierarchy (i.e. the tower volume should be depth 2), and this should be discussed with the capillary tube DRC colleagues.

There are still several outstanding action items (e.g., to validate cellID encoding, update CI), but I took liberty to push PR already to discuss whether people agree with this approach (conceptually).

@lopezzot @swkim95 @s6anloes

[BrieucF]

With these, the CPU consumption is now suppressed down to a few seconds per event.

:heart_eyes:

How long does it take to build the geometry now?

[SanghyunKo]

@BrieucF I didn't measure it precisely, but maybe around 10mins? (when I tested with the DRCfastSDsteer.py in lxplus9, with the full IDEA detector) But as I mentioned in the description, one really needs to be careful when matching regex pattern, because with bad/complicated patterns this can explode easily (performing regex matching O(10^6) time is a expensive operation)

[lopezzot]

Hi @SanghyunKo thank you very much for this example.

We will need to check how to use the volume hierarchy with the tubes geometry but I am pretty sure it is not hard to do. The optical photons treatment you just described is identical to what we are doing for Hidra simulation since a few years. Indeed I can confirm a few seconds per event (depending on energy and slightly on particle type).

Apart from this, I will study with @s6anloes this solution and get back to you.

[SanghyunKo]

since https://github.com/AIDASoft/DD4hep/pull/1308 is now merged, I'll update the steering file shortly once we have new nightlies