Project

General

Profile

Bug #1842

dubious spacepoint finding

Added by Overton, Edward over 7 years ago. Updated over 6 years ago.

Status:
Open
Priority:
Normal
Assignee:
Kyberd, Paul
Category:
Tracker
Target version:
-
Start date:
22 April 2016
Due date:
% Done:

0%

Estimated time:
Workflow:
New Issue

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

Screenshot_from_2016-04-22_13-50-58.png (8.33 KB) Screenshot_from_2016-04-22_13-50-58.png Overton, Edward, 22 April 2016 14:02
doublet_npe.cpp (2.02 KB) doublet_npe.cpp Doublet Recon code based on NPE Overton, Edward, 25 April 2016 13:14
#1

Updated by Overton, Edward over 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%.

#2

Updated by Overton, Edward over 7 years ago

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

#3

Updated by Dobbs, Adam over 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)?

#4

Updated by Overton, Edward over 7 years ago

It leads to that exactly. The x coordinate is normally correct, but y is very wrong.

#5

Updated by Dobbs, Adam over 6 years ago

  • Assignee changed from Dobbs, Adam to Kyberd, Paul

Hi All, does anyone know if this is still an issue?

Also available in: Atom PDF