Ca: update of the track fit utilities
Several commits updating the track fit utilities in CA tracker
Merge request reports
Activity
added Tracking label
requested review from @s.zharko
assigned to @se.gorbunov
- Resolved by Sergey Gorbunov
- Resolved by Sergey Gorbunov
Dear @d.smith, @fweig, @f.uhlig, @se.gorbunov, @s.zharko, @v.friese, @p.-a.loizeau,
you have been identified as code owner of at least one file which was changed with this merge request.
Please check the changes and approve them or request changes.
added CodeOwners label
enabled an automatic merge when the pipeline for 8eab383d succeeds
added 16 commits
-
77653b0f...043446e8 - 8 commits from branch
computing:master
- 57dcd2c7 - Kf refit: proper initialization of the no-field case
- 8020f93f - update of the BBA package version
- 2cb0dc19 - Ca: track fit: remove numerical protection when fit in double precision
- dfa437a1 - Kf: updte of the CbmKfTrackFitter
- 85a31d54 - Ca: make CaTrackFit work with different data types: SIMD and non-SIMD tracks,...
- 5f90ed35 - Ca: fit: use enum for upstream/downstream direction flag
- 277e68e2 - Ca: fixes after rebase
- 34ff68c8 - Ca: cosmetics
Toggle commit list-
77653b0f...043446e8 - 8 commits from branch
enabled an automatic merge when the pipeline for 34ff68c8 succeeds
mentioned in merge request !1903 (closed)
mentioned in merge request !1911 (merged)
Hi, sorry for the late notification wrt the merging of this code. I noticed in the Reco Qa task a totally different behavior of CbmKfTrackFitter which is used internally in CbmRecoQaTask wrt the situation before.
For those of you not familiar with mCBM data analysis the next plot shows various elements (red dashed circles) of the target chamber seen by track projection at the z position where they are expected to be, according to the geometry (this is golden run 2391 from 2022 campaign)
running ONLY the QA after this MR the following very different distribution is obtained:
Besides missing the structures of the target chamber, a very strong y=0 component is found. The cuts (in y) on the last projection are also for the moment a mystery !
I wander if there is some other QA on tracking related observables which can be cross checked in order to see if this is a local (CbmRecoQaTask) miss-representation of the fitter update or it has larger coverage.
PS. I will be in holiday for the next week. I will, therefore, not be able to provide extra info for this issue.
Edited by Alexandru BercuciI tried to print out the values stored in the CbmKfTrackFitter::FitNode. Here is the z distribution of tracking stations (this data are from 3105_node8_00_0000, first event from the first TS) :
[INFO] Target found: "/cave_1/pipe_v19f_0/vacu20_1/target_0" at ( -4.44089e-16 0 0 ) [INFO] - STS station 0 at z = 17.29 cm [INFO] - STS station 1 at z = 30.64 cm [INFO] - STS station 2 at z = 44.31 cm [INFO] - TRD station 0 at z = 120.17 cm [INFO] - TRD station 1 at z = 150.6 cm [INFO] - TRD station 2 at z = 190.8 cm [INFO] - TOF station 0 at z = 241.15 cm [INFO] - TOF station 1 at z = 266.025 cm [INFO] - TOF station 2 at z = 270.075 cm [INFO] - TOF station 3 at z = 282.5 cm [INFO] - TOF station 4 at z = 286.8 cm [INFO] - TOF station 5 at z = 309.722 cm
The values stored in the CbmKfTrackFitter::FitNode::fMxy
AB :: Build kf_track from global_track_0[0] AB :: ref[-1] x[ +0.00] y[ +0.00] z[ +17.29] xy_set[n] AB :: ref[-1] x[ -2.40] y[ -0.57] z[ +29.91] xy_set[y] AB :: ref[-1] x[ -3.31] y[ -0.86] z[ +44.86] xy_set[y] AB :: ref[-1] x[ +0.00] y[ +0.00] z[+120.17] xy_set[n] AB :: ref[-1] x[ +0.00] y[ +0.00] z[+150.60] xy_set[n] AB :: ref[-1] x[-12.38] y[ -29.53] z[+190.30] xy_set[y] AB :: ref[-1] x[ +0.00] y[ +0.00] z[+241.15] xy_set[n] AB :: ref[-1] x[ +0.00] y[ +0.00] z[+266.02] xy_set[n] AB :: ref[-1] x[ +0.00] y[ +0.00] z[+270.07] xy_set[n] AB :: ref[-1] x[ +0.00] y[ +0.00] z[+282.50] xy_set[n] AB :: ref[-1] x[ +0.00] y[ +0.00] z[+286.80] xy_set[n] AB :: ref[-1] x[ +0.00] y[ +0.00] z[+309.72] xy_set[n]
as seen this track is defined by STS/U1, STS/U2 and TRD1Dy. After the fit the results stored in CbmKfTrackFitter::FitNode::fTrack are as follows :
AB :: track_fit AB :: ref[4] x[ +2.06] y[ +0.00] z[ -45.77] AB :: fill kXYt4 AB :: ref[3] x[ +1.39] y[ +0.00] z[ -34.44] AB :: fill kXYt3 AB :: ref[2] x[ +0.43] y[ -0.00] z[ -18.13] AB :: fill kXYt2 AB :: ref[1] x[ -0.64] y[ -0.00] z[ +0.00] AB :: fill kXYt1 AB :: ref[0] x[ -1.40] y[ -0.00] z[ +12.96] AB :: fill kXYt0 AB :: ref[-1] x[ -1.66] y[ -0.00] z[ +17.29] AB :: ref[-1] x[ -2.40] y[ -0.57] z[ +29.91] AB :: ref[-1] x[ -3.31] y[ -0.86] z[ +44.86] AB :: ref[-1] x[ -7.87] y[ +22.26] z[+120.17] AB :: ref[-1] x[ -9.72] y[ +2.78] z[+150.60] AB :: ref[-1] x[-12.13] y[ -29.53] z[+190.30] AB :: ref[-1] x[-15.22] y[ -42.64] z[+241.15] AB :: ref[-1] x[-16.73] y[ -49.05] z[+266.02] AB :: ref[-1] x[-16.97] y[ -50.09] z[+270.07] AB :: ref[-1] x[-17.73] y[ -53.30] z[+282.50] AB :: ref[-1] x[-17.99] y[ -54.41] z[+286.80] AB :: ref[-1] x[-19.38] y[ -60.32] z[+309.72]
Note that the first 5 nodes are added on top of those defined through the hits to estimate the projections from the previous post !1904 (comment 46147). As you can see from the print, the X estimates seemed fine but for Y, the values are totally unrealistic.
mentioned in merge request !1908 (merged)