Application of the CA tracking into the online reconstruction chain: Iteration 1
Overview
In this merge request, the first iteration of the CA tracking application into the online reconstruction chain is carried out. In the first iteration, an object of the tracking parameters is initialized from the pre-generated binary parameter file.
Logs
14.09.2023
- Added a new library CaCore in cbmroot/algo/ca/core, where the code from cbmroot/reco/L1/L1Algo is to be iteratively moved
- Added the cbm::algo::TrackingChain class
- Added the dummy cbm::algo::ca::TrackingDemo class, which is to be replaced with the actual CA tracking later
08.10.2023
- Removed the cbm::algo::ca::TrackingDemo class
- Added a tracking parameters file mcbm_beam_2022_05_23_nickel.ca.par to the algo/params
- Added parameters object initialization to the cbm::algo::TrackingChain class
Merge request reports
Activity
requested review from @fweig
assigned to @v.friese
Dear @f.uhlig, @v.friese, @p.-a.loizeau, @se.gorbunov, @v.akishina, @a.bercuci, @p.kaehler, @s.lebedev, @andrey.lebedev,
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
mentioned in merge request !1324 (merged)
added 54 commits
-
5539d052...ab6d88c0 - 50 commits from branch
computing:master
- 90156303 - CA: move the L1CAIteration class to /algo
- d98e0159 - CA: moved L1Parameters, L1SearchWindow and CaMonitor to cbm::algo::ca
- 6352605d - CA: move parameter and init manager to the libCaCore
- d2aaa397 - CA-Online:
Toggle commit list-
5539d052...ab6d88c0 - 50 commits from branch
added 2 commits
added 2 commits
added 4 commits
-
aafd2c36...8f054f2e - 3 commits from branch
computing:master
- 35aba348 - CA-Online:
-
aafd2c36...8f054f2e - 3 commits from branch
- Resolved by Sergei Zharko
The implementation, as far as I can see, is empty - the tracking chain will return an empty track vector. What will be the benefit to include this in the DC 11 October?
Hi @v.friese,
first, we want to have a placeholder where we can iteratively add more stuff. And we want to make sure this placeholder is up-to-date with the framework. The only way to do it is to make it a default part of the reco chain.
Second, even a dummy tracker can have problems that we want to discover. It is not completely empty - we want to read the setup, receive some data, and output some monitoring info. Maybe it is already able to crash the online reconstruction:) We want to experience that.