Problems with track extension for high pT tracks

[madbaron]

When studying the tracking with a muon gun, I have noticed that high-pT tracks tend to have fewer hits than expected.
This is particularly visible for tracks with pT>250 GeV.

The studies are made with the 10 TeV detector geometry (https://github.com/madbaron/detector-simulation/tree/KITP_10TeV/geometries/MuColl_10TeV_v0A) which differs from MuColl_v1 in the fact that the 3 outermost double layers were removed. (Note: the v1 material map is still used, since I didn't get yet to sort out the hardcoded parts that deal with the decoding of the DD4hep geometry - the assumption being that overestimating the material should not decrease the efficiency)

The figure below shows the number of hits on track on a sample of muon gun events distributed uniformly in pt and theta.
The plot is the sum of 4 slices: (0,50),(50,250),(250,1000), (1000,5000) GeV, with the red highlighting the contribution of tracks with pT>250 GeV

If I restrict myself to just the highest pT slice (1000,5000) GeV, this is what I find as a function of the track theta.

Updating the seeding to include also the first layers of the IT seems to mitigate the issue:

which is however still present.

I am a bit puzzled by the fact that this effect is more prominent for high-pT tracks than for lower pT ones (the 0-50 GeV range is essentially ok).

Below I report my ACTSTracking configuration.

Cheers,
Federico

CKFTracking = MarlinProcessorWrapper("CKFTracking")
CKFTracking.OutputLevel = INFO
CKFTracking.ProcessorType = "ACTSSeededCKFTrackingProc"
CKFTracking.Parameters = {
"CKF_Chi2CutOff": ["10"],
"CKF_NumMeasurementsCutOff": ["1"],
"MatFile": ["/opt/spack/opt/spack/linux-ubuntu22.04-x86_64/gcc-11.3.0/actstracking-1.1.0-cffpaztpv3yiqxvgiregpm6jrfxaa2ij/share/ACTSTracking/data/material-maps.json"],
"PropagateBackward": ["False"],
"RunCKF": ["True"],
"SeedFinding_CollisionRegion": ["5"],
"SeedFinding_DeltaRMax": ["80"],
"SeedFinding_DeltaRMin": ["5"],
"SeedFinding_ImpactMax": ["3"],
"SeedFinding_MinPt": ["500"],
"SeedFinding_RMax": ["150"],
"SeedFinding_RadLengthPerSeed": ["0.1"],
"SeedFinding_SigmaScattering": ["50"],
"SeedingLayers": ["13", "2", "13", "6", "13", "10", "13", "14",
"14", "2", "14", "6", "14", "10", "14", "14",
"15", "2", "15", "6", "15", "10", "15", "14",
"8", "2",
"17", "2",
"18", "2"],
"TGeoFile": ["/opt/spack/opt/spack/linux-ubuntu22.04-x86_64/gcc-11.3.0/actstracking-1.1.0-cffpaztpv3yiqxvgiregpm6jrfxaa2ij/share/ACTSTracking/data/MuColl_v1.root"],
"TrackCollectionName": ["AllTracks"],
"TrackerHitCollectionNames": ["VBTrackerHits", "IBTrackerHits", "OBTrackerHits", "VETrackerHits", "IETrackerHits", "OETrackerHits"]
}

[kkrizka]

@casarsa has also reported the same thing a while back slides for the 3 TeV geometry. I've also managed to reproduce this in my setup as a follow up. It's been on my TODO list for a while to track this down. Also I got a bit distracted by consolidating my and CLIC definition of track reconstruction efficiency.

One thing I did to debug this was trace through the ACTS output as it propagates the CKF for each track. There is a huge jump in the chi0 as you transition between the vertex and inner tacker in the forward direction. So any hits past that transition are considered outliers.

I've played around with the material binning in that region. Hypothesis being that the single bin (current setting) in the r direction was incorrectly propagating nozzle material through the entire end cap. That didn't help. Also I don't think it is consistent with this mostly affecting high pT tracks.

Another thing I tried were different definition of the local coordinate axis. That also didn't have much of an effect.

A few suggestions I had after discussions with Simone:

• Trace a 5 GeV and 10 GeV muon at the same angle through CKF debug output.
• Issues at high pT means that the measurement uncertainty dominates. We should make sure that it is being set correctly (ie: try inflating the IT resolution and see if the chi2 drops).

I'll try to summarize all this in slides after Upgrade Week. Also happy to discuss over Zoom, if useful.