Use transverse width for X-bar containment - #289
Conversation
|
Actually, this pull seems to somehow drop efficiency. While this is being investigated, we should hold off on merging this in. (EDIT: this is also on a single neutrino file, so something has gone wrong deeper than this fix) On this pull Main with the same settings 
|
|
The hough transform is looking for a very thin slice. Using the bar length instead of bar width accidentally made the effective width much larger (> 50x). That gave us a better reco efficiency in the X view because it was more forgiving. Note that the Y view was still constrained to a single bar width, which probably reduced its reco eff compared to X. I've exposed parameters |
Same plot, on the most recent commit. Seems it still needs more investigation.
|
|
I think I understand this issue better. The bug fix itself is fine. But it increases the number of X 2d line candidates. The XY matcher doesn't look for global best matches. Instead, it starts with the longest and tries to match it. With the increased number of candidates, we're getting more and more bad matches. Previously, it would only have one X match to match against all possible Y matches. Or something like that. The solution is a global matcher. So it looks at all possible pairs and finds the best global solution, with the possibility of not matching any. |
|
It has improved, but is still lagging behind main. Seems comparable to my test from the first commit. 
|
|
Okay, it'll lag behind main because main has some improvements on top of it. When we merge, main will retain those improvements so I expect it'll be fine. I'll merge based on this. |
|
These are efficiency plots for the N5p3 sample: 
Post Fix
So about the same, maybe slightly better but hard to distinguish from statistical fluctuations. |
2 participants
The X bar used the wrong transverse width. This caused the hough transform to get very confused. It would add a bunch of extra hits to the candidate. Then it was up to DB scan to fix the issue by making sure what it found was contiguous.
Note that this is only a problem for pileup or busy events. A single muon event should process about the same. But this would lead to different behavior in X and Y views.
See these diagnostic plots using branch
jdkio/266_hough_attempt_diagnostics. In them, we see all hits would be hough seeds (orange circles), rather than only the ones along the line. This would also lead to bad line candidates, which is why the red line is not pointing along the eventual DB scan's hits. The DB scan hits then fix the issue slightly. Those hits are then removed for the next attempt, but I'm not sure that helps much. The Y view wasn't affected, which is how we were able to find the issue.Before
After