fix the weight calculation in raw to sim hits association

[ShujieL]

Briefly, what does this PR introduce?

In Si digi, the weight between raw and sim hit was set to 1 manually regardless of how many sim hits on the same cell. This update should provide a rough but more correct weight.

What kind of change does this PR introduce?

• [ x] Bug fix (issue #__)
• New feature (issue #__)
• Documentation update
• Other: __

Please check if this PR fulfills the following:

• Tests for the changes have been added
• Documentation has been added / updated
• Changes have been communicated to collaborators

Does this PR introduce breaking changes? What changes might users need to make to their code?

Does this PR change default behavior?

[github-actions]

Capybara summary for PR 2065

• rec_dis_10x100_minQ2=0_craterlake_10x100
• rec_dis_10x100_minQ2=1000_craterlake_tracking_only
• rec_dis_18x275_minQ2=0_craterlake_18x275
• rec_dis_18x275_minQ2=0_craterlake_18x275_MT
• rec_dis_18x275_minQ2=0_craterlake_18x275_ST_MT
• rec_dis_18x275_minQ2=1000_craterlake_18x275
• rec_dis_18x275_minQ2=1000_craterlake_18x275_MT
• rec_dis_18x275_minQ2=1000_craterlake_18x275_ST_MT
• rec_dis_5x41_minQ2=0_craterlake_5x41
• rec_e_1GeV_20GeV_craterlake
• rec_pi_1GeV_20GeV_craterlake
  ^{_{Last updated 2025-09-08T20:13-04:00 dbc31c5}}

[ShujieL]

To add a bit more context to this PR, I looked at the background merged events, and noticed that the photons from Synchrotron radiation almost always left a pair of sim hits on one pixel, see attached an example from the vertex barrel hits.

In our current digi code, the energy deposit on a given cell is the sum of all sim hits so they almost always pass the edep threshold. But any idea on how DD4hep created two hits here? The non-zero quality code in this case seems to indicate overlay (bit=31).

[wdconinc]

Please remove these magic numbers.

[wdconinc]

And why the rounding?

[ShujieL]

by "magic number" I guess you mean the times 10 for rounding?

In line 72 will fill the charge with (std::int32_t)std::llround(sim_hit.getEDep() * 1e6). one could use exactly this formula. I wanted to use rounding to make sure it will return 1 instead of 0.99999 for example, and I assume we don't care about too much about precision. Would times 100 (two decimal digits) be better?

[wdconinc]

Don't round.

Other magical number is the 1e6.

[ShujieL]

1e6 is the unit conversion. Can you suggest some alternative?

[wdconinc]

https://github.com/eic/EDM4eic/blob/main/utils/include/edm4eic/unit_system.h, https://github.com/AIDASoft/DD4hep/blob/master/DDParsers/include/Evaluator/DD4hepUnits.h

[ShujieL]

Thanks! I changed to use eV for rawhit.charge so it's always integer. It was keV with the magic number of 1e6, which is not the best choice because our detector threshold is often <1keV.
We can have a separate discussion later on whether it makes sense to declare RawTrackerHit.charge as int32_t.

[wdconinc]

I don't know how we've come this far without proper energy deposition digitization in the silicon tracker. What bit depth and dynamic range do we expect there? This digitization algorithm can learn a lot from the calorimeter digitization... It almost doesn't make sense to tack on more hacky hard coded bit depth and dynamic range assumptions with this PR until the underlying logic is fixed.

[simonge]

I don't know how we've come this far without proper energy deposition digitization in the silicon tracker.

I thought we'd decided to leave this in place, rather than spend time patching it, while pursuing proper technology dependant approaches.

To add a bit more context to this PR, I looked at the background merged events, and noticed that the photons from Synchrotron radiation almost always left a pair of sim hits on one pixel, see attached an example from the vertex barrel hits.
In our current digi code, the energy deposit on a given cell is the sum of all sim hits so they almost always pass the edep threshold. But any idea on how DD4hep created two hits here? The non-zero quality code in this case seems to indicate overlay (bit=31).

Is that not the quality flag for secondary rather than overlay. Does the associated MCParticle point to the same particle? Is this just the synchrotron backgrounds or are other sources showing the same thing?

[ShujieL]

Is that not the quality flag for secondary rather than overlay. Does the associated MCParticle point to the same particle? Is this just the synchrotron backgrounds or are other sources showing the same thing?

Edited: the quality value I saw is 1073741824, which is indeed the secondary bit (30th) given how the set_bit function works. Thanks for pointing it out.
See https://github.com/key4hep/EDM4hep/blob/a200fd1567fb189f19b3db0330261c37b062ccca/edm4hep.yaml#L323

Both hits are associated with the same particle, mainly from SR.

[ShujieL]

I don't know how we've come this far without proper energy deposition digitization in the silicon tracker. What bit depth and dynamic range do we expect there? This digitization algorithm can learn a lot from the calorimeter digitization... It almost doesn't make sense to tack on more hacky hard coded bit depth and dynamic range assumptions with this PR until the underlying logic is fixed.

I will follow up with you and Simon to arrange a dedicated discussion on edep digitization scheme. Any more suggestions on the current change?