You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As already pointed out by @cerati in PR #195 , we are unfairly penalizing short tracks by counting the negative hit indices after the last positive hit index on a candidate as missing hits for the score.
In addition, after discussing with @osschar , it turns out we are also incorrectly accounting for missed layers due to a track propagating to outside the sensitive region of the detector that actually can count towards the number of holes when considering stopping a track.
As a reminder:
idx >=0 : valid hit
idx == -1: missed finding a hit on this layer
idx == -2: track is stopped after accumulating too many misses
idx == -3: track propagated to outside of sensitive region of a layer
In principle, hit indices labeled -3 should NOT count towards the number of holes for stopping a track, only -1's. It turns out there is a bug in some cases where it actually does count towards the number of holes and then kills the track (by the simple nature of how we compute invalid hits in MkFinder).
To demonstrate this issue, consider this dump of tracks + hit indices. This list was produced with the first ttbar PU70 event with CE, and setting the number_of_holes to 3 and hit chi2 to 15 using this patch file (via the suggestion of #195).
At track label 90, 91, you can see the track is incorrectly ended with a -2, even though it had only one -1 and two -3s. Then, looking at label 95, things are correct, where three -1's are accumulated, continues, even finds a -3, continues, until it finds another -1 which then swaps to a -2, and ends.
Needed fixes
Proper counter of only -1's (ignore -3's) in a track for stopping it with a -2
Counter of -1's (ignore -3's) WITHIN a track for the score (i.e. -1's up until the last positive index)
The text was updated successfully, but these errors were encountered:
-3 is is actually "missed or grazed sensitive layer" within specified error. If we clearly miss the layer, the hit is not stored. We can fix some of this (not the scoring) by not storing -3 hits (for now).
-3 is is actually "missed or grazed sensitive layer" within specified error. If we clearly miss the layer, the hit is not stored. We can fix some of this (not the scoring) by not storing -3 hits (for now).
Yeah, that is probably a good first "hack" just to see the size of the effect of this problem. A more complete answer can come later.
I believe this issue has been solved by PRs #214 . Although the saga may continue given the report from @osschar and @mmasciov about track cands from short tracks entirely disappearing... Closing for now... will open a separate issue if the latter festers...
As already pointed out by @cerati in PR #195 , we are unfairly penalizing short tracks by counting the negative hit indices after the last positive hit index on a candidate as missing hits for the score.
In addition, after discussing with @osschar , it turns out we are also incorrectly accounting for missed layers due to a track propagating to outside the sensitive region of the detector that actually can count towards the number of holes when considering stopping a track.
As a reminder:
In principle, hit indices labeled -3 should NOT count towards the number of holes for stopping a track, only -1's. It turns out there is a bug in some cases where it actually does count towards the number of holes and then kills the track (by the simple nature of how we compute invalid hits in MkFinder).
Related lines
To demonstrate this issue, consider this dump of tracks + hit indices. This list was produced with the first ttbar PU70 event with CE, and setting the number_of_holes to 3 and hit chi2 to 15 using this patch file (via the suggestion of #195).
At track label 90, 91, you can see the track is incorrectly ended with a -2, even though it had only one -1 and two -3s. Then, looking at label 95, things are correct, where three -1's are accumulated, continues, even finds a -3, continues, until it finds another -1 which then swaps to a -2, and ends.
Needed fixes
The text was updated successfully, but these errors were encountered: