Realistic BTOF digitization

[ssedd1123]

Briefly, what does this PR introduce?

It's an attempt to make LGAD sensor response for Barrel TOF more realistic by doing the following,

1. Spread charge deposition from strips that are hit directly to nearby strips.
2. Perform digitization by converting charge deposited to electric pulse.
3. Digitize the pulse by converting it to TDC and ADC value. ADC propto pulse height and TDC propto time when voltage crosses certain threshold.
4. Convert the TDC and ADC value back to time and Edep by linear fit.
5. Return the BTOF hit point as "TOFBarrelRecHit". Position is estimated by either weighted sum of ADC or just center of the cell with max ADC. It's weighted average by default, but the behavior can be changed by parameters.

Noise, edge correction and time talk correction will be developed in the future.

What kind of change does this PR introduce?

• [x ] Bug fix (issue Enhanced Realism in TOF Reconstruction & Digitization #1656 )
• New feature (issue #__)
• Documentation update
• [x ] Other: Implementation of digitization and clusterization for LGADs in Barrel TOF

Please check if this PR fulfills the following:

• Tests for the changes have been added
• Documentation has been added / updated
• [x ] 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?

It replaces the content of "TOFBarrelRecHit" with results of this new clusterization. It was originally just geant point + random smearing. I have communicated to the reconstruction group and they advise that I submit this pull request so they can study the effect of having this new digitization/clusterization algorithm. They will decide if I should save the data in a new branch or replace the origin content.

[github-actions]

Capybara summary for PR 1635

• 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-02-20T18:37-05:00 04fe162}}

[ruse-traveler]

Okay, last comment from me! The capybara report makes it seems like there's a few cases where a CellID gets set to some sort of max value (~1.9e19). Is this to be expected?
https://eicrecon.epic-eic.org/pr/1635/capybara/rec_dis_5x41_minQ2=0_craterlake_5x41/index.html#TOFBarrelADCTDC

[veprbl]

Okay, last comment from me! The capybara report makes it seems like there's a few cases where a CellID gets set to some sort of max value (~1.9e19). Is this to be expected? https://eicrecon.epic-eic.org/pr/1635/capybara/rec_dis_5x41_minQ2=0_craterlake_5x41/index.html#TOFBarrelADCTDC

This is expected for 64 bit values. We often have upper 32 bit split into x and y coordinates that are non-zero and produce an overall large cellID.

[ruse-traveler]

This is expected for 64 bit values. We often have upper 32 bit split into x and y coordinates that are non-zero and produce an overall large cellID.

Ahhhhh gotcha! I see!

[ssedd1123]

Sorry I did not update this request for a month. Unfortunately I am having significant difficulty with my work visa so I am legally forbidden from performing any research related work at the moment. I will return to this request once I worked out my visa situation.

[ruse-traveler]

Sorry I did not update this request for a month. Unfortunately I am having significant difficulty with my work visa so I am legally forbidden from performing any research related work at the moment. I will return to this request once I worked out my visa situation.

No worries! We completely understand given the situation! Just let us know if you need help, and we'll be happy to jump in!

[veprbl]

From what I see, all of my comments are addressed. I'm happy with the state of this, but let's keep this pending for others to have time to comment. We probably can use some time from the upcoming digi-in-tracking discussion, if there is a contention.

[ssedd1123]

I have resolved my visa issue and resumed working. Since @veprbl changed the interface for LGADPulseGenerator (thank you for doing it), I believe all outstanding issues are resolved. I see that @ruse-traveler has requested changes but I don't see the request itself. @ruse-traveler can you restate your request please? I will have that resolved. Hopefully, this pull request is mature enough to be accepted.

[ruse-traveler]

I have resolved my visa issue and resumed working. Since @veprbl changed the interface for LGADPulseGenerator (thank you for doing it), I believe all outstanding issues are resolved. I see that @ruse-traveler has requested changes but I don't see the request itself. @ruse-traveler can you restate your request please? I will have that resolved. Hopefully, this pull request is mature enough to be accepted.

Those should be old requests! My requests have all been addressed, and I'm quite happy with this PR as-is!

[ruse-traveler]

This is a huge step! Thank you for all of the hard work on this!

[ruse-traveler]

Pulling this out of the merge queue for a second: were we going to wait until the tracking digitization discussion for any further comments?

[ssedd1123]

I am fine with one final discussion, but even if we don't, it shouldn't affect any other part of the simulation because the simulated ADC and TDC value are not used by any other class downstream, they are just dangling there.

What I plan to do next is to submit another pull request soon after this one is approved, which consist of using these simulated ADC and TDC value to reconstruct hit location, and feed it to track reconstruction algorithm downstream. When that happen, it will definitely affect track reconstruction quality and we will have another round of discussion to test.

If you mean by "tracking digitization discussion" that you want to study the effect of digitization on track reconstruction, it would be more appropriate to discuss it in the next pull request.

With that being said, if you have any more issues that you want to discuss before the merge, I am happy to. Please let me know if you have any concerns.

[veprbl]

Let me clarify. There is no plan to have a target discussion of this PR. We are putting some time between approval and merge to let people comment on immediate concerns. The discussion will be on getting timing aspects of digitization right in the existing codes (prompted by discussion regarding digi simulation for MPGD/MAPS trackers). We will follow up with plan of changes after that.

[ssedd1123]

Okay got it. We shell wait for the responses.

[veprbl]

Still good