Joint Direct/Heuristic/ML Navigator

[asalzburger]

@XiaocongAi @benjaminhuth @paulgessinger @niermann999 - here's something I think we could consider.

@benjaminhuth and I discussed the possibility to create a heuristic navigator that basically has a trial-and-error machinery behind, i.e. a parser that collects all surfaces (configured to whatever type) from a given tracking geometry via the

TrackingGeometry::visitSurface(...)

visitor pattern. In every status() call it sorts through the surfaces and drops the unreachable ones, but keeps all reachable ones (probably with some bound tolerance). The idea is to get a slow but true ground truth navigation engine.

Now, practically this is nothing else then the DirectNavigator just with the difference that the direct version of it has a predefined sequence of surfaces to be walked through (which is static).

What I am thinking of is a sort of

template <typename guider_t>
class GuidedNavigator {

}

shell, where one implementation is the DirectGuider, one the HeuristicGuider and then, when @benjaminhuth has trained his MLGuider it could just slit in as a new module. And eventually, when @niermann999 and I have a version of the DetrayGuider we could plug it into the same infrastructure.

What do you think?

[benjaminhuth]

I think that is a really good idea, because otherwise we would have a lot of redundant/duplicate code implementing the navigator interface for all kinds of navigators.

These Guider classes would probably have an interface such as

class MyGuider
{
   std::vector<const Surface *> operator()(const propagator_state &);
},

right?

[asalzburger]

Oh, that could be ... we probably should do here is to set the currentVolumeMaterial instead of the currentVolume ?

[niermann999]

I think that sounds great! Especially since we have to decide the memory layout for the surface containers at somepoint

[XiaocongAi]

One question for @XiaocongAi though:
The KalmanFilter is currently the only place where we access the currentVolume and currentLayer from the Navigator::State.

• do we need that ?

We have to reset the currentVolume and the currentLayer in the (C)KF to reset the navigation status for reversing the navigation direction for the backward filtering in the KF, and for jumping back and forth at different surfaces in the CKF. I'm not sure if this reset of the currentVolume and currentLayer could be removed when we reset the propagation state.

[asalzburger]

Ah, cool, I think we can work around this, with adding a Navigator::State::reset() concept as we have for the Stepper.

[XiaocongAi]

That's a great idea. It will simplify things a lot.