Skip to content

INTT hit duplication implementation - #4290

Closed
hrjheng wants to merge 12 commits into
sPHENIX-Collaboration:masterfrom
hrjheng:InttHitCarryover_dev
Closed

hrjheng wants to merge 12 commits into
sPHENIX-Collaboration:masterfrom
hrjheng:InttHitCarryover_dev

Conversation

@hrjheng

@hrjheng hrjheng commented Jun 7, 2026 •

Copy link
Copy Markdown
Contributor

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work for users)
  • Requiring change in macros repository (Please provide links to the macros pull request in the last section)
  • I am a member of GitHub organization of sPHENIX Collaboration, EIC, or ECCE (contact Chris Pinkenburg to join)

What kind of change does this PR introduce? (Bug fix, feature, ...)

This PR introduces an optional INTT hit-duplication implementation in Fun4AllStreamingInputManager as a possible mitigation for the hit carry-over issue. When enabled, raw hits found at a later BCO, (N + M * 120), are copied into the raw-hit container with their BCO reassigned to N.
The duplication is disabled by default. The maximum shift multiple, controlled by the variable m_InttHitCarryOverShiftMaxMultiple, is configurable, while the carry-over shift is currently fixed at 120.

[Update 2026.06.11] The idea is to introduce an additional "second" duplication pass, in which hits in the next (or subsequent) strobes with FPHX BCO = 0 are also duplicated. I suspect this is necessary in addition to the "first" duplication pass because your previous slides indicate a non-negligible population of hits whose FPHX BCO is reset, particularly near the end of a strobe (two spikes appear in the subsequent strobe: one at FPHX BCO = 0 and another at the nominal +120 shift)
To avoid duplicating the same hits twice, the "second" pass is skipped whenever the target BCO (i.e. the BCO to which hits are being duplicated) corresponds to FPHX BCO = 0. In that case, the first duplication has already recovered all possible carried-over hits

(This strategy still requires careful study and discussion, so the PR is currently marked as a draft)

TODOs (if applicable)

Links to other PRs in macros and calibration repositories (if applicable)

INTT hit carry-over mitigation: optional hit-duplication in Fun4AllStreamingInputManager

Motivation / Context

INTT streaming can exhibit “hit carry-over” behavior where hits associated with later BCOs are effectively carried into earlier strobe windows (linked to FPHX BCO resets). This PR adds an optional, off-by-default mitigation that duplicates affected raw INTT hits into earlier BCOs to recover the intended hit timing.

AI note: AI-generated summaries can contain mistakes—please use best judgment and validate details during review.

Key changes

  • New configuration API (off by default) in Fun4AllStreamingInputManager.h:

    • EnableInttHitDuplication(bool b = true)
    • InttHitCarryOverShiftMaxMultiple(int i)
    • Internal defaults: m_InttHitDuplication{false}, carry-over shift base fixed at 120, and max multiple defaulting to 4
  • Extended INTT raw hit filling in Fun4AllStreamingInputManager.cc (FillIntt()):

    • When m_InttHitDuplication is enabled:
      • Pre-reading/arming step: repeatedly calls FillInttPool() until the highest stashed INTT BCO reaches select_crossings + (120 * maxMultiple), including a guard to break if FillInttPool() doesn’t advance the highest BCO (avoids infinite loops).
      • Two-pass duplication into InttRawHitContainer:
        • Pass 1: for each target BCO N, copy hits found at N + k*120 for k=1..maxMultiple, and reassign the copied hit BCO back by -k*120 (with additional checks on hit BCO relative to the shift).
        • Pass 2 (FPHX reset recovery): for the same N, attempt an additional copy targeting the case where the copied hits correspond to FPHX BCO = 0.
          • The second-pass copy is skipped when target_refbco == 0 (derived from N % 120) to avoid double-duplicating the FPHX-bco=0 hits already covered by Pass 1.
          • Second-pass copies only proceed if source_hit->get_FPHX_BCO() == 0 and the hit BCO is not earlier than the computed reset_shift.
    • If duplication is disabled, behavior is unchanged aside from minor non-semantic iterator formatting.
  • Minor code-style changes (no semantic intent):

    • INTT/MVTX map iteration uses auto & in updated loops.

Potential risk areas

AI note: AI can be wrong—please verify with targeted tests/QA.

  • Reconstruction / physics behavior: duplication increases INTT raw hit multiplicity and modifies BCO assignments; this can affect downstream hit building and any analysis relying on raw-hit time structure.
  • Correctness/edge cases: the combined “pre-read to threshold + two-pass duplication + skip condition when N % 120 == 0” is subtle; off-by-one/BCO-boundary conditions could lead to missed or extra duplicates near strobe boundaries.
  • Performance & memory: pre-reading extends pooling until a higher BCO threshold, and duplication can add up to maxMultiple (plus second-pass candidates) copies per hit; this may increase CPU time and memory use.
  • Thread-safety: changes operate on shared instance state (m_InttRawHitMap, m_RefBCO, etc.); if this component were used concurrently, risks remain (though existing design appears single-threaded).

Possible future improvements

  • Add/extend QA validation (e.g., compare reconstructed/selected hit rates and timing distributions with duplication on vs off).
  • Consider unit/regression tests for the duplication logic (especially around FPHX BCO reset transitions and the target_refbco==0 skip).
  • Explore configurability of the base 120-BCO shift (currently fixed) and document recommended values per running mode.
  • Optimize duplication loops (e.g., reduce repeated map lookups) if performance becomes limiting.

@coderabbitai

coderabbitai Bot commented Jun 7, 2026 •

Copy link
Copy Markdown
Contributor

Review Change Stack

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: c96f28a9-b4eb-469f-bfa7-f89db1c09a77

📥 Commits

Reviewing files that changed from the base of the PR and between 176ba1d and 94182d2.

📒 Files selected for processing (1)
  • offline/framework/fun4allraw/Fun4AllStreamingInputManager.cc

📝 Walkthrough

Walkthrough

Adds configurable INTT hit duplication to Fun4AllStreamingInputManager: new header settings, a BCO-threshold-based pool prefill loop, and a two-pass duplication path while draining hits into the output container.

Changes

INTT Hit Duplication Feature

Layer / File(s) Summary
INTT duplication configuration interface
offline/framework/fun4allraw/Fun4AllStreamingInputManager.h
Adds <vector>, public setters for enabling INTT hit duplication and setting the maximum carry-over shift multiple, and private members for the duplication state and shift parameters.
INTT prefill and two-pass duplication
offline/framework/fun4allraw/Fun4AllStreamingInputManager.cc
Extends FillIntt() with a threshold-driven FillInttPool() loop and stall guard, then duplicates hits into InttRawHitContainer in two passes while adjusting BCO values and skipping already-covered reset cases. Also reformats the m_InttRawHitMap and m_MvtxRawHitMap loop variables.

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@sphenix-jenkins-ci

Copy link
Copy Markdown

Build & test report

Report for commit 4af70f2dd2331b3748d4234ede69e0eed835b096:
Jenkins passed


Automatically generated by sPHENIX Jenkins continuous integration
sPHENIX             jenkins.io

@osbornjd osbornjd left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems like a reasonable implementation to me, we should test it out and see if it improves the cluster/hit drop off towards the end of the strobe width

@sphenix-jenkins-ci

Copy link
Copy Markdown

Build & test report

Report for commit 6ce8662791365c156efa10702d1cc6026ee8d39b:
Jenkins on fire


Automatically generated by sPHENIX Jenkins continuous integration
sPHENIX             jenkins.io

@sphenix-jenkins-ci

Copy link
Copy Markdown

Build & test report

Report for commit 88b10946a50a324a94399ffc39c04f1b0f1c5cf6:
Jenkins on fire


Automatically generated by sPHENIX Jenkins continuous integration
sPHENIX             jenkins.io

@sphenix-jenkins-ci

Copy link
Copy Markdown

Build & test report

Report for commit 418247ecb2937d0d99002613f8439419c9ef3cca:
Jenkins on fire


Automatically generated by sPHENIX Jenkins continuous integration
sPHENIX             jenkins.io

@sphenix-jenkins-ci

Copy link
Copy Markdown

Build & test report

Report for commit 3844e7c18dfce80a3527e09a12014bf248beb0b5:
Jenkins on fire


Automatically generated by sPHENIX Jenkins continuous integration
sPHENIX             jenkins.io

@hrjheng
hrjheng marked this pull request as ready for review June 16, 2026 19:56

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1


ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 97c8f8ac-55d4-4a5b-90d8-b7450e113e47

📥 Commits

Reviewing files that changed from the base of the PR and between d9e42ff and 176ba1d.

📒 Files selected for processing (2)
  • offline/framework/fun4allraw/Fun4AllStreamingInputManager.cc
  • offline/framework/fun4allraw/Fun4AllStreamingInputManager.h

Comment thread offline/framework/fun4allraw/Fun4AllStreamingInputManager.cc Outdated
@sphenix-jenkins-ci

Copy link
Copy Markdown

Build & test report

Report for commit 176ba1d92556b64985d3bdc373df9c7a33d1c479:
Jenkins on fire


Automatically generated by sPHENIX Jenkins continuous integration
sPHENIX             jenkins.io

@sphenix-jenkins-ci

Copy link
Copy Markdown

Build & test report

Report for commit cbf93806fb70d149f66ba55bc4285dce35cb6779:
Jenkins passed


Automatically generated by sPHENIX Jenkins continuous integration
sPHENIX             jenkins.io

@hrjheng

hrjheng commented Jun 29, 2026

Copy link
Copy Markdown
Contributor Author

Closing this PR because Cheng-Wei has created a new one: #4324

Cheng-Wei can provide the full explanation, but here is my understanding of the differences between the two implementations:

  1. Both implementations use the same two-pass duplication strategy. The first duplication pass is identical (at least conceptually).
  2. Cheng-Wei pointed out that, although my second duplication pass correctly reassigns the FPHX BCO, it does not update BCO_full. As a result, the duplicated hits are not actually assigned to the intended strobe. Cheng-Wei's implementation corrects this by updating BCO_full together with the FPHX BCO.
  3. Cheng-Wei's implementation also duplicates hits with FPHX BCO values from 0 through 5, rather than only FPHX BCO = 0. The hypothesis is that when the FPHX BCO is reset, it may be reset to any value between 0 and 5, randomly or not. This hypothesis has not yet been verified.

To test 3, Cheng-Wei will compare the INTT doublet distributions as a function of FPHX BCO using two configurations:

  • duplicating only hits with FPHX BCO = 0 (with the corrected BCO_full assignment), and
  • duplicating hits with FPHX BCO values from 0 to 5.
    If the two approaches produce significantly different results, that would provide evidence supporting the hypothesis that the reset FPHX BCO can take values other than 0. If there is little or no difference, the additional duplication may not be necessary.

@sphenix-jenkins-ci

Copy link
Copy Markdown

Build & test report

Report for commit 94182d2409b661cc571215acac73b520de300a99:
Jenkins passed


Automatically generated by sPHENIX Jenkins continuous integration
sPHENIX             jenkins.io

@hrjheng
hrjheng deleted the InttHitCarryover_dev branch August 27, 2026 16:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants