refactor!: Packed strip space point calibration column

[andiwand]

--- END COMMIT MESSAGE ---

blocked by

• feat: Provide access to tangents from seed estimation function #5437
• feat: Elevate strip space point calibration to public API #5444
• fix: Set strip half length vector in SpacePointMaker #5445
• refactor: Revise track parameter estimation implementation #5436

cc @mvessell96

[github-actions]

📊: Physics performance monitoring for e458cf3

Full contents

physmon summary

• ✅ Particles fatras
• ✅ Particles geant4
• ✅ Particles ttbar
• ✅ Vertices ttbar
• ✅ Truth tracking (KF)
• ✅ Truth tracking (GSF)
• ✅ Truth tracking (GX2F)
• ✅ Truth tracking (KF refit)
• ✅ Truth tracking (GSF refit)
• ✅ CKF finding performance | trackfinding | single muon | truth smeared seeding
• ✅ CKF fitting performance | trackfinding | single muon | truth smeared seeding
• ✅ CKF track summary | trackfinding | single muon | truth smeared seeding
• ✅ Seeding trackfinding | single muon | truth estimated seeding
• ✅ CKF finding performance | trackfinding | single muon | truth estimated seeding
• ✅ CKF fitting performance | trackfinding | single muon | truth estimated seeding
• ✅ CKF track summary | trackfinding | single muon | truth estimated seeding
• ✅ Seeding trackfinding | single muon | default seeding
• ✅ CKF finding performance | trackfinding | single muon | default seeding
• ✅ CKF fitting performance | trackfinding | single muon | default seeding
• ✅ CKF track summary | trackfinding | single muon | default seeding
• ✅ Seeding trackfinding | single muon | orthogonal seeding
• ✅ CKF finding performance | trackfinding | single muon | orthogonal seeding
• ✅ CKF fitting performance | trackfinding | single muon | orthogonal seeding
• ✅ CKF track summary | trackfinding | single muon | orthogonal seeding
• ✅ Seeding trackfinding | 4 muon x 50 vertices | default seeding
• ✅ CKF finding performance | trackfinding | 4 muon x 50 vertices | default seeding
• ✅ CKF fitting performance | trackfinding | 4 muon x 50 vertices | default seeding
• ✅ CKF track summary | trackfinding | 4 muon x 50 vertices | default seeding
• ✅ Ambisolver finding performance | trackfinding | 4 muon x 50 vertices | default seeding
• ✅ IVF notime | trackfinding | 4 muon x 50 vertices | default seeding
• ✅ AMVF gauss notime | trackfinding | 4 muon x 50 vertices | default seeding
• ✅ AMVF grid time | trackfinding | 4 muon x 50 vertices | default seeding
• ✅ Seeding trackfinding | ttbar with 200 pileup | default seeding
• ✅ CKF finding performance | trackfinding | ttbar with 200 pileup | default seeding
• ✅ CKF fitting performance | trackfinding | ttbar with 200 pileup | default seeding
• ✅ CKF track summary | trackfinding | ttbar with 200 pileup | default seeding
• ✅ Ambisolver finding performance | trackfinding | ttbar with 200 pileup | default seeding
• ✅ ML Ambisolver | trackfinding | ttbar with 200 pileup | default seeding
• ✅ AMVF gauss notime | trackfinding | ttbar with 200 pileup | default seeding
• ✅ AMVF grid time | trackfinding | ttbar with 200 pileup | default seeding
• 🔵️ Comparison - Truth tracking (GX2F vs KF)

[andiwand]

Elevates the pre-computable strip space point information out of the seeding code. This way the computation only needs to happen once, but the user is now responsible for the computation. Therefore this is a breaking change.

Also allows to deduplicate the stripCoordinateCheck again. In a followup PR I plan to elevate this this function and rename it to something like stripSpacePointCalibration to make it useable in the parameter estimation.

To be seen what performance difference this makes for ITk strip seeding

After fighting the performance I get a marginal 2% improvement in Athena with the SPOT script. I am back to two functions again but elevated them now to public functions in Core/SpacePointerFormation2/StripSpacePointBuilder.hpp.

With the single function and the 5 calibration vectors attached to the space point I saw about ~10% slowdown. My interpretation is that all of these are in the cache and loading them from there is slower than recalculating them from 4 calibration vectors. I think this will highly depend on the CPU and scenario but lets not go down that road.

I also experimented with using Eigen to various degrees but the more we use it the more it slows down...

What is left from this is mainly a refactor and some breaking renames that I believe overall improve things. Next I would explore a bit how to best estimate the seed params using the calibration.

[andiwand]

A few things I was not sure about while trying to understand the code

[mvessell96]

Elevates the pre-computable strip space point information out of the seeding code. This way the computation only needs to happen once, but the user is now responsible for the computation. Therefore this is a breaking change.
Also allows to deduplicate the stripCoordinateCheck again. In a followup PR I plan to elevate this this function and rename it to something like stripSpacePointCalibration to make it useable in the parameter estimation.
To be seen what performance difference this makes for ITk strip seeding

After fighting the performance I get a marginal 2% improvement in Athena with the SPOT script. I am back to two functions again but elevated them now to public functions in Core/SpacePointerFormation2/StripSpacePointBuilder.hpp.

With the single function and the 5 calibration vectors attached to the space point I saw about ~10% slowdown. My interpretation is that all of these are in the cache and loading them from there is slower than recalculating them from 4 calibration vectors. I think this will highly depend on the CPU and scenario but lets not go down that road.

I also experimented with using Eigen to various degrees but the more we use it the more it slows down...

What is left from this is mainly a refactor and some breaking renames that I believe overall improve things. Next I would explore a bit how to best estimate the seed params using the calibration.

Yes I tried something similar (ok but much less elegant) originally and also came to the conclusion that loading from cache was slower than recalculating them but also was not sure how much this result could be trusted for the same CPU/scenario reason so left it unmentioned ;) This is ultimately why I settled on the messy two function solution which I wasn't exactly happy with but was the fastest implementation out of the stuff I threw at the wall

[andiwand]

I also tried using only the function with the pre-calculated struct and it seems to produce the same timing. Maybe we can deduplicate to this variant? Or did it behave differently for you?

There are a few things I was not sure about and left a few comments above, maybe you have an opinion on these @mvessell96.

If we could reduce the information necessary for the calibration it might go faster but I didn't have a great idea about it.

[mvessell96]

I also tried using only the function with the pre-calculated struct and it seems to produce the same timing. Maybe we can deduplicate to this variant? Or did it behave differently for you?

There are a few things I was not sure about and left a few comments above, maybe you have an opinion on these @mvessell96.

If we could reduce the information necessary for the calibration it might go faster but I didn't have a great idea about it.

I think it gave like O(5-8%) which was a much bigger number when I put this in, I think likely some of the other recent improvements have eaten most of the gain? Since we are likely getting to the bad top sps less often

[andiwand]

Ok good to know! Then lets just keep it - doesn't hurt

[andiwand]

I coded up a little toy visualization and the current implementation looks indeed correct https://github.com/andiwand/cern-scripts/blob/main/scripts/2026-05-10_strip-space-point-calibration.py

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
11.5% Duplication on New Code

See analysis details on SonarQube Cloud

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
11.5% Duplication on New Code

See analysis details on SonarQube Cloud