GSI Forum
GSI Helmholtzzentrum für Schwerionenforschung

Home » PANDA » PandaRoot » Tracking » Start and stop values from PndRecoKalmanTask
Start and stop values from PndRecoKalmanTask [message #15197] Tue, 13 August 2013 16:00 Go to next message
Simone Esch is currently offline  Simone Esch
Messages: 37
Registered: August 2010
Location: Forschungszentrum Jülich...
continuous participant

From: *ext.kfa-juelich.de
Hello Pandas!

I have and Issue concerning the PndRecoKalmanTask.

I am using modified version of Ralfs PndSttMvdGemIdealTrackFinder to find my tracks. The ideal track finder gives start and stop vectors to the track which are located at the first and last hit of the track. This I checked with the event display for several events.

After the PndRecoKalmanTask fitted the tracks, for ~25% of the tracks are the start vectors strange.
Strange means, that they are close to the stop vectors (sometimes identical with the stop vectors) and far at the end of the track, despit the fact that there are several points before (For example they are located at a GEM point, but there are several STT or MVD points, see picture).

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

This far away start vectors make strange results in my analysis (Poca is way to big, inv. masses are to big..)

Any idea what could cause this or (my favorite Smile ) what could solve this?

Best regards

Simone
Re: Start and stop values from PndRecoKalmanTask [message #15198 is a reply to message #15197] Tue, 13 August 2013 16:31 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: 2.235.190*
In reality we have seen some strange thing like this together with Lia, where fome some tracks the difference between the first and the final momentun is very large or also negative.
We believe there is something weird in genfit, but up to now we were not able to udnerstand what is going wrong.

However, you could try to do add the following line in the kalman part:

kalmanttask->SetPropagateToIP(kFALSE);


In this way it neglects the backpropagation from the first hit to the interaction point, which is dangerous in the case the particles are emitted "far" from the IP.
Just to take out this possible noise source.

Question: have you selected ony the fitted tracks? The non fitted tracks (flag<=0) should be bad.

The other point could be that inside the trackcand the hits are not well sorted. I admit I never checked the ideal mvdsttgem trackcand, but this is easy to check.
Re: Start and stop values from PndRecoKalmanTask [message #15199 is a reply to message #15198] Tue, 13 August 2013 16:53 Go to previous messageGo to next message
Simone Esch is currently offline  Simone Esch
Messages: 37
Registered: August 2010
Location: Forschungszentrum Jülich...
continuous participant

From: *ext.kfa-juelich.de
Hello Stefano

i feared such an answer :-/

I will try the ip-propagation setting.

No, I didnt select for the fit status. Since I was choosing track with a lot of this, I thought this should have went fine. I will check if and how much tracks with Flag<=0 I have.

I checked the sorting if the hits in the track finder, and its look reasonable for me.
The start vectors are also always at the first hit, as they should be (see picture).
index.php?t=getfile&id=7507&private=0

I will report from my results

Best Regards

Simone
Re: Start and stop values from PndRecoKalmanTask [message #15214 is a reply to message #15198] Thu, 15 August 2013 09:13 Go to previous messageGo to next message
Simone Esch is currently offline  Simone Esch
Messages: 37
Registered: August 2010
Location: Forschungszentrum Jülich...
continuous participant

From: *ext.kfa-juelich.de
Hello Stefano,

I checked the flag of my tracks.
18% of the tracks have the flag -1, which means that the NDF is zero, or that the transformation of a GeneFitTrack into a PndTrack failed.
( https://subversion.gsi.de/trac/fairroot/browser/pandaroot/trunk/GenfitTo ols/adapters/PndGenfitAdapters.cxx , around line 111)
The rest of the tracks have flag 1.

When I have a look at the tracks with Flag -1 I would say that the biggest amount of them is with this late start vector, but there is also an amount with I would judge as ok.
If i filter them out, I have still a big amount of tracks with a strange start value. So this is not a criteria for this Sad.

What is the reason to get a fit with a NDF=0? What is in this case wrong with the fit? Should I filter them out?

Best Regards

Simone
Re: Start and stop values from PndRecoKalmanTask [message #15215 is a reply to message #15214] Thu, 15 August 2013 11:03 Go to previous message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: 2.235.190*
In the case the flag is not 1, the "fitted" PndTrack will have the parameters of the "prefit" PndTrack since the fit or somethign else has failed... Gianluigi's code or in your case the smearing you put in the ideal track finder. In this sense, those tracks should be removed ( PndPidCandidate::GetFitStatus()>0 are the good tracks) since they cannot be used.
The reason... the NDF==0 comes from genfit itself, the missed conversion between GFTrack and PndTrack... if you read the adapter it is coming from an exception of this code:

first_pro = gtr->getMom(firstPlane).Dot(firstPlane.getNormal());
last_pro = gtr->getMom(lastPlane).Dot(lastPlane.getNormal());


Again, this is internal to genfit. No idea what is wrong there.
Our genfit version is "old", of 2011, they said a new revision should come this summer, and we should move to such new code... but still I did not read about any news in their mailing list. Maybe some bugs are fixed, maybe not.

The fact that flag>0 does not solve completely the situation was seen also by me and Lia, but for sure it is not "safe" to use tracks with flag <=0.

I suspect genfit developers are not reading our forum anymore.
Previous Topic: new version of the offline Pattern Recognition
Next Topic: Test of kinematic/vertex fitters
Goto Forum:
  


Current Time: Mon Jul 04 15:00:57 CEST 2022

Total time taken to generate the page: 0.00933 seconds