Update of the Track length calculator

[dudarboh]

BEGINRELEASENOTES

• Switch to the helix formula without Omega: $\ell{i} = \frac{|z{i+1} - z{i}|}{|\tan{\lambda{i}}|}\sqrt{1 +\tan^2{\lambda_{i}}}$. It shows the best performance so far.
• Other bug fixes and consistency improvements.

ENDRELEASENOTES

• The most major change is the new formula to calculate the helical distance between two neighboring track states. We change from $\ell{i} = \sqrt{\left( \frac{\varphi{i+1} - \varphi{i}}{\Omega{i}}\right)^{2} + \left( z{i+1} - z{i} \right)^{2} }$ to $\ell{i} = \frac{|z{i+1} - z{i}|}{|\tan{\lambda{i}}|}\sqrt{1 +\tan^2{\lambda_{i}}}$ as it shows much more precise results for all tracks.
• Fixed a bug where the track state at the calorimeter surface was not included when track fit of the last subTrack has failed. Now we extrapolate to the calorimeter from the latest successfuly fitted subTrack if PFO has any matched shower in the calorimeter.
• Fixed a bug where an additional extra track state was added by mistake before the calorimeter track state.
• Improved robustness of identifying first TPC curl subTrack. Now it is expected to work100% of the time, not most of the time.
• Now track length calculated for all PFOs which have at least one track, independently of number of clusters, as it should be. In case of the PFOs with 2+ tracks attached (e.g. kinks, V0s) track length takes only the first track to do the calculation. For these cases track length might not be very well defined.
• Code cleanup, style and comments improvements and clarifications.

[tmadlener]

I just had a brief look (so no detailed comments yet). There is a lot of removed code / functionality. I suppose this was mainly useful for development and testing and now that things have settled we really don't want to offer that functionality any longer since the helix length formula will be the only one that is used in the future? Otherwise, we could consider keeping the "legacy" functionality around in case one wants to redo these studies in the future again.

[dudarboh]

Indeed, I think I could keep few utility functions, without using them in the code itself, so that if we want to test all different options again, one at least has all the utils here, rather than deducing them mathematically again from scratch... I will add the onse I removed and one extra next week.

EDIT: As another point of improvement which is on the surface right now, that we could use reconstructed Primary and Secondary Vertex collections to get a starting point for the track length estimator, rather than always assume track comes from (0,0,0). It should be rather simple addition, but requires few more optional steering parameters for the vertex collections. I will try to implement this change locally and if I see it brings the improvement, then I don't see hard to include it in the next patch as well.

[dudarboh]

As discussed on the meeting today, we postpone the idea of calculating track length from the vertex position, as: a) for primary vertices, this should not make any difference, as (0,0,0) is just a reference point and distance to the PrimVertex accounted in z0 paramter. b) for secondary vertices, we keep it as it is, as for the current time-of-flight studies we always use time of the event, as the initial time, not the time of the secondary vertex production. So this needs a more involved treatment, even if needed.

[dudarboh]

As for the track state at the last hit discussion and the difference between getTrackState() vs propagate(). I would prefer to use getTrackState() for now for all the hits. As it seems to show reasonable results as long as the track length calculation is concerned and code looks cleaner. We can always implement this (probably) sub-percent level of improvement in the future.

So for me it looks good to go.