KalmanFilter error: No measurement detected during the propagation

[CarloVarni]

When running KF refitting on a tt-bar sample with pile-up (mu 200), ACTS reports the following error message:

ActsReFitterAlg.ActsKalmanFitter.Acts Kalman Refit  ERROR KalmanFilter failed: KalmanFitterError:5, No measurement detected during the propagation

This fit failure comes from https://github.com/acts-project/acts/blob/main/Core/include/Acts/TrackFitting/KalmanFitter.hpp#L1056 in which the KF tries to refit a fitted track and doesn’t find a single measurement. Despite being a fit failure, should this result in an error message in the KF itself?

This has been observed when running the ActsReFitterAlg algorithm in Athena, and does not happen for a single mu input sample. The presence of an ERROR message will mark the algorithm execution as a failure, thus preventing its use in a CI test.

[stale[bot]]

This issue/PR has been automatically marked as stale because it has not had recent activity. The stale label will be removed if any interaction occurs.

[paulgessinger]

This was recently observed again in https://gitlab.cern.ch/atlas/athena/-/merge_requests/59359

[paulgessinger]

I investigated a bit, and this looks like another case of a navigation failure. From the RDO file that has 5 events, I believe it's these cases that error out:

Seems to me like they start out very forward and then fail to reach the beampipe cylinder boundary. The navigation then runs into infinity, which the KF interprets as not having found any measurements. In 5 cases the trajectory somehow bends in the longitudinal plane (how?).

[paulgessinger]

In some cases, the propagation also turns around like this:

@noemina @andiwand could this be related to the error you were observing with boundaries?

[paulgessinger]

It seems like we slightly overstep in these cases, but beyond the overstep-limit. I see cases like this:

RAWtoALL 14:18:32 ActsReFitterAlg.ActsKalmanFitter.Acts Kalman RefitVERBOSE Check intersection with surface vol=8|bnd=4
RAWtoALL 14:18:32 ActsReFitterAlg.ActsKalmanFitter.Acts Kalman RefitVERBOSE  -> pLimit, oLimit, cLimit: 28874, -0.1, -0.102747
RAWtoALL 14:18:32 ActsReFitterAlg.ActsKalmanFitter.Acts Kalman RefitVERBOSE Intersection is OUTSIDE limit because:
RAWtoALL 14:18:32 ActsReFitterAlg.ActsKalmanFitter.Acts Kalman RefitVERBOSE - intersection path length -0.102747 <= overstep limit -0.1
...
RAWtoALL 14:19:31 ActsReFitterAlg.ActsKalmanFitter.Acts Kalman RefitVERBOSE Check intersection with surface vol=8|bnd=4
RAWtoALL 14:19:31 ActsReFitterAlg.ActsKalmanFitter.Acts Kalman RefitVERBOSE  -> pLimit, oLimit, cLimit: 30127.6, -0.1, -0.192962
RAWtoALL 14:19:31 ActsReFitterAlg.ActsKalmanFitter.Acts Kalman RefitVERBOSE Intersection is OUTSIDE limit because:
RAWtoALL 14:19:31 ActsReFitterAlg.ActsKalmanFitter.Acts Kalman RefitVERBOSE - intersection path length -0.192962 <= overstep limit -0.1
...
RAWtoALL 14:19:48 ActsReFitterAlg.ActsKalmanFitter.Acts Kalman RefitVERBOSE Check intersection with surface vol=8|bnd=4
RAWtoALL 14:19:48 ActsReFitterAlg.ActsKalmanFitter.Acts Kalman RefitVERBOSE  -> pLimit, oLimit, cLimit: 42217.2, -0.1, -0.139699
RAWtoALL 14:19:48 ActsReFitterAlg.ActsKalmanFitter.Acts Kalman RefitVERBOSE Intersection is OUTSIDE limit because:
RAWtoALL 14:19:48 ActsReFitterAlg.ActsKalmanFitter.Acts Kalman RefitVERBOSE - intersection path length -0.139699 <= overstep limit -0.1

[noemina]

Yes, it might be related to it. Have you already tried with including https://github.com/acts-project/acts/pull/1722 in ACTS? Can you tell me how to reproduce this?

[paulgessinger]

@noemina: this should be enough to reproduce: https://gitlab.cern.ch/atlas/athena/-/blob/master/AtlasTest/CITest/test/ActsKfRefitting.sh

[noemina]

Thank you @paulgessinger . I can reproduce the issue and it is not fixed by https://github.com/acts-project/acts/pull/1722. I am starting investigating this.

[noemina]

It might be because we have no material loaded on the tracking geometry at the time being... I will confirm this asap.

[stale[bot]]

This issue/PR has been automatically marked as stale because it has not had recent activity. The stale label will be removed if any interaction occurs.

[paulgessinger]

Sort of solved via configurable overstep limit. Closing for now.