Low-Q2 Charge Sharing

[simonge]

Briefly, what does this PR introduce?

Introduces sensor charge sharing for hits in the Low-Q2 Tagger dividing a single SimTrackerHit into several.

The method originally introduced for LGADs has been simplified and optimized to make it more accessible for future users, making more use of functions provided by dd4hep.

What kind of change does this PR introduce?

• 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?

No

Does this PR change default behavior?

Adds the TaggerTrackerSharedHits to the output and uses them as the input to the digitization.

[github-actions]

Capybara summary for PR 1763

• rec_dis_10x100_minQ2=0_craterlake
• rec_dis_10x100_minQ2=1000_craterlake_tracking_only
• rec_dis_18x275_minQ2=0_craterlake_18x275
• rec_dis_18x275_minQ2=1000_craterlake_18x275
• rec_dis_5x41_minQ2=0_craterlake_5x41
• rec_e_1GeV_20GeV_craterlake
• rec_pi_1GeV_20GeV_craterlake
  ^{_{Last updated 2025-04-09T16:07-04:00 e9246a3}}

[veprbl]

Need a rebase.

[simonge]

There are some changes in the BTOF charge sharing I need to understand/fix and discus whether the changes are actually improvements or not.

[ssedd1123]

There are some changes in the BTOF charge sharing I need to understand/fix and discus whether the changes are actually improvements or not.

What's the problem you're facing, if you don't mind me asking? I think it is a nice improvement over the original LGADChargeSharing. I've always considered testing cellID with position converter and see if it throws error is a bit of a hack. I did not know m_seg.neighbours exist at all.

[simonge]

What's the problem you're facing, if you don't mind me asking? I think it is a nice improvement over the original LGADChargeSharing. I've always considered testing cellID with position converter and see if it throws error is a bit of a hack. I did not know m_seg.neighbours exist at all.

It's the differences in the capybara I don't quite understand:
https://eicrecon.epic-eic.org/pr/1763/capybara/rec_dis_10x100_minQ2=0_craterlake/index.html#TOFBarrelADCTDC

I thought that the changes shouldn't make a difference to the number or charge of hits if the charge limit is set to 0. But it looks like there are significantly fewer hits being created.

The neighbours will only work if the sensor uses a segmentation in the geometry which may not always be the case (but probably always should be...). I don't believe this will account for the edges of sensors either, so a hit in the detector can probably spread outside the sensor.

[simonge]

Looks like the problem comes from the MultiSegmentation used for the BTOF. The dd4hep neighbours function doesn't return any cellIDs when it is used. If it is possible to recover which sub-segmentation was used for the specific CellID this might be fixable but I haven't looked yet.