Kalman Fitter on CPU #264
Kalman Fitter on CPU #264
Conversation
|
First of all this looks like fantastic work! Thanks @beomki-yeo! Are the pulls you show the smoothed ones? |
|
This is impressive work! Note that d0 and z0 are the only ones somehow that are estimated directly (by the measurements) and not indirectly (by the trajectory), so, Indeed it looks like the errors are not correctly defined. It does help to print the residuals/pulls per measurement surface ... |
|
Yeah They are smoothed parameter. There is definitely something wrong because chi square gets bigger with smoothed parameters :/ Let me dig into it |
|
Nahh I was comparing with smeared local position instead of the truth local position. Hopefully that fixes the issue... |
beomki-yeo
force-pushed
the
fitter
branch
3 times, most recently
from
74b93d3
to
ece6ade
Compare
|
PR is ready for review. Let me leave |
|
Wow. I just found that KF with cmath plugin doesn't work :/ .. |
|
All bugs are fixed now but I still need to wait for acts-project/detray#360 and acts-project/algebra-plugins#80 to be merged. |
|
@krasznaa Could you check the PR? |
|
@beomki-yeo Attila's on his Christmas break (as most already are), so he might only get around to this in January |
|
Not quite next year, but by now I'm at 1100m next to a ski slope. With only my phone for electronics. Will have a look once I'm down from the mountain at the end of the week. 😄 |
core/include/traccc/fitting/kalman_filter/gain_matrix_updater.hpp
Outdated
Show resolved
Hide resolved
|
@krasznaa Could you approve again if the changes are OK? |
This is a (very preliminary) PR for Kalman filtering on CPU. The detray pull requests also should be merged before we accept this PR.
Let me explain one by one as the PR is pretty big...
EDM
There are two EDM classes added.
track_candidate, which takes geometry link and measurement object, is an input to kalman filtering and potentially an output of combinatorial kalman filtering.track_stateis the output of kalman filtering, which takes the fitted track parameters, measurement and geometry link.Algorithm structure
There is a
fitting_algorithmclass which runs the fitting algorithm fortrack_candidatecontainer input (Doesn't have to be for single event).kalman_fitting, which is wrapped byfitting_algorithm, runs the fitting algorithm for a single track. It runsdetray::propagatorinside a given geometry which triggersactor_chainfor every surface intersection.The actor chain is made of the following actors: (1) parameter transporter -> (2) material interactor -> (3) kalman actor -> (4) parameter resetter.
(1) is for calculating the jacobian from the last surface to the current surface
(2) is for calculating the effect of energy loss and multiple scattering
(3) is for kalman filtering
(4) is for resetting the track parameters for the next surface intersection
(1), (2), (4) are already defined in detray so people can check them out by themselves.
Kalman filtering (kalman actor)
The updating or filtering of the predicted track parameters is done by the kalman actor The algorithm is pretty much the same with one implemented in ACTS main repository. Techincally, eq. 7 - 8b of R.Frühwirth is implemented in
gain_matrix_updaterKalman smoothing
Given that kalman filtering is an iterative algorithm on the time series of measurements, the filtered state at the last surface contains all information from the previous surfaces while the first measurement only contains the information of its own surface. Since we are mostly interested in the fitted state of the first surface, we need to refine the fitted parameters using the smoothing algorithm. There are two ways for smoothing: (1) For a smoothed parameter of n-th surface, remove the process noise using the predicted and smoothed parameters of the n+1-th surface. Since the smoothed parameters of the last surface is equal to the filtered parameter, the algorithm should iterate backwardly (This is what implemented in ACTS) (See Eq. 3.36 - 3.37 of this book (2) Do one more kalman filtering backwardly from the last surface to the first surface and take an average of two kalman filtering result. (See Eq. 3.38 - 3.40 of this book.)
I tried to implemented (2) method at the begining but ended up with implementing (1), because the backward navigation has some issues right now.
Test Results:
Setup
Following figures show the pull distributions of bound track parameters at the first surface. I don't know why d0 and z0 (local0 and local1) show unreasonable results (@asalzburger @paulgessinger Do you guys have any idea ?)
One thing to note is that the fitting with a single precision makes wrong results after the smoothing where chi square gets negative.
What to do next
The kalman filtering in this PR was tested in a very ideal detector setup. In real cases, lots of exceptions will occur during the fitting, which we need to handle very carefully.
Haven't tested GPU yet, but I have a strong feeling that we will have a bad performance unless we achieve the thread synchronization over the actor chain triggering.
As mentioned above, single precision is not working correctly for smoothing. I think it is because the residual covariance is not always positive definite. The ACTS main repository is handling this with the single value decomposition (SVD) to make the covaraince positive definite. We need to think about implementing SVD in algebra-plugins
I made another (very unsatisfactory) event map class for this truth tracking validation. I need to come up with a better way to store the truth information of events.