GSI Forum
GSI Helmholtzzentrum für Schwerionenforschung

Home » PANDA » PandaRoot » Bugs, Fixes, Releases » Bug in GenfitTrack2PndTrack
Bug in GenfitTrack2PndTrack [message #9262] Mon, 31 August 2009 14:19 Go to next message
StefanoSpataro is currently offline  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


(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 #9279 is a reply to message #9262] Tue, 01 September 2009 15:20 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: *to.infn.it
In this plot (2000 muons at 2 GeV, theta [5°, 20°]) I show on y axis the theta angle before the genfit conversion (lhe theta), and on x the theta after genfit conversion:

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

The same for phi:

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

Here the problem is clearly visible, with all the double structures.
Re: Bug in GenfitTrack2PndTrack [message #9285 is a reply to message #9279] Wed, 02 September 2009 12:11 Go to previous messageGo to next message
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 Go to previous messageGo to next message
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 #9287 is a reply to message #9285] Wed, 02 September 2009 14:48 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: *to.infn.it
I have done your changes,
and I attach the new plots for theta:

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

and phi:

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

It seems the situation is much better, there are still some structures but negligible (hopefully).

Should I commit the changes in svn?
  • Attachment: new_theta.gif
    (Size: 7.31KB, Downloaded 351 times)
  • Attachment: new_phi.gif
    (Size: 6.80KB, Downloaded 358 times)
Re: Bug in GenfitTrack2PndTrack [message #9288 is a reply to message #9287] Wed, 02 September 2009 15:00 Go to previous messageGo to next message
Lia Lavezzi
Messages: 291
Registered: May 2007
Location: Torino
first-grade participant

From: *47-151.net24.it
Nice to see you get good results Smile

Quote:

Should I commit the changes in svn?

Ok for me (and as I can see from its message I guess also for Christian Smile)
Ciao,
Lia.
Re: Bug in GenfitTrack2PndTrack [message #9289 is a reply to message #9288] Wed, 02 September 2009 15:05 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: *to.infn.it
Done!
Re: Bug in GenfitTrack2PndTrack [message #9296 is a reply to message #9289] Thu, 03 September 2009 11:38 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: *to.infn.it
For the community:

The conversion problem for the parameters of the first hit is solved. Unfortunately it still persists for the last hit, even adding the SPU variable.

A buf fix is still needed.
Re: Bug in GenfitTrack2PndTrack [message #9299 is a reply to message #9296] Thu, 03 September 2009 13:11 Go to previous messageGo to next message
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 Go to previous messageGo to next message
StefanoSpataro is currently offline  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)


(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 #9311 is a reply to message #9307] Thu, 03 September 2009 16:05 Go to previous messageGo to next message
Lia Lavezzi
Messages: 291
Registered: May 2007
Location: Torino
first-grade participant

From: *47-151.net24.it
It could be due to the protection for the low momenta in the extrapolate function of GeaneTrackRep:
// protect against low momentum:
  if(fabs(state[0][0])>10){
    FitterException exc("GeaneTrackRep: PROTECT AGAINST LOW MOMENTA",__LINE__,__FILE__);
    exc.setFatal();
    throw exc;
  }

Since when you call gtr->getMom(lastPlane) you perform an extrapolation and in this case q/p = 10.19 the extrapolation could fail.

You could try to comment out the lines of the protection against low momentum to see if the problems disappears.
Ciao,
Lia.
Re: Bug in GenfitTrack2PndTrack [message #9313 is a reply to message #9311] Thu, 03 September 2009 16:18 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: *to.infn.it
Hi,now it seems to work, and the correlation theta/ph seems fine.
Thanks.

Maybe the exception should be catched somehow, I am wondering if commenting out those lines could give problems to the analysis later.

[Updated on: Thu, 03 September 2009 16:22]

Report message to a moderator

Re: Bug in GenfitTrack2PndTrack [message #9314 is a reply to message #9313] Thu, 03 September 2009 16:48 Go to previous messageGo to next message
Lia Lavezzi
Messages: 291
Registered: May 2007
Location: Torino
first-grade participant

From: *47-151.net24.it
Actually the lines were added because there were problems with low momentum tracks in GEANE (I didn' t check it recently whether they are still there) and this protection works fine for the usual propagation within the Kalman procedure... maybe it just has to be handled somehow here in getMom but I am not so expert in exceptions Embarassed so I' d ask Christian if he could please have a look to this Smile

Ciao,
Lia.
Re: Bug in GenfitTrack2PndTrack [message #9315 is a reply to message #9299] Thu, 03 September 2009 16:51 Go to previous messageGo to next message
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 #9316 is a reply to message #9315] Thu, 03 September 2009 16:55 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: *to.infn.it
That would be a great idea, I think.
Re: Bug in GenfitTrack2PndTrack [message #9317 is a reply to message #9314] Thu, 03 September 2009 17:08 Go to previous messageGo to next message
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
Re: Bug in GenfitTrack2PndTrack [message #12253 is a reply to message #9262] Wed, 13 July 2011 18:13 Go to previous message
Johannes Rauch is currently offline  Johannes Rauch
Messages: 41
Registered: September 2010
Location: TUM
continuous participant
From: *natpool.mwn.de
I just put a try catch block around getMom().

If an exception occurs, retVal->SetFlag(-1); is called. Is that correct?

regards,

Johannes
Previous Topic: MVD covariance matrix = 0.
Next Topic: Vertex fitter for eta_c analysis
Goto Forum:
  


Current Time: Wed Dec 08 14:26:39 CET 2021

Total time taken to generate the page: 0.02132 seconds