Closed rahmans1 closed 1 month ago
I think there is a desire to move forward on tracking here, where the implementation is essentially complete thanks to one-to-one associations and relations, but I fear that if we add calorimeter hit associations and relations to the scope of this PR it will be slowed down. In particular, the CalorimeterHitDigi does pre-digitization merging of SimCalorimeterHits, so the associations are going to be requiring some non-trivial code.
So, I suggest we keep this PR for tracker (and photomultiplier) hits only, and create a similar PR for calorimeters that may need more non-trivial code.
So, I suggest we keep this PR for tracker (and photomultiplier) hits only, and create a similar PR for calorimeters that may need more non-trivial code.
In particular, we want more than just the leading hit in
https://github.com/eic/EICrecon/blob/ec93c7427137ad78e80bb6de1a33616874de7b18/src/algorithms/calorimetry/CalorimeterHitDigi.cc#L190-L194
and that then requires that we decide on a weight strategy (hit.getEnergy() / edep
probably).
Issues
0 New issues
0 Accepted issues
Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code
Briefly, what does this PR introduce?
Add one-to-one relation with raw tracker/calorimeter hit for reconstructed tracker/calorimeter hit. Contingent on https://github.com/eic/EDM4eic/pull/86.
What kind of change does this PR introduce?
Please check if this PR fulfills the following:
Does this PR introduce breaking changes? What changes might users need to make to their code?
Does this PR change default behavior?