Skip to content

Conversation

@bfonta
Copy link
Contributor

@bfonta bfonta commented Jul 3, 2025

Recent developments on extending the CA algorithm for the first three layers of the outer tracker have been rebased onto release 15_1_0_pre4 (technically 15_1_X_2025-06-19-2300). It includes the following developments, in order:

PR validation:

I run the following cmsDriver.py commands for both the branch included in this PR ("pre4") and the same commits rebased onto 15_1_0_pre3 ("pre3"), where I only listed the first file:

NEVENTS=1000
PROCMOD="alpaka" 
function mystep2() {
	cmsDriver.py step2 -s L1P2GT,HLT:NGTScouting,VALIDATION:@hltValidation \
				 --conditions auto:phase2_realistic_T33 \
				 --datatier GEN-SIM-DIGI-RAW,DQMIO \
				 -n ${NEVENTS} \
				 --eventcontent FEVTDEBUGHLT,DQMIO \
				 --geometry ExtendedRun4D110 \
				 --era Phase2C17I13M9 \
				 --procModifier ${PROCMOD} \
				 --filein file:/eos/cms/store/relval/CMSSW_15_1_0_pre3/RelValTTbar_14TeV/GEN-SIM-DIGI-RAW/PU_150X_mcRun4_realistic_v1_STD_Run4D110_PU-v1/2590000//00c675dc-1517-4af7-8dd4-841e0668fefe.root,...
				 --fileout file:step2.root \
				 --nThreads 24 \
				 --process HLTX \
				 --inputCommands='keep *, drop *_hlt*_*_HLT, drop triggerTriggerFilterObjectWithRefs_l1t*_*_HLT'
}

function mystep3() {
	cmsDriver.py step3 -s HARVESTING:@hlt+@hltValidation \
				 --conditions auto:phase2_realistic_T33 \
				 --mc \
				 --geometry ExtendedRun4D110 \
				 --scenario pp \
				 --filetype DQM \
				 --era Phase2C17I13M9 \
				 -n ${NEVENTS}  \
				 --filein file:step2_inDQM.root \
				 --fileout file:step3.root
}

mystep2 && mystep3

The validation plots are available here. As an example:

effic

Note: The efficiency is below what the extension can currently provide since this PR was not included (cut on the transverse impact parameter).

rovere and others added 30 commits June 27, 2025 16:13
Update also the configuration parameters to include the 3 additional
barrel layers from the OT.
Added 6 more double connections.
The index in the SiStipHitSoA to address the proper rotation of the
module is now correctly computed by couting all the preceeding pixel
modules and simply incrementing that number by one, for every new
P-module in the OT barrel.
The code and logic is extremely fragile and relies on a couple of
assumptions:
- all pixel modules will be used in the CA, not matter what.
- the order of modules in Phase2OTRecHitsSoAConverter and in
CAHitNtuplet is the same.
The traits guarding Phase2 and Phase2OT should now be guarded correctly
@cmsbuild
Copy link
Contributor

cmsbuild commented Jul 3, 2025

cms-bot internal usage

@cmsbuild
Copy link
Contributor

cmsbuild commented Jul 3, 2025

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants