Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug in counting of invalid hits for stopping a track and cand score #196

Closed
kmcdermo opened this issue Dec 12, 2018 · 3 comments
Closed

Comments

@kmcdermo
Copy link
Collaborator

kmcdermo commented Dec 12, 2018

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).

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

  • 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)
@osschar
Copy link
Collaborator

osschar commented Dec 12, 2018

-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).

@kmcdermo
Copy link
Collaborator Author

-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.

@kmcdermo
Copy link
Collaborator Author

kmcdermo commented May 3, 2019

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants