Sweeping !24469 from 21.2 to 21.0. Protect VKalVrt against negative track covariance
Protect VKalVrt against negative track covariance
See merge request !24469 (merged)
Merge request reports
Activity
added sweep:from 21.2 label
added 21.0 Tracking review-pending-level-1 labels
✅ CI Result SUCCESSAthena AthDataQuality AthSimulation externals ✅ ✅ ✅ cmake ✅ ✅ ✅ make ✅ ✅ ✅ required tests ✅ ✅ ✅ optional tests ✅ ✅ ✅ Full details available at NICOS MR-24475-2019-06-27-05-35
⚠ Athena: number of compilation errors 0, warnings 1
✅ AthDataQuality: number of compilation errors 0, warnings 0
✅ AthSimulation: number of compilation errors 0, warnings 0
📝 For experts only: Jenkins output [CI-MERGE-REQUEST 39702]added review-approved label and removed review-pending-level-1 label
mentioned in commit e1c434cd
added sweep:done label
added sweep:failed label
mentioned in merge request !24468 (merged)
Hi @vkost ,
I'm just checking that this fix is expected to introduce some FT0V changes such as those seen here (the changes are only in the DRAW_RPVLL test). Checking through the changed branches, I think that the main cause of the changes are related to the covariance matrix and the subsequent changes to other branches are caused by that?
Cheers
John
Hi @janders,
Let me summarise as follows. The vertexing code wasn't properly protected against cases when track extrapolator returns covariance matrix with negative eigenvalues. Vertex fit results in this case are unpredictable and non-interpretable. As I've discovered, all cases of FT0V are these. Why 21.0 and 21.2 codes give different results in these cases - I didn't investigate honestly (full machinery uses many different matrices calculated from the track covariances...). I've just introduced a proper protection, so that the vertexing itself becomes correct (more or less).
As negative eigenvalue in track covariance is definitely a symptom of some pathology, most probably the corresponding vertex candidates should have big chi2 and then be rejected in physics selection.
Unfortunately it means that all such vertex candidates obtained with protection are different from themselves obtained without protection. This is clear FT0V, but what I can do?
Cheers, Vadim
mentioned in merge request !24614 (merged)
mentioned in commit d9dd5a6d