| tracks belonging to the same MC truth track [message #17537] |
Tue, 18 November 2014 18:27  |
Gianluigi Boca
Messages: 177
Registered: March 2004
|
first-grade participant |
From: *pv.infn.it
|
|
hi Donghee,
I saw your presentation at the last computing Evo meeting.
Can you please be more specific on the problem you mentioned ? Did you mean that it can happen that more than one RECONSTRUCTED
TRACK can be associated to the SAME MC TRUTH TRACK ?
Gianluigi
|
|
|
|
| Re: tracks belonging to the same MC truth track [message #17538 is a reply to message #17537] |
Tue, 18 November 2014 20:57  |
donghee
Messages: 385
Registered: January 2009
Location: Germnay
|
first-grade participant |
From: *dip0.t-ipconnect.de
|
|
Hi Gianluigi,
Yes exactly, two or sometimes more than two reconstucted tracks are associated to the one MC truth track.
2-3 % of events have such kind of double(or more) tracks effect with oct14 release.
At exclusive analysis, those events doesn't affect too much for the evaluation of efficiency.
If we are doing inclusive analysis, we need to care about those events seriously, otherwise the efficiency could be biased.
How can we avoid this effect when we perform MC truth matching?
Naturally we can have some tracks, which is basically induced same origin, in the track reconstruction.
I do not have clear idea what the best solution is, either a strict clean up in the track reconstruction or specific handling of MC truth matching for such tracks.
Best wishes,
Donghee
|
|
|
|
|
|
| Re: tracks belonging to the same MC truth track [message #17540 is a reply to message #17538] |
Tue, 18 November 2014 21:16 |
Gianluigi Boca
Messages: 177
Registered: March 2004
|
first-grade participant |
From: *pv.infn.it
|
|
Hi,
that is a problem caused by the task that associates the reconstructed track to the MC truth.
I suggested a couple of years ago an algorithm that avoids exactly those situations since it chooses the reconstructed track with the largest number of 'true' hits to be associated with a MC truth track.
That algorithm was not accepted (for very detached vertices like Lambda's it may happen that one track is reconstructed in two pieces, each piece belonging to a different sector of the Stt) but we could use it now except for the Lambda or Ks
case.
On the other hand I would be interested to know how many clones tracks (tracks with essentially the same momentum components)
you have in your channel. Those should be down to a minimum percentage after I eliminated them last August.
In any case, the Task to be modified is the PndMCTrackAssociator task.
Gianlugi
I suggested time ago an associator that avoids that situation
donghee wrote on Tue, 18 November 2014 20:57Hi Gianluigi,
Yes exactly, two or sometimes more than two reconstucted tracks are associated to the one MC truth track.
2-3 % of events have such kind of double(or more) tracks effect with oct14 release.
At exclusive analysis, those events doesn't affect too much for the evaluation of efficiency.
If we are doing inclusive analysis, we need to care about those events seriously, otherwise the efficiency could be biased.
How can we avoid this effect when we perform MC truth matching?
Naturally we can have some tracks, which is basically induced same origin, in the track reconstruction.
I do not have clear idea what the best solution is, either a strict clean up in the track reconstruction or specific handling of MC truth matching for such tracks.
Best wishes,
Donghee
|
|
|
|
|
|
GSI Forum
Search
Help
Members
Login
Home
