feat!: Resurrect original AdaptiveGridTrackDensity; Move new impl to SparseGridTrackDensity

[andiwand]

This is an attempt to resurrect the original AdaptiveGridTrackDensity to compare it's performance against the new SparseGridTrackDensity.

The main reason for this is that the algorithms diverged significantly and it would be good to capture this by different names. This also allows for CPU and physics performance comparisons which is currently looked at.

blocked by

• feat: Add nCleanVtx to VertexPerformanceWriter in Examples #3352

[andiwand]

This is a bit more complicated than I anticipated. There have been a serious of changes to the AdaptiveGridTrackDensity, some of them we want to keep and some of them we want to revert.

• revert refactor: use map instead of two vectors in AdaptiveGridTrackDensity #2338
• keep refactor!: Rename ActsSymMatrix -> ActsSquareMatrix #2387
• keep fix: minor bugs in grid vertex seeder #2376
• revert feat: time vertex seeding #2460
• revert refactor!: make trkGridSize non-template parameter in AdaptiveGridTrackDensity #2745
• revert refactor: Refactor AdaptiveGridTrackDensity #2830

I think this has to be done manually since this also interfered with large scale vertexing refactor. Overall we should keep the improved comments and interfaces while the algorithm should stay as it was with its data structures.

[paulgessinger]

You don't think we can keep #2745 @andiwand?

[andiwand]

You don't think we can keep #2745 @andiwand?

I would definitely keep this in SparseGridTrackDensity which is the current implementation of AdaptiveGridTrackDensity. Looking at the old implementation of AdaptiveGridTrackDensity it seems to be that the constant size has performance benefits. If there is an alternative I would also like to drop the template param.

[paulgessinger]

Did we not measure this back then? I'd be surprised if that's what makes a difference in performance here.

If it does after all, I'd want to attempt to use the compile time variables by dispatching in a compilation unit.

[andiwand]

I don't think we did a full comparison of the std::unordered_map vs the std::vector implementation. Part of this is that track density objects can live on the stack with known size.

[github-actions]

📊: Physics performance monitoring for 03f70ce

Full contents

physmon summary

• ✅ CKF truth_smeared
• ✅ IVF truth_smeared
• ✅ AMVF truth_smeared
• ✅ Track Summary CKF truth_smeared
• ✅ Seeding truth_estimated
• ✅ CKF truth_estimated
• ✅ IVF truth_estimated
• ✅ AMVF truth_estimated
• ✅ Track Summary CKF truth_estimated
• ✅ Seeding seeded
• ✅ CKF seeded
• ✅ IVF seeded
• ✅ AMVF seeded
• ✅ AMVF (+grid seeder) seeded
• ✅ Track Summary CKF seeded
• ✅ Seeding orthogonal
• ✅ CKF orthogonal
• ✅ IVF orthogonal
• ✅ AMVF orthogonal
• ✅ Track Summary CKF orthogonal
• ✅ Ambisolver seeded
• ✅ Ambisolver orthogonal
• ✅ Seeding ttbar
• ✅ CKF ttbar
• ✅ Ambisolver
• ✅ Track Summary CKF ttbar
• ✅ AMVF ttbar
• ✅ AMVF (+grid seeder) ttbar
• ✅ Particles ttbar
• ✅ Vertices ttbar
• ✅ Truth tracking (GSF)
• ✅ Truth tracking
• ✅ Truth tracking (GX2F)
• ✅ Particles fatras
• ✅ Particles geant4

[andiwand]

This is the performance I measured for CPU and physics. Looks surprisingly comparable to me.

I am not sure if we want to proceed with porting the original AdaptiveGridTrackDensity now. One reason to do so is that the algorithm quite diverged and it might be confusing to keep the name for the newer version. Also the newer one was extended to time while the old one was not adoptable in this direction. On the other hand the principle is quite the same while we use a different data structure as a backend.

[andiwand]

dropping this for now as there are no apparent gains in merging this

[sonarcloud]

Quality Gate passed

Issues
24 New issues
0 Accepted issues

Measures
0 Security Hotspots
63.9% Coverage on New Code
4.3% Duplication on New Code

See analysis details on SonarCloud