[TrackFit] Generalization for any Bz field direction

[BrieucF]

BEGINRELEASENOTES

• [TrackFit] Generalization for any Bz field direction

ENDRELEASENOTES

[andread3vita]

Hi @BrieucF! Thanks for the PR. I’m a bit concerned about the case where a track is fitted using only the muon system. In that situation, (B_z < 0), but we would not want to propagate the track to the inner calorimeter surface. Maybe we could change the condition from “non-zero magnetic field” to “positive magnetic field” instead?

[BrieucF]

Hi @BrieucF! Thanks for the PR. I’m a bit concerned about the case where a track is fitted using only the muon system. In that situation, (B_z < 0), but we would not want to propagate the track to the inner calorimeter surface. Maybe we could change the condition from “non-zero magnetic field” to “positive magnetic field” instead?

Why would we never want to extrapolate a muon track to the calorimeter? Actually, we could just completely remove this condition on Bz (you can extrapolate a track even if Bz = 0). My problem with the current check and how it is done is that if at some point, for any reason, Bz changes sign, this code will go wrong, and people will have a hard time to debug... I don't think the tracking algorithm should impose anything on the B field sign.

[andread3vita]

Why would we never want to extrapolate a muon track to the calorimeter? Actually, we could just completely remove this condition on Bz (you can extrapolate a track even if Bz = 0). My problem with the current check and how it is done is that if at some point, for any reason, Bz changes sign, this code will go wrong, and people will have a hard time to debug... I don't think the tracking algorithm should impose anything on the B field sign.

I agree that we could also propagate the track to the calorimeter starting from the muon system, but in that case the propagation would be fundamentally different. As you suggested in this PR, we could use the built-in GenFit method (as I already do for the propagation to the IP), but we should distinguish between tracks located before or after the calorimeter. In the former case, the track should be propagated forward starting from the last hit, whereas in the latter case it should be propagated backward starting from the first hit.

[BrieucF]

If not too much work, I'd propose to already handle properly the case where we extrapolate outwards i.e. to use the stepper. The standalone tracks from the muon system will presumably be built by calling a different instance of GenFitTrackFitter, for which RunCalorimeterExtrapolation should be set to false (could be added as a disclaimer in this helper)

[andread3vita]

Sure, I can try to implement it :)

[giovannimarchiori]

@andread3vita @BrieucF do we want to merge this PR as is or wait for Andrea to first work on the extrapolation improvements mentioned earlier?