Tracking issue for displaced tracks and electron reconstruction efficiency

[gaswk]

After investigating the tracking issue, adjusting the parameters MaxCellAngle and MaxCellAngleRZto 0.5 (as opposed to 0.1), in the displaced step, has significantly enhanced the reconstruction of displaced tracks (tested with displaced single particle). These conditions were frequently not met, leading to track not being reconstructed. The choice of the 0.5 value was somewhat arbitrary, and further optimisation is required.

However, despite this adjustment, an issue persists in properly reconstructing the Heavy Neutral Lepton (HNL) vertex with electron tracks. Interestingly, when considering all tracks in the event, the HNL vertex reconstruction aligns better with the expected distribution. What factors could be contributing to the reconstruction efficiency of electron?

1- Reconstructed vertex displacement (normalised to 1)

2- Comparison of Generated and reconstructed vertex displacement for MaxCellAngle, MaxCellAngleRZ = 0.5, left reconstructed with electrons tracks and right with all tracks in the event

3- Comparison of Generated and reconstructed vertex displacement MaxCellAngle, MaxCellAngleRZ = 0.1, left reconstructed with electrons tracks and right with all tracks in the event

[Zehvogel]

Hi Galle,

very interesting results! Can you also check how the change of this criterion affects the track finding efficiency and the fake rate? It is a bit hard to judge from your plots if the distribution is different because the tracks are missing or because the tracks are reconstructed incorrectly. In the longer run we should probably collect a set of tracking performance plot scripts that we can put into a CI workflow...

Regarding the electrons: there are also some issues reconstructing prompt electrons that I noticed recently I hoped that this can be fixed by relaxing another cut somewhere, but I had no time to investigate yet.

[gaswk]

I gave you access to the aida files, with both values of MaxCellAngle. I think tracks were not correctly reconstructed. Both files are for 500mm displayed muons

/eos/user/g/gasadows/Output/TrackingPerformance/testREC_500mm_MCA01_aida.root

/eos/user/g/gasadows/Output/TrackingPerformance/testREC_500mm_MCA05_aida.root

[Zehvogel]

Yes, as far as I can see from the files (MyClicEfficiencyCalculator/simplifiedEfficiencyTree/m_reconstructed) the issue seems to be that the tracks are not reconstructed at all.

In the 0.1 case its only 6/87 tracks and in the 0.5 case it is 37/87

I am a bit surprised by the uneven number of 87 but I think this includes being in the detector acceptance and maybe one of the particles goes down the beamline...

I would still like to check how this change influences the fake rate of tracking in more busy events before making this the new default but that will still take me a while.

[gaswk]

While investigating Pandora particles, mainly photons instead of electrons, tracks are not consistently associated with clusters. A comparison of track positions at calo and cluster positions reveals a mismatch.

[andresailer]

Hi @gaswk

Can you plot the 3D distance between tracks and clusters? Maybe even split between tracks and clusters that were matched and unmatched clusters and tracks? The track position is at the calo front face surface, and the cluster in the calorimeter, so some distance is expected.

[gaswk]

Here is DeltaR and DeltaD for tracks and clusters position

[andresailer]

Thanks!

What is DeltaD? And DeltaR is the difference in radius between trackState and cluster, or cluster and trackstate?

[gaswk]

D = sqrt(X^2 + Y^2 + Z^2) Both are differences between cluster and trackstate (Delta = cluster - tracktate)

[andresailer]

It is DeltaD = sqrt(Sum_i (X_c^i-X_t^i)^2)) ? How can it be negative?

[gaswk]

DeltaD = D_cluster - D_trackstate

[andresailer]

That is not the 3D distance though. So if you could plot the DeltaD as I defined above?

[gaswk]

Here is the Delta3D distribution for matched and not matched electrons

[andresailer]

Thanks for the plot @gaswk ! There is not really any difference between the distribution, so the issue is probably elsewhere.