GSI Forum: Bugs, Fixes, Releases » [FIXED] Ideal Tracking Bugs(?) when using FairLinks

Home » PANDA » PandaRoot » Bugs, Fixes, Releases » [FIXED] Ideal Tracking Bugs(?) when using FairLinks

Show: Today's Messages :: Polls :: Message Navigator

[FIXED] Ideal Tracking Bugs(?) when using FairLinks [message #18211]

Tue, 12 May 2015 16:38

André Zambanini
Messages: 17
Registered: February 2012
Location: FZ Jülich

occasional visitor

From: *ext.kfa-juelich.de

Hello everyone,

for my analysis I had a closer look at some events in the eventDisplay and found some strange behavior of the ideal track finding. Basically, I found two problems and my guess is, they are independent of each other, but I'm not sure.

General Information
First, some information beforehand.
FairSoft: mar15
FairRoot: master (fb738d60 from 26.03.2015)
PandaRoot: r27581

I'm simulating events with EvtGen (momentum 4.07 GeV/c) using the decay chain: pbar p -> Xi+ Xi(1690)- -> Lambdabar pi+ Lambda K- and the lambdas decaying to pi p. The main message from the decay for you is that I have a lot of displaced vertices with distances of several centimeters to the IP.

For the reconstruction I'm using ideal track finding, both with the old track finder (PndSttMvdGemTrackingIdeal) and the new one (PndMCIdealTrackFinderNewLinks). The simulation chain uses FairLinks (fRun->SetUseFairLinks(kTRUE) Wink

.

Wrongly Assigned GEM Hits
The first thing Tobias and me noticed were wrongly assigned GEM hits. From what I understood from Tobias and Stefano, this is a known issue. To illustrate this a bit, see these screenshots here:

index.php?t=getfile&id=8385&private=0

Both, the old and the new track finder seem to assign GEM hits which don't belong to the track. The white dots indicate the MC points associated with the selected track - which works fine for MVD (blue squares) and STT (purple) hits, but seems to be off for GEM (red) hits.

Along with this comes wrong track information, as you can see with the red and blue circles, which indicate the first and last track parameters, respectively.

Tobias and me had a closer look at the new track finder and found out, that the spurious hit assignment happens when more than one MC point belong to a hit. The quick fix introduced by us is to simply ignore those hits. This came to the PndMCMatchNewLinks class with r27667 in the trunk.

My conclusion here is, that for now this is okay but maybe someone should have a detailed look at this.

Track Reconstruction with Kalman Task
After resolving the spurious GEM hits, the reconstructed track parameters still looked quite odd. I did some comparison and found out, that in a few cases the Kalman task messes things up, both for genfit 1 and 2. The following screenshots all show the result of the new ideal track finder (PndMCMatchNewLinks):

index.php?t=getfile&id=8386&private=0

For this event, the Kalman filter produces strange tracks, independent of the genfit version. Most other events I had a look at seemed ok with genfit 2, while genfit 1 sometimes causes charge flips for instance (as visible in the screenshot above).
Ideally, I would leave the Kalman filter out, especially because for ideal tracking it seems a bit odd to use it. But this doesn't work for the PID, which seems to require the covariant matrices or something else filled by the Kalman.

So concluding, I have two questions: Any ideas, what could cause the Kalman to produce these results? And secondly, why is it required to have it in the first place, shouldn't ideal PID be based on MC information?

Attachment: GEM_assignment_4_labels.png
(Size: 82.33KB, Downloaded 603 times)
Attachment: GEM_assignment_Ideal_Trackfinder_labels.png
(Size: 85.97KB, Downloaded 597 times)
Attachment: IdealNew_noKalman_labels.png
(Size: 177.98KB, Downloaded 605 times)
Attachment: IdealNew_withKalman_labels.png
(Size: 181.22KB, Downloaded 561 times)
Attachment: IdealNew_withKalman2_labels.png
(Size: 179.68KB, Downloaded 495 times)

[Updated on: Mon, 06 July 2015 14:12]