Home » PANDA » PandaRoot » Bugs, Fixes, Releases » Bug in GenfitTrack2PndTrack
| Bug in GenfitTrack2PndTrack [message #9262] |
Mon, 31 August 2009 14:19  |
StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
|
first-grade participant |
From: *to.infn.it
|
|
Hello,
playing with kalman I have found there is a small bug in the converter from genfit Track to PndTrack. I am converting Track to PndTrack with the following code in PndLheKalmanTask:
Track *trk;
...
...
cout << "Trk fin:" << endl;
trk->getMom().Print();
PndTrack *fitTrack = (PndTrack*)GenfitTrack2PndTrack(trk);
cout << "pndtrk fin:" << endl;
fitTrack->GetParamFirst().GetMomentum().Print();
Once I plot the momentum value before and after the conversion, I have (for different events):
Toggle Spoiler
Trk fin:
TVector3 A 3D physics vector (x,y,z)=(1.373069,0.210701,1.478064) (rho,theta,phi)=(2.028395,43.223627,8.724142)
pndtrk fin:
TVector3 A 3D physics vector (x,y,z)=(1.373069,0.210701,1.478064) (rho,theta,phi)=(2.028395,43.223627,8.724142)
Trk fin:
TVector3 A 3D physics vector (x,y,z)=(-0.780230,1.078801,1.491037) (rho,theta,phi)=(1.998940,41.762353,125.875875)
pndtrk fin:
TVector3 A 3D physics vector (x,y,z)=(0.780230,-1.078801,-1.491037) (rho,theta,phi)=(1.998940,138.237647,-54.124125)
Trk fin:
TVector3 A 3D physics vector (x,y,z)=(-1.743418,-0.130269,1.215589) (rho,theta,phi)=(2.129350,55.188850,-175.726788)
pndtrk fin:
TVector3 A 3D physics vector (x,y,z)=(1.743418,0.130269,-1.215589) (rho,theta,phi)=(2.129350,124.811150,4.273212)
Trk fin:
TVector3 A 3D physics vector (x,y,z)=(1.259328,-1.327701,0.748083) (rho,theta,phi)=(1.976948,67.765194,-46.513927)
pndtrk fin:
TVector3 A 3D physics vector (x,y,z)=(1.259328,-1.327701,0.748083) (rho,theta,phi)=(1.976948,67.765194,-46.513927)
Trk fin:
TVector3 A 3D physics vector (x,y,z)=(-0.233548,-1.536000,1.323097) (rho,theta,phi)=(2.040693,49.582170,-98.645565)
pndtrk fin:
TVector3 A 3D physics vector (x,y,z)=(0.233548,1.536000,-1.323097) (rho,theta,phi)=(2.040693,130.417830,81.354435)
Trk fin:
TVector3 A 3D physics vector (x,y,z)=(1.221191,1.319585,-0.811028) (rho,theta,phi)=(1.972404,114.279440,47.217711)
pndtrk fin:
TVector3 A 3D physics vector (x,y,z)=(1.221191,1.319585,-0.811028) (rho,theta,phi)=(1.972404,114.279440,47.217711)
Trk fin:
TVector3 A 3D physics vector (x,y,z)=(-1.651799,0.864065,0.744961) (rho,theta,phi)=(2.007490,68.217108,152.385683)
pndtrk fin:
TVector3 A 3D physics vector (x,y,z)=(1.651799,-0.864065,-0.744961) (rho,theta,phi)=(2.007490,111.782892,-27.614317)
Trk fin:
TVector3 A 3D physics vector (x,y,z)=(1.753957,0.354045,0.912949) (rho,theta,phi)=(2.008778,62.968538,11.412095)
pndtrk fin:
TVector3 A 3D physics vector (x,y,z)=(1.753957,0.354045,0.912949) (rho,theta,phi)=(2.008778,62.968538,11.412095)
(the numbers taken from muons at 2 GeV, 5° < theta < 140°).
You can see in red that during the conversion, for some tracks, theta -> 180° - theta, phi -> +-(180° - phi).
It seems that during the conversion the direction of the track is somehow inverted, and this screws up the outgoing momentum (I have not checked the other parameters).
Would it be possible to fix it? Of course even the correlation to the other detectors is completely screwed up.
|
|
|
|
|
|
| Re: Bug in GenfitTrack2PndTrack [message #9285 is a reply to message #9279] |
Wed, 02 September 2009 12:11  |
Lia Lavezzi
Messages: 291
Registered: May 2007
Location: Torino
|
first-grade participant |
From: *pv.infn.it
|
|
Hi Stefano,
I had a look to the problem and I think the "spu" information is missing in the conversion.
If you add in GeaneTrackRep.h a function:
double getSPU() {return _spu;}
to retrieve it, and in PndGenfitAdapter.cxx you add:
double spu = gtr->getSPU();
and use:
FairTrackParP first(firstState[3][0],firstState[4][0],firstState[1][0],firstState[2][0 ],firstState[0][0],firstCova,firstPlane.getO(),firstPlane.getU(),firstPl ane.getV(),spu);
FairTrackParP last(lastState[3][0],lastState[4][0],lastState[1][0],lastState[2][0],las tState[0][0],lastCova,lastPlane.getO(),lastPlane.getU(),lastPlane.getV() ,spu);
instead of using just:
FairTrackParP first(firstState[3][0],firstState[4][0],firstState[1][0],firstState[2][0 ],firstState[0][0],firstCova,firstPlane.getO(),firstPlane.getU(),firstPl ane.getV());
FairTrackParP last(lastState[3][0],lastState[4][0],lastState[1][0],lastState[2][0],las tState[0][0],lastCova,lastPlane.getO(),lastPlane.getU(),lastPlane.getV() );
to use spu during the conversion, the problem should be fixed.
Can you please test it and tell me if it is ok?
Ciao,
Lia.
|
|
|
|
| Re: Bug in GenfitTrack2PndTrack [message #9286 is a reply to message #9285] |
Wed, 02 September 2009 14:45 |
|
Anonymous Poster
|
|
From: *e18.physik.tu-muenchen.de
|
|
Hi,
sorry for not replying until now. I was on vacation. Lia, I think that your idea is exactly right. Could I suggest that you maybe do the fix? If this is a problem, just let me know and I will do it. But it is nice if other people get there hand in the code and the svn log....
Cheers, Christian
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Bug in GenfitTrack2PndTrack [message #9299 is a reply to message #9296] |
Thu, 03 September 2009 13:11 |
Lia Lavezzi
Messages: 291
Registered: May 2007
Location: Torino
|
first-grade participant |
From: *pv.infn.it
|
|
Hi,
I just uploaded some last changes. The SPU is no more obtained via getSPU, but it is calculated by hand in the first and last point of the track. Previously, using getSPU, the same SPU value was used in the two cases and this was the main reason why the first point was ok, while the second one not.
There is still a problem, however, with the last point: the signs of the momentum components are correct, but there is a very small difference in their value before and after the conversion.
Consider this case as an example:
first hit before conversion:(-0.279309,0.949132,-0.098875)
first hit after conversion: (-0.279309,0.949132,-0.098875)
last hit before conversion:(-0.428044,0.887351,-0.098413)
last hit after conversion: (-0.427660,0.892086,-0.100010)
You can see that for the first hit everything is ok, while for the last the small difference is still there (though the signs are correct).
I am still studying the problem.
Stefano, can you please make your tests on theta and phi with this last change to see if there is an improvement with respect to the last results?
Thanks, ciao,
Lia.
|
|
|
|
| Re: Bug in GenfitTrack2PndTrack [message #9307 is a reply to message #9299] |
Thu, 03 September 2009 15:28 |
StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
|
first-grade participant |
From: *to.infn.it
|
|
Hi,
I am not so sure if theta and phi are fine...
BUT
now I have the following error which stops the analysis, after some events:
*** Event # 427
===== PndLheHitsMaker =====
Total number of hits for tracking: 82
Total number of tracks in TPC: 1
Good tracks in TPC: 1
Working with 82 hits
found 2 tracks
finder : Real Time = 119.42 seconds Cpu Time = 98.89 seconds
===== PndLheTrackFitter =====
Number of tracks for fitting 2
Error: Symbol G__exception is not defined in current scope run_reco_tpccombi.C:79:
Error: type G__exception not defined FILE:/home/spataro/july09/pandaroot/macro/pid/./run_reco_tpccombi.C LINE:79
This come from the following line:
double last_pro = gtr->getMom(lastPlane).Dot(lastPlane.getNormal());
In particular from:
(gtr->getMom(lastPlane).Print() gave me the same message).
I have done a lastPlane.Print(), this is the output:
DetPlane: O(-4.400,3.217,7.140) u(0.000,1.000,0.000) v(1.000,-0.000,0.000) n(0.000,0.000,-1.000)
and gtr->Print():
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
AbsTrackRep::Parameters at reference plane DetPlane: O(-2.430,-0.5800,2.370) u(0.000,-1.000,0.000) v(-1.000,0.000,0.000) n(-0.000,-0.000,-1.000)
AbsTrackRep::State
5x1 matrix is as follows
| 0 |
------------------
0 | 10.19
1 | 0.2318
2 | -0.5959
3 | -1.219
4 | -0.9614
AbsTrackRep::Covariances
5x5 matrix is as follows
| 0 | 1 | 2 | 3 | 4 |
----------------------------------------------------------------------
0 | 1.427 -0.004631 -0.003401 -0.001314 -0.000963
1 | -0.004631 0.0001002 -2.511e-06 1.756e-05 2.866e-06
2 | -0.003401 -2.511e-06 0.0001009 3.542e-06 1.546e-05
3 | -0.001314 1.756e-05 3.542e-06 2.398e-05 6.665e-07
4 | -0.000963 2.866e-06 1.546e-05 6.665e-07 2.353e-05
AbsTrackRep::chi^2
230.8
Any clues?
[Updated on: Thu, 03 September 2009 15:35] Report message to a moderator |
|
|
|
|
|
|
|
|
|
| Re: Bug in GenfitTrack2PndTrack [message #9315 is a reply to message #9299] |
Thu, 03 September 2009 16:51 |
Lia Lavezzi
Messages: 291
Registered: May 2007
Location: Torino
|
first-grade participant |
From: *47-151.net24.it
|
|
Hi,
I think the reason of the strange behaviour for the last point is the following: we have two different results depending on how we retrieve the momentum on the last plane:
(i) the first way is:
gtr->getMom(lastPlane).Print();
(ii) the second one is to calculate the momentum starting from lastState and lastPlane, by:
TVector3 mom_cal = last_spu*lastPlane.getNormal()
+ last_spu*lastState[1][0]*lastPlane.getU()
+ last_spu*lastState[2][0]*lastPlane.getV();
mom_cal.SetMag(1./fabs(lastState[0][0]));
mom_cal.Print();
When doing the conversion Track -> PndTrack, the output PndTrack is constructed starting from lastPlane, lastState and lastCov, so the momentum is equal (exactly equal) to the one calculated in (ii), and not (i).
The difference between the results in (i) and (ii) is that in (i) the momentum on the last plane is obtained starting from the information on the first plane (after the whole Kalman), extrapolating the track to the last one in order to obtain a statePred and calculating the momentum from it; in case (ii) the momentum is calculated, without extrapolation, directly from lastState (the state on last plane which has been saved during the Kalman procedure, before the last backtracking (right?)): these two states are in general different.
I' d like to ask for some opinion about this: wouln' t it be better to fill the last point state or covariance with the value of the track extrapolated to the last plane after the whole Kalman procedure has ended? In this way the momentum calculated in both (i) and (ii) would be the same.
Ciao,
Lia.
|
|
|
|
|
|
| Re: Bug in GenfitTrack2PndTrack [message #9317 is a reply to message #9314] |
Thu, 03 September 2009 17:08 |
|
Anonymous Poster
|
|
From: *e18.physik.tu-muenchen.de
|
|
Hi,
sorry, but where is the getMom call we are talking about? If you put it into a try catch block you can handle this problem however you like.
Cheers, Christian
|
|
|
|
|
|
Goto Forum:
Current Time: Sun Oct 13 13:22:24 CEST 2024
Total time taken to generate the page: 0.00935 seconds
|
GSI Forum
Search
Help
Members
Login
Home
so I' d ask Christian if he could please have a look to this 
