| SPU problem explanation. [message #9525] |
Wed, 07 October 2009 12:58  |
Lia Lavezzi
Messages: 291
Registered: May 2007
Location: Torino
|
first-grade participant |
From: *pv.infn.it
|
|
Hi Christian,
as agreed at the EVO meeting, I explain here what the problem with spu was, so that you can tell me how you managed to fix it.
As I said, I was experiencing a problem due to the fact that spu is updated after each extrapolation and not just after the filtering step (as state and cov are).
Let me give a short explanation: while the state vector and covariance matrix which come out from the extrapolation are stored in statePred and covPred, the spu is not. There is not an spuPred and the spu of the track is updated just after the extrapolation. This is ok as long as we are doing the Kalman procedure, but creates problems in other occasions.
For example it is a problem in the getPos/Mom... functions.
I attach to this message a macro (checkspu.C) to explain this with an example: we have a track (state, cov, plane) described on a plane, call it splane. We want to know the momentum on a different plane, call it eplane and call getMom(eplane).
An extrapolation to eplane is performed and the function returns the momentum there.
The problem is that, if during this extrapolation SPU changes (e.g.: from +1 to -1), in the track representation it is set to -1 and if we re-perform the same getMom(eplane) again we' ll get a wrong result because this second extrapolation is wrong (since it starts with a wrong spu)!
This was my problem: if you solved it I would be very happy! 
Ciao,
Lia.
-
Attachment: checkspu.C
(Size: 5.44KB, Downloaded 279 times)
|
|
|
|
| Re: SPU problem explanation. [message #9526 is a reply to message #9525] |
Wed, 07 October 2009 13:07  |
|
Anonymous Poster
|
|
From: *pool.mediaWays.net
|
|
Hi Lia,
the solution to this unfortunate inconsistency is to treat spu as a real track parameter. In this way it is only predicted and/or updated consistently with the other parameters describing the track. So here is how I did it:
1) I make the state vector 6 dimensional (parameter in GeaneTrackRep.h and some hardcoded 5->6 in the cxx file) so that spu becomes track parameter number 5 (start counting from 0)
2) Very important: Initialize the 5th row and 5th column of the now 6x6 covariance matrix with 0
3) Due to this initialization, the update step in the Kalman will never change the value of spu which cones out of the prediction (The Kalman gain is 6x2 (for a 2D hit) where the last row is just zero, if the covariance has only 0 in the 5th row and column to begin with. If you take my PandaNote and insert the matrices into the equations this becomes clear very easily.
4) Every time you use spu, extract it from the state vector
5) Delete the parameter as a member of GeaneTrackRep
I have done all this in GeaneTrackRep2 which is the class that I use for the external GENFIT. In principle this class should also work inside PandaROOT (together with TGeoManager and FairMCApplication). I will also make it available in the next weeks, and then you can just take a look for yourself. If you want to look now, get genfit at https://genfit.svn.sourceforge.net/svnroot/genfit and look in the GeaneTrackRep directory.
If you have any further questions, please do not hesitate to ask me.
Cheers, Christian
|
|
|
|
|
|
| Re: SPU problem explanation. [message #9534 is a reply to message #9532] |
Thu, 08 October 2009 10:40 |
|
Anonymous Poster
|
|
From: *e18.physik.tu-muenchen.de
|
|
Hi Lia,
I dont really see it as a pity. Spu is a track parameter in some sense. In fact, if you build the universal track representation of dimension 6 (giving position and momentum in space). The covariance matrix is 6x6. But it is only of rank 5. I think this is nicely and explicitely represented in the solution I propose.
Cheers, Christian
|
|
|
|
GSI Forum
Search
Help
Members
Login
Home
