Parametrised scatters don't work any more for dd4hep builds + TrackMasterFitter

!3529 (merged)

It looks like in this MR too much functionality was disabled, such that the TMF's fits are not reliable any more even when using parametrised scatters... this can affect the tools that we use that run the TMF, such as our hit efficiencies.

@jonrob

added RTA label

I guess without pinging the relevant people this will go nowhere: @ausachov @dovombru @mveghel

Question aside: can't you use the PrKalmanFilter?

I still know my way around the TMF, don't worry ;)

Because the fitresults and node types aren't interfaces properly, such that it doesn't work with the interpolator.

and is !3414 solving that?

Somewhat... I had a slightly different solution in mind.

can you elaborate? you mean properly using the interface?

Yes, passing around an interfaces and then just using dynamic_cast to distinguish their implementations is bad practice.

ah yes ... now I remember the problem, the interface is only a facade with nothing behind there's nothing to implement

I guess we can combine fixing this with #429, given the expected timescale of that one? @ausachov

For this issue, indeed, it looks like the scattering is now disabled completely when using dd4hep.

Concerning the interface, the problem is that it is unclear (at least for me) how to technically support the required functionality such as accessing the fitnodes. In particular, the TrackFitResult stores pointers of FitNodes while PrTrackFitResult stores a vector of PrFitNodes. So it would need some interface for iFitNode and then iFitNodeContainer but in one case it means vector of pointers and in another one - just std vector

@mveghel no, I think Laurent's !3663 (merged) will solve this one since, if I understand, too much functionality is disabled for dd4hep, i.e. parametrized scatters should work with dd4hep unrelated to the materials issue but they are simply disabled now

Would you happen to have time for a test of this @ausachov ?

I believe there is some HLT2 line that now doesn't properly account for material...

which line do you mean, and do you see any problems with !3663 (merged)? I am afraid that I am fully booked by the end of this week, and starting from Wednesday next week I will be completely off

assigned to @ausachov

mentioned in merge request !3663 (merged)

assigned to @ldufour

unassigned @ausachov

added Tracking label

mentioned in merge request Moore!3318 (merged)

added RTA WP2 bug labels