Bug #1842
dubious spacepoint finding
0%
Description
The space point finding seems to be generating incorrect doublet space points in some cases.
I have attached an example plot, the blue dots are points on a track and the red dots are not on a track. If the dot is filled it is a triplet and if it is not filled then it is a doublet.
The formatting of the details is as follows:
SP: x(mm),y(mm)
+ C: plane channel is_used npe
Tracker:1, Station:2
SP: 27.077350, -147.853421
+ C: 0 201.0 True 2.46755852843
+ C: 2 87.0 True 9.06126914661
UNASSIGNED:
+ C: 1 110.0 False 9.64406779661
As you can see the combination was done incorrectly and the one real hit was combined with a noise hit, followed by another real hit being unassigned to a space point.
Files
Updated by Overton, Edward about 7 years ago
I should add that this a notable but not massive effect. The number of adversely effected events is definitely less than 7%, and probably about 3.5%.
Updated by Overton, Edward about 7 years ago
- File doublet_npe.cpp doublet_npe.cpp added
I wrote a new doublet finding algorithm for MAUS, which sorts by npe and improves things.
Using the bin/user/scifi/efficiency.py code:
File #_Recon_Events TkUS_5pt TkUS_3-5_pt TkDS_5pt TkDS_3-5pt
07691_new.root 70676 0.98274 1.00000 0.91512 0.99751
07691_orig.root 70676 0.95301 1.00000 0.90299 0.99733
As you can see the upstream 5pt efficiency is increased by 3% and the downstream is 1.3%.
Updated by Dobbs, Adam about 7 years ago
Good work Ed. Could this lead to one transverse coordinate for a spacepoint being wrong, the other being correct (an effect I have been wondering about)?
Updated by Overton, Edward about 7 years ago
It leads to that exactly. The x coordinate is normally correct, but y is very wrong.
Updated by Dobbs, Adam about 6 years ago
- Assignee changed from Dobbs, Adam to Kyberd, Paul
Hi All, does anyone know if this is still an issue?