Not linked MCParticles in MCCollector::TupleAlg
TL;DR
If the TrackID is not in GiGaKineRefTable, the linking between MCHits with the corresponding MCParticle is missing in generic hit extraction classes like MCCollector::HitsAlg. Accessing this information in other algorithms results in segmentation faults.
Description
The linking between MCHits and MCParticles is done via GiGaKineRefTable. This information is filled in hit extraction classes. Some extraction classes like MCCollector::HitsAlg can store information about any particle traversing through a sensitive volume. On the other hand, we do not store all the information generated by Geant4. This is controlled by the GaussPostTrackAction class. We cannot access the particle from the hit if the trackID is incorrect in the table. In cases like this, the MCCollector::TupleAlg will trigger a segmentation fault.
The purpose of this issue is to answer the following questions:
- In what cases do we expect particles not to be found via the
GiGaKineRefTable? Is this expected? If yes, should this information be taken into account when usingMCCollector? - Should the
MCCollectorgive warnings and proceed with the simulation instead of failing completely?
Minimum reproducible example
The first issue like this was reported by @dzuliani. Below you can find the options file and a log file.
minimum_reproducible_example.log
minimum_reproducible_example.py
In this case, the segmentation fault is caused by an attempt to access information about an optical photon. The properties of this optical photon are:
| Property | Value |
|---|---|
| Geant4 Name | opticalphoton |
| Momentum | 4.87746e-06 MeV |
| Hit X | 153.154 mm |
| Hit Y | 55.5436 mm |
| Hit Z | 11948.2 mm |
| Vertex X | 131.227 mm |
| Vertex Y | -7.92174 mm |
| Vertex Z | 9807.35 mm |