Record track quality to the CKF tracks

[beomki-yeo]

track quality is the struct for the NDF, chi2 and the number of holes.
This has been recorded in the KF but we can also calculate it for the CKF.

This will allow us to apply the ambiguity resolution to the CKF output directly, and reduce the KF time significantly.

[krasznaa]

I'm generally on board. Code-wise I like how you did things.

But do you have some measurements to what it does to our runtime performance? I understand that the KF should become faster (not necessary?) after this. But do you have any quantitative numbers on that? 🤔

[beomki-yeo]

I understand that the KF should become faster (not necessary?) after this.

No this PR is not for performance improvement.
Instead, this PR will allow us moving the ambi-solver, which needs chi2 and number of holes information, before the KF. Then, KF will fit less number of tracks.

[niermann999]

I understand that the KF should become faster (not necessary?) after this.

No this PR is not for performance improvement. Instead, this PR will allow us moving the ambi-solver, which needs chi2 information, before the KF. Then, KF will fit less tracks.

Sorry if this is a stupid question, but do we have/plan to add a GPU ambi solver or is this a CPU-only development?

[stephenswat]

Sorry if this is a stupid question, but do we have/plan to add a GPU ambi solver or is this a CPU-only development?

If we end up running the ambiguity resolution between the CKF and the KF we will want to build a GPU ambiguity resolver.

[beomki-yeo]

I will move the current cpu amisolver to between ckf and kf, and implement the gpu ambl-solver in a similar fasion

[beomki-yeo]

Can I go with the PR? There are still some PRs left before I can move the ambiguity resolver between the CKF and KF.

There is no big difference in performance. Anyway this PR itself is not for performance improvement

Main

byeo@hermes:/mnt/nvme0n1/byeo/projects/traccc/traccc_build$ ./bin/traccc_benchmark_cuda 
Please be patient. It may take some time to generate the simulation data.
2025-02-10T14:40:40-08:00
Running ./bin/traccc_benchmark_cuda
Run on (32 X 3000 MHz CPU s)
CPU Caches:
  L1 Data 32 KiB (x16)
  L1 Instruction 32 KiB (x16)
  L2 Unified 512 KiB (x16)
  L3 Unified 16384 KiB (x8)
Load Average: 1.35, 1.96, 1.93
***WARNING*** CPU scaling is enabled, the benchmark real time measurements may be noisy and will incur extra overhead.
WARNING: No entries in volume finder

Detector check: OK
------------------------------------------------------------------------------------
Benchmark                          Time             CPU   Iterations UserCounters...
------------------------------------------------------------------------------------
ToyDetectorBenchmark/CUDA 1.2447e+10 ns   1.2446e+10 ns            1 event_throughput_Hz=8.03452/s

This PR

byeo@hermes:/mnt/nvme0n1/byeo/projects/traccc/traccc_build$ ./bin/traccc_benchmark_cuda 
Please be patient. It may take some time to generate the simulation data.
2025-02-10T14:28:21-08:00
Running ./bin/traccc_benchmark_cuda
Run on (32 X 3000 MHz CPU s)
CPU Caches:
  L1 Data 32 KiB (x16)
  L1 Instruction 32 KiB (x16)
  L2 Unified 512 KiB (x16)
  L3 Unified 16384 KiB (x8)
Load Average: 1.10, 1.63, 1.51
***WARNING*** CPU scaling is enabled, the benchmark real time measurements may be noisy and will incur extra overhead.
WARNING: No entries in volume finder

Detector check: OK
------------------------------------------------------------------------------------
Benchmark                          Time             CPU   Iterations UserCounters...
------------------------------------------------------------------------------------
ToyDetectorBenchmark/CUDA 1.2514e+10 ns   1.2513e+10 ns            1 event_throughput_Hz=7.99149/s

[sonarqubecloud]

Quality Gate passed

Issues
6 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
5.5% Duplication on New Code

See analysis details on SonarQube Cloud