Fix Track Sharing in PHSimpleVertexFinder - #4444
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthrough
ChangesTrack connection resolution
Priority: ⬇️ Low Merge Risk: ⚪ Minimal · up to This change completes chained track grouping while preserving existing selection behavior, with no material merge-blocking risk identified. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Build & test reportReport for commit 3157e7f6f87f65ea82fc7a5d440a2ca962d379b6:
Automatically generated by sPHENIX Jenkins continuous integration |
|
I'm not sure I understand what this PR accomplishes from the plots that are added - can you provide some context/detail? |



comment: <
The original
findConnectedTracksimplementation used a single scan of the track-pair map to extend each connected group. During that scan, a pair could add tracks to the group when at least one of its tracks was already present. However, a pair rejected earlier because neither track belonged to the group was not reconsidered after subsequent pairs expanded the group. Consequently, the group could be finalized before all indirectly connected tracks had been included, making the grouping dependent on the order in which pairs were visited.For example, consider a group initially containing tracks A and B. If the scan encounters the pair C–D before B–C, it initially skips C–D. The later pair B–C adds C, making C–D eligible to extend the group, but the single scan never returns to it. Track D therefore remains outside the group despite being connected to A and B through C. Subsequent grouping can then produce overlapping groups that share tracks, contributing to track sharing between vertex candidates.
This change wraps the existing inner pair scan in a loop that repeats until a complete scan adds no new tracks. At the start of each pass, the size of the
connectedset is recorded. After the pass, the scan is repeated only if that size has increased. This allows previously skipped pairs to be reconsidered as the group grows and follows indirect connections until no further expansion is possible. Becauseconnectedis a set, inserting tracks already present does not increase its size or unnecessarily prolong the loop. The finite number of available tracks guarantees termination.The modification is confined to repeating the existing inner scan and checking whether the connected set has grown. The existing pair-selection conditions, track insertions,
usedbookkeeping, and group-finalization logic are retained. No reconstruction cuts or downstream vertex-position calculations are changed. The fix addresses incomplete connected-group construction.Types of changes
What kind of change does this PR introduce? (Bug fix, feature, ...)
TODOs (if applicable)
Links to other PRs in macros and calibration repositories (if applicable)
track_sharing_pull_request_plots.pdf
Uploading SAED_PPG_07_25_2026.pdf…
Motivation / Context
This change fixes primary track sharing in
PHSimpleVertexFinder. It ensures that chained track connections form complete connected groups.Key Changes
findConnectedTracksnow repeats the pair scan until a full scan adds no tracks.Potential Risk Areas
Possible Future Improvements
Test results were not provided. AI-generated summaries can contain mistakes; verify this summary against the implementation and validation results.