LST: Creation and implementation of T4 (quadruplet) object

[jchismar]

This PR introduces the T4 (quadruplet) object to increase efficiency at large displacement. T4s are built from two T3s that share a common LS. Only T3s that are not used in pT5s, pT3s or T5s are considered, and the T3s must start in either the endcap or on barrel layer 3 to reduce duplicates with the other objects. T4s are added as an additional track candidate so that the final TC collection is in the following order: pT5, pT3, T5, T4, and pLS. Motivation for the introduction of T4s was presented at the Tracking POG meeting on 30 Sep 2025.

5 selections are applied to T4s: requiring that the charges of the two T3s must be the same, a DNN classifier, a beta cut for consistency with a circle in r-phi (identical to that used for T5s), a chi-squared cut for consistency with a helix in r-z, and a cut on the impact parameter (dxy). The T4 DNN uses a multi-class architecture (similar to the T3 DNN) which classifies T4s as fake, real prompt, and real displaced. The DNN and dxy cut values are set to keep real displaced tracks while rejecting fake and real prompt tracks.

The displaced efficiency gain on a 50cm cube muon gun sample is shown below, where the current configuration is shown in blue and the addition of T4s is shown in red.

Full plots can be found here for ttbar PU200 and 50cm cube muon gun.

[cmsbuild]

cms-bot internal usage

[cmsbuild]

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-49529/47038

• There are other open Pull requests which might conflict with changes you have proposed:
  • File Validation/RecoTrack/python/HLTmultiTrackValidator_cff.py modified in PR(s): [NGT] add "pixel-less" and "withPixels" track validation monitoring for HLT #49517

[cmsbuild]

A new Pull Request was created by @jchismar for master.

It involves the following packages:

• Configuration/EventContent (operations)
• HLTrigger/Configuration (hlt)
• RecoTracker/FinalTrackSelectors (reconstruction)
• RecoTracker/IterativeTracking (reconstruction)
• RecoTracker/LST (reconstruction)
• RecoTracker/LSTCore (reconstruction)
• Validation/RecoTrack (dqm)

@Martin-Grunewald, @cmsbuild, @ctarricone, @davidlange6, @fabiocos, @ftenchini, @gabrielmscampos, @jfernan2, @mandrenguyen, @mmusich, @nothingface0, @rseidita, @srimanob can you please review it and eventually sign? Thanks.
@GiacomoSguazzoni, @Martin-Grunewald, @SohamBhattacharya, @VinInn, @VourMa, @dgulhan, @elusian, @fabiocos, @felicepantaleo, @gpetruc, @missirol, @mmasciov, @mmusich, @mtosi, @rovere, @wmtford this is something you requested to watch as well.
@ftenchini, @mandrenguyen, @sextonkennedy you are the release manager for this.

cms-bot commands are listed here

[gabrielmscampos]

please test

[mmusich]

@cmsbuild please abort

[mmusich]

test parameters:

• enable = hlt_p2_integration, hlt_p2_timing
• workflows = ph2_hlt

[mmusich]

@cmsbuild, please test

[mmusich]

@jchismar this branch has conflicts that must be resolved.

[cmsbuild]

+1

Size: This PR adds an extra 208KB to repository
Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-6e9aac/49762/summary.html
COMMIT: 45e831b
CMSSW: CMSSW_16_0_X_2025-12-01-2300/el8_amd64_gcc13
Additional Tests: HLT_P2_INTEGRATION,HLT_P2_TIMING
User test area: For local testing, you can use /cvmfs/cms-ci.cern.ch/week0/cms-sw/cmssw/49529/49762/install.sh to create a dev area with all the needed externals and cmssw changes.

HLT P2 Timing: chart
DAS Queries: The DAS query tests failed, see the summary page for details.

Comparison Summary

Summary:

• You potentially removed 1 lines from the logs
• ROOTFileChecks: Some differences in event products or their sizes found
• Reco comparison results: 8 differences found in the comparisons
• Reco comparison had 4 failed jobs
• DQMHistoTests: Total files compared: 73
• DQMHistoTests: Total histograms compared: 5002869
• DQMHistoTests: Total failures: 5836
• DQMHistoTests: Total nulls: 0
• DQMHistoTests: Total successes: 4997013
• DQMHistoTests: Total skipped: 20
• DQMHistoTests: Total Missing objects: 0
• DQMHistoSizes: Histogram memory added: 0.652 KiB( 72 files compared)
• DQMHistoSizes: changed ( 34434.775 ): 0.652 KiB HLT/Tracking
• Checked 295 log files, 253 edm output root files, 73 DQM output files
• TriggerResults: found differences in 2 / 71 workflows

[cmsbuild]

+1

Size: This PR adds an extra 20KB to repository
Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-6e9aac/49785/summary.html
COMMIT: acef004
CMSSW: CMSSW_16_0_X_2025-12-03-1100/el8_amd64_gcc13
Additional Tests: HLT_P2_INTEGRATION,HLT_P2_TIMING
User test area: For local testing, you can use /cvmfs/cms-ci.cern.ch/week0/cms-sw/cmssw/49529/49785/install.sh to create a dev area with all the needed externals and cmssw changes.

HLT P2 Timing: chart
DAS Queries: The DAS query tests failed, see the summary page for details.

Comparison Summary

Summary:

• You potentially added 1 lines to the logs
• ROOTFileChecks: Some differences in event products or their sizes found
• Reco comparison results: 12 differences found in the comparisons
• Reco comparison had 4 failed jobs
• DQMHistoTests: Total files compared: 73
• DQMHistoTests: Total histograms compared: 5016897
• DQMHistoTests: Total failures: 6774
• DQMHistoTests: Total nulls: 0
• DQMHistoTests: Total successes: 5010103
• DQMHistoTests: Total skipped: 20
• DQMHistoTests: Total Missing objects: 0
• DQMHistoSizes: Histogram memory added: 0.652 KiB( 72 files compared)
• DQMHistoSizes: changed ( 34434.775 ): 0.652 KiB HLT/Tracking
• Checked 295 log files, 253 edm output root files, 73 DQM output files
• TriggerResults: found differences in 2 / 71 workflows

[gabrielmscampos]

Are the changes in the DQM histograms behaving as expected with this PR's changes?

[slava77]

Are the changes in the DQM histograms behaving as expected with this PR's changes?

The .7x workflows with differences all have LST running

• 34434.754 1424

  • (I looked in detail only at this one). Differences start in HLT tracking and apparently show up downstream as well
  • The general summary in tracking shows that the differences are only in tracks without pixel hits. This PR adds more such tracks. The recently added pixelLess track monitoring shows pretty small changes
  • DQM bin-to-bin is a bit more tractable and shows e.g. some more of these pixelLess tracks
    as expected, these are all with 4 layers (T4)

• 34434.755 1384

• 34434.757 997

• 34434.7571 1283

• 34434.7572 1034

• 34434.775 594

• 34434.911 55

  • is a DD4hep wf; seems unrelated

[mmusich]

+hlt

[mmusich]

do you have any quantitative impact in terms of HLT timing / throughput when employing the trackingLST modifier in conjuction to this PR? Apologies if I missed it elsewhere.

[slava77]

do you have any quantitative impact in terms of HLT timing / throughput when employing the trackingLST modifier in conjuction to this PR? Apologies if I missed it elsewhere.

is there a way to enable this in the CI/cms-bot so that it shows up in what's the default now in

HLT P2 Timing: chart

?

(timing numbers are easily available for the standalone LST benchmarks timing just the algorithm on offline-like inputs; but it sounds like that's not what's being asked)

[mmusich]

is there a way to enable this in the CI/cms-bot so that it shows up in what's the default now in

at present we cannot select the flavour of the menu (read: process modifiers to use) in the timing tests unless we add one more (ad-hoc) test case in

https://github.com/cms-sw/cmssw/blob/master/HLTrigger/Configuration/python/HLT_75e33/test/runHLTTiming.sh

or we make trackingLST the default (that is an already covered case, that IIUC will at some point become the default).
As a side note: it would be interesting to see if we still fit the memory available in the 2 T4s of the test machine when that happens.
As generally speaking I'd like to reabsorb process modifiers usage in the phase-2 HLT menu, I think supporting a bot runtime configuration might be counterproductive.
Users can still use the same (or similar scripts) privately to produce the same result.

(timing numbers are easily available for the standalone LST benchmarks timing just the algorithm on offline-like inputs; but it sounds like that's not what's being asked)

I guess this would still be better than nothing.

[jfernan2]

+1

[slava77]

(timing numbers are easily available for the standalone LST benchmarks timing just the algorithm on offline-like inputs; but it sounds like that's not what's being asked)

I guess this would still be better than nothing.

• the CPU backend is about 2% slower
• the GPU backend is about 15% slower (an average of two setups with L4 and H100); this counts the kernel times (the fast-timer service piecharts do not count it, IIUC only the CPU side is counted. As long as GPUs are loaded at well below 100% this increase will not affect the throughput).

[slava77]

@cms-sw/dqm-l2
your signature is needed, please check this PR.
Thank you.

[nothingface0]

+dqm

[cmsbuild]

This pull request is fully signed and it will be integrated in one of the next master IBs (tests are also fine). This pull request will now be reviewed by the release team before it's merged. @ftenchini, @sextonkennedy, @mandrenguyen (and backports should be raised in the release meeting by the corresponding L2)

[mandrenguyen]

+1