refactor: Move logic into TrackerHitLocal

[paulgessinger]

This moves the subspace encoding / decoding into headers that are located with the EDM.

[github-actions]

📊: Physics performance monitoring for 63c0fc6

Full contents

physmon summary

• ✅ Particles fatras
• ✅ Particles geant4
• ✅ Particles ttbar
• ✅ Vertices ttbar
• ✅ Truth tracking (KF)
• ✅ Truth tracking (GSF)
• ✅ Truth tracking (GX2F)
• ✅ Truth tracking (KF refit)
• ✅ Truth tracking (GSF refit)
• ✅ CKF finding performance | trackfinding | single muon | truth smeared seeding
• ✅ CKF fitting performance | trackfinding | single muon | truth smeared seeding
• ✅ CKF track summary | trackfinding | single muon | truth smeared seeding
• ✅ Seeding trackfinding | single muon | truth estimated seeding
• ✅ CKF finding performance | trackfinding | single muon | truth estimated seeding
• ✅ CKF fitting performance | trackfinding | single muon | truth estimated seeding
• ✅ CKF track summary | trackfinding | single muon | truth estimated seeding
• ✅ Seeding trackfinding | single muon | default seeding
• ✅ CKF finding performance | trackfinding | single muon | default seeding
• ✅ CKF fitting performance | trackfinding | single muon | default seeding
• ✅ CKF track summary | trackfinding | single muon | default seeding
• ✅ Seeding trackfinding | single muon | orthogonal seeding
• ✅ CKF finding performance | trackfinding | single muon | orthogonal seeding
• ✅ CKF fitting performance | trackfinding | single muon | orthogonal seeding
• ✅ CKF track summary | trackfinding | single muon | orthogonal seeding
• ✅ Seeding trackfinding | 4 muon x 50 vertices | default seeding
• ✅ CKF finding performance | trackfinding | 4 muon x 50 vertices | default seeding
• ✅ CKF fitting performance | trackfinding | 4 muon x 50 vertices | default seeding
• ✅ CKF track summary | trackfinding | 4 muon x 50 vertices | default seeding
• ✅ Ambisolver finding performance | trackfinding | 4 muon x 50 vertices | default seeding
• ✅ IVF notime | trackfinding | 4 muon x 50 vertices | default seeding
• ✅ AMVF gauss notime | trackfinding | 4 muon x 50 vertices | default seeding
• ✅ AMVF grid time | trackfinding | 4 muon x 50 vertices | default seeding
• ✅ Seeding trackfinding | ttbar with 200 pileup | default seeding
• ✅ CKF finding performance | trackfinding | ttbar with 200 pileup | default seeding
• ✅ CKF fitting performance | trackfinding | ttbar with 200 pileup | default seeding
• ✅ CKF track summary | trackfinding | ttbar with 200 pileup | default seeding
• ✅ Ambisolver finding performance | trackfinding | ttbar with 200 pileup | default seeding
• ✅ ML Ambisolver | trackfinding | ttbar with 200 pileup | default seeding
• ✅ AMVF gauss notime | trackfinding | ttbar with 200 pileup | default seeding
• ✅ AMVF grid time | trackfinding | ttbar with 200 pileup | default seeding
• 🔵️ Comparison - Truth tracking (GX2F vs KF)

[tmadlener]

Generally, this looks good, I think. There are a few technical details below and the question(s) on how to best fulfill the edm4hep::TrackerHit interface (which, I suppose would be part of the final goal).

The accessors to [gs]etValue and [gs]etCov are currently std::size_t. This should not block something like what is done in key4hep/EDM4hep#170 with accessing them via some enum to improve the ergonomics a bit, right? IIUC there is enough information encoded into the type here such that we can map between enum values (e.g. the Acts::BoundIndices) and the size_t?

[paulgessinger]

@tmadlener I can change the std::size_t arguments to templated integrals, but that wouldn't automatically implement the full "interpretation" mechanism that you added in that PR. The other point is about fulfilling the TrackerHit interface is a bit tricky. Realistically, I can't always fill the members with meaningful numbers. I don't fully know how the interface mechanism works, so e.g. if I could throw in case global position or time is not available.

[tmadlener]

Does the current std::size_t argument allow me to pass in e.g. Acts::eBoundLoc0? IIUC, it should because it's not an enum class but just an enum. The main point I want to make is that there should be a 1:1 mapping between what the users use to index into the measurements and the covariance matrices and some constants that are defined somewhere. (As opposed of having to use a dedicated set of values here). That is the intended way of using this, right?

Regarding the interfaces it is not strictly necessary that a datatype provides the functionality that the interface requires via Members. You can also add dummy implementations via ExtraCode, as long as the getter names match. If you fail to do that the datamodel will fail to compile but (IIRC) we don't do any dedicated validation on the podio side to ensure this during code generation.

As an example from the podio tests:

• The interface
• A datatype that fulfills this via ExtraCode (not that for the test datamodel we use getSyntax: False, so you will have to adapt the ExtraCode in your case accordingly)

[paulgessinger]

@tmadlener I added the redirect mechanism now, where you can use an enum to access named components by looking up the local indices in the type variable. Let me know what you think!

[tmadlener]

Looks reasonable to me. I don't think we can do much more QoL here without without having to invent a lot of new stuff.

[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