feat(nav): Gen3 Navigation policies and factory

[paulgessinger]

Terminology:

• "Navigation delegate": the function that is registered with a tracking volume. In principle, this can be anything
• "Navigation policy": the object that is registered with the tracking volume. It contains a method that is connected to the "navigation delegate". It has extra methods
• "Navigation policy factory": To delay construction of the actual policy object until after the volume is fully sized and has all of its internal structure registered, the blueprint tree only contains navigation policy factories. This is configurable. During construction, the factory is applied to volumes, and produces a policy that is registered with the volume. This is called "navigation policy factory" from a conceptual point of view.
• "MultiNavigationPolicy": chains together multiple policies in a sort of composition. You can have one policy that only deals with portals, one for sensitive and one for passive surfaces, for example.
• To make this less annoying to construct, as you would have to manage the factory, I'm adding a concrete class NavigationPolicyFactory. Its job is to make defining a factory that produces a "MultiNavigationPolicy" easy, like:

  using namespace Acts;
  using SurfaceArrayNavigationPolicy::LayerType;
  SurfaceArrayNavigationPolicy::Config config{
    .layerType = LayerType::Cylinder,
    .bins = {10, 10}
  };
  auto factory = NavigationPolicyFactory::make()
    .add<TryAllPortalNavigationPolicy>()
    .add<SurfaceArrayNavigationPolicy>(config);

  or in python:

  policy = (
    acts.NavigationPolicyFactory.make()
      .add(acts.TryAllPortalNavigationPolicy)
      .add(acts.TryAllSurfaceNavigationPolicy)
      .add(
        acts.SurfaceArrayNavigationPolicy,
        acts.SurfaceArrayNavigationPolicy.Config(
            layerType=acts.SurfaceArrayNavigationPolicy.LayerType.Plane,
            bins=(10, 10),
        ),
      )
  )

Part of #3502

[github-actions]

📊: Physics performance monitoring for b8d52c4

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
• ✅ AMVF gauss notime | trackfinding | ttbar with 200 pileup | default seeding
• ✅ AMVF grid time | trackfinding | ttbar with 200 pileup | default seeding

[paulgessinger]

@asalzburger I'm making some changes to the NavigationStream here to make it support the Gen3 portals. I'm keeping the Gen2 portals in, but I'm prefixing them with "Gen2" to clarify.

[andiwand]

Some general comments and questions about the logic from my side

[paulgessinger]

After discussion with @andiwand, I refactored the interface of the function contained in the NavigationDelegate to be called initializeCandidates in most cases, and I pull out the navigation stream and the logger as separate arguments to clarify the function's purpose.

I'm also wrapping the navigation stream into a separate wrapper object called AppendOnlyNavigationStream that only exposes methods to append to the navigation stream, thereby guaranteeing that the navigation policies will not be able to arbitrarily manipulate the candidate vector.

This is to be complemented (in a future PR) with a method like isValid where the navigation policies can return whether their candidates can still be considered valid, as well as dedicated function for volume entry and exit.

[andiwand]

I think that makes a lot of sense!

Lets get this in!