Add LGADHitReconstruction that does clustering

[ssedd1123]

Briefly, what does this PR introduce?

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?

TOFBarrelRecHits is now generated from the new class "LGADHitReconstruction". This class takes the digitized ADC and TDC values from each strips within the BTOF sensor to reconstruct the hit location, hit time and energy deposition.

Currently, this class is just a skeleton with position calculated by a simple weighted average, energy is just the sum of ADC values inside a sensor and time is just the earliest TDC value within a sensor, transformed linearly to get a rough time and EDep. There is no time walk correction and this class is unable to distinguish multiple hits in the same sensor if they arrive within the same EICROC cycle (25 ns). However, our group is developing a more sophisticated clustering algorithm and the time walk correction will be implemented in the future in another pull request. This is just a skeletal class for our group to develop further.

Name of the class is still open for discussion. See #1778

Does this PR change default behavior?

TOFBarrelRecHits is now generated by LGADHitReconstruction. If TOFBarrelRecHits are used by downstream classes for track reconstruction, I believe it will lower the tracking efficiency because digitization class discard hits with too low energy threshold. The lack of time walk correction and energy loss through the boundaries of BTOF sensor also contributes to the worsening of position resolution, which may or may not have huge ramifications.

Part of the reason I make this pull request is precisely because I don't fully understand it's downstream effect. Please feel free to let me know if any part of the performance is significantly degraded.

[github-actions]

Capybara summary for PR 1779

• 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-17T19:06-04:00 617f509}}

[simonge]

I think here you will want to split the algorithm into two parts again:

1. Calibration of the RawTrackerHit into a TrackerHit.
2. Clustering of the reconstructed hits into a Measurement2D.

The calibration of an individual hit can be very simple at the moment as there is no variation in the gain, delay, noise etc. from channel to channel but basic timewalk can be added there.

The TrackerHit only has a single relation to a RawTrackerHit while the Measurement2D is supposed to allow for clustering. I have a similar algorithm to what you're developing, which requires pre-divided collections, here:
https://github.com/eic/EICrecon/blob/main/src/algorithms/fardetectors/FarDetectorTrackerCluster.cc

A basic weighted clustering algorithm could easily be shared between tracking detectors but I wouldn't necessarily advise adopting mine.

This will require a bit of a change of where the Measurements are included into the rest of the tracking pipeline

[ssedd1123]

I think here you will want to split the algorithm into two parts again:

1. Calibration of the RawTrackerHit into a TrackerHit.
2. Clustering of the reconstructed hits into a Measurement2D.

The calibration of an individual hit can be very simple at the moment as there is no variation in the gain, delay, noise etc. from channel to channel but basic timewalk can be added there.

The TrackerHit only has a single relation to a RawTrackerHit while the Measurement2D is supposed to allow for clustering. I have a similar algorithm to what you're developing, which requires pre-divided collections, here: https://github.com/eic/EICrecon/blob/main/src/algorithms/fardetectors/FarDetectorTrackerCluster.cc

A basic weighted clustering algorithm could easily be shared between tracking detectors but I wouldn't necessarily advise adopting mine.

This will require a bit of a change of where the Measurements are included into the rest of the tracking pipeline

That is a good idea. I am working on it.

Thanks for the references on clustering. Since this class is just a skeleton class for the TOF group to develop more sophisticated clustering algorithm in the future, it's better that we write a separate clustering class for BTOF.

I can certainly output the cluster information as Measurement2D, but I am not sure if the tracking group is using it. As a matter of fact, I don't know what the downstream track reconstruction class takes as input. I know that before I was asked to develop TOF class, the final output from BTOF.cc is "TOFBarrelRecHits", which is a TrackerHit class, so I just assumed that ACTS downstream takes "TOFBarrelRecHits" as input for their track reconstruction. Can you confirm if downstream classes will still work correctly if I switch "TOFBarrelRecHits" to a Measurement2D class please? Because at this stage, I do want to see how significantly track reconstruction is affacted by digitization.

[ssedd1123]

@simonge Is cluster.setLoc supposed to be local position? In that case, should I also use local position for the position of TrackerHit? Just want to make sure my understanding is correct before proceeding further.

Edit: Oh I get it now. "Loc" stands for local, not location.

[simonge]

I can certainly output the cluster information as Measurement2D, but I am not sure if the tracking group is using it. As a matter of fact, I don't know what the downstream track reconstruction class takes as input. I know that before I was asked to develop TOF class, the final output from BTOF.cc is "TOFBarrelRecHits", which is a TrackerHit class, so I just assumed that ACTS downstream takes "TOFBarrelRecHits" as input for their track reconstruction. Can you confirm if downstream classes will still work correctly if I switch "TOFBarrelRecHits" to a Measurement2D class please? Because at this stage, I do want to see how significantly track reconstruction is affacted by digitization.

The Measurement2D is the interface required by acts. At the moment all of the other TrackerHits are converted into Measurement2Ds, simply without clustering. You will need to make sure you get the correct surface from the acts geometry so it gets used correctly:
https://github.com/eic/EICrecon/blob/main/src/algorithms/tracking/TrackerMeasurementFromHits.cc

[ssedd1123]

It's done. Now the class is separated into two: LGADHitCalibration and LGADHitClustering. The output of LGADHitClustering is now Measurement2D.

TofEfficiency_process complains that TOFBarrelRecHits is no longer of type TrackerHit. I modified it to accept Measurement2D, but I don't know if I did it correctly as I did not know how to test TofEfficiency_process locally. Please double check my modifications, and if you can tell me how to run it locally or give me some relevant references, I would greatly appreciate that.

[ssedd1123]

All physics_benchmarks failed. I did some investigation and, apparently, it's caused by the failure of Measurement2D to be associated with the corresponding raw_hit. I tried to revert the output of LGADHitClustering back to TrackerHit, do some very rudimentary hit matching and assign it to the output TrackerHit with TrackerHit::setRawHit. I don't know if the resultant physics_benchmarks outputs make sense, but at least snakemake is not throwing any error when I run it locally.

I tried to call TrackerHit::setRawHit on all the tracker hits before adding them to Measurement2D, but the physics_benchmarks still fail. Did I miss a step here? Is there a equivalent function in Measurement2D for TrackerHit::setRawHit?

[veprbl]

I believe the issue was fixed in #1792. I've rebased to fix conflicts due to recent introduction of forced clang-format. Let's see how this runs (may take time, there is a bit of job backlog currently)

[veprbl]

Somehow an issue crept into the previous merge: https://github.com/eic/EICrecon/compare/49dbca98c2027fa823766080b2914c40457d5f93..a1d28b172db6746afd9eeac66cb4fd69ee5fcecf where formatted code from main branch got duplicated. That is fixed now.