Use PDF for impact parameter weight

[stephenswat]

This commit uses the PDF of a half-Gaussian distribution to determine the weight of the impact factor in the track finding. This change makes it so that weights are strictly positive and negates the "cut-off" effect caused by the confirmation weight.

[beomki-yeo]

So this PDF is less tighter than the current weight, which makes seeding find more seeds? The increased number of seeds is concerning but I might be onboard with it as the efficiency is significantly increased.

Meanwhile do you know why the seeding efficiency is higher than track finding efficiency in your plots above? My understanding is that it is supposed to be the other way around.

[stephenswat]

So this PDF is less tighter than the current weight, which makes seeding find more seeds? The increased number of seeds is concerning but I might be onboard with it as the efficiency is significantly increased.

The problem is that we have a minimum seed weight of $200$ and we also have a per-confirmation seed weight of $200$. Imagine that a seed in the old system has an impact parameter of $0.0001$ mm. In the old system, this creates a weight of $200 - 0.0001 = 199.9999$ so it gets cut by the minimum weight of $200$. In this new system, the weights are strictly positive which I think is good; it means that we don't have this "cut-off" effect. But it also means that - for now - the cut is looser. I plan to rework this so we don't end up with way too many seeds.

Meanwhile do you know why the seeding efficiency is higher than track finding efficiency in your plots above? My understanding is that it is supposed to be the other way around.

It's interesting; I guess that if we kill tracks in the CKF, there is no way to get them back. So we might be killing the wrong tracks? It's hard to say. Also, this assumes a matching ratio of 70% which is pretty tight. For the EF tracking in ATLAS we assume a weighted matching ratio of only 50%.

[stephenswat]

The problem is that we have a minimum seed weight of 200 and we also have a per-confirmation seed weight of 200 . Imagine that a seed in the old system has an impact parameter of 0.0001 mm. In the old system, this creates a weight of 200 − 0.0001 = 199.9999 so it gets cut by the minimum weight of 200 . In this new system, the weights are strictly positive which I think is good; it means that we don't have this "cut-off" effect. But it also means that - for now - the cut is looser. I plan to rework this so we don't end up with way too many seeds.

Thankfully, this issue is easily resolved by requiring one more confirmation seed, i.e. by increasing the minimum weight by $200$.

[stephenswat]

With that fix, this is now ready to go!

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud

[stephenswat]

I updated this to use a normalized PDF with range $[0,1]$. This has the benefit of giving a more consistent range (I want to move all weights to have range $[0, 1]$) while also requiring fewer floating point operations.

[stephenswat]

Physics performance summary

Here is a summary of the physics performance effects of this PR. Command used:

traccc_seeding_example_cuda --input-directory=/data/Acts/odd-simulations-20240506/geant4_ttbar_mu200 --digitization-file=geometries/odd/odd-digi-geometric-config.json --detector-file=geometries/odd/odd-detray_geometry_detray.json --grid-file=geometries/odd/odd-detray_surface_grids_detray.json --use-detray-detector=on --input-events=10 --use-acts-geom-source=on --check-performance --truth-finding-min-track-candidates=5 --truth-finding-min-pt=1.0 --truth-finding-min-z=-150 --truth-finding-max-z=150 --truth-finding-max-r=10 --seed-matching-ratio=0.99 --track-matching-ratio=0.5 --track-candidates-range=5:100 --seedfinder-vertex-range=-150:150

Seeding performance

Total number of seeds went from 336240 to 336227 (-0.0%)

Track finding performance

Total number of found tracks went from 146077 to 146069 (-0.0%)

Note

This is an automated message produced on the explicit request of a human being.

[beomki-yeo]

In the new plots, it seems there is no improvement with the PR. Can we possibly make them better by using the PDF weight?