Kleykamp track smoothing

[jdkio]

Adds in track smoothing for y positions. In some cases, this reduces the kalman filter
lol y value outside TMS: 3211.24 TMS: [-3500, 500]
errors mentioned in issue #160. But it also causes that to happen sometimes when it has a large jump in y, so it's not perfect. But overall the y positions are more accurate, see below

Strategy

First it finds "transition points". This is where Y jumps because the track has moved +/- 1 bar in the U or V view. At that point, we know the y position with better accuracy. In my testing, it's about 2x more accurate

Then, we can divide the track into segments between these transition points, and before and after. For the between points, we can connect using a straight line*. For the before and after, we can estimate slope. For now, I'm using the overall y slope as the best estimate, while limiting so the end position is never more than +/- 30cm from the starting position. This limit assumes we'd see an additional transition point when we hit +/- 30 cm, so it couldn't have been that large.

• Really we should take the two points that mark the transition point and make them more sloped but right now they're just straight.

Below are examples before and after smoothing. The red points are reco positions while green diamonds are true positions. Additional event displays can be found in
/exp/dune/data/users/kleykamp/dune-tms/Validation/Tracking_Validation/2024-10-17_test_no_track_smoothing_images/EventDisplays
and
/exp/dune/data/users/kleykamp/dune-tms/Validation/Tracking_Validation/2024-10-17_test_track_smoothing_images/EventDisplays

Statistics

Below are the hit y resolution plots. I didn't plot them on the same hist but you can see they improve from a FWHM of ~20cm to ~12cm.

See event displays for the tails of the distribution in
/exp/dune/data/users/kleykamp/dune-tms/Validation/Tracking_Validation/2024-10-17_test_track_smoothing_images/EventDisplays/poor_hit_y_resolution_large_deviation

They are dominated by cases where the track is in a busy event where the reco track is confused. There are also cases where the truth info has a point way outside the positions we'd expect. I think that has to do with how we do hit merging. So two hits from different particles are merged into a single reco hit because of the readout. But now the true position should have two true positions, one for each particle. But instead we currently merge that into the avg true position. That doesn't really make sense and we should change it, or not include those in these plots

[LiamOS]

Very good change!

Have given it a high-level look over and am happy. Will give this a test run myself to see what the difference is like. Approved.

[AsaNehm]

With the changes now also approved by me

[AsaNehm]

Some numbers on end point resolution with the track smoothing
Kalman filter on: x: 0.539±42.319, y: -20.456±289.112, z: -13.545±116.644
Kalman filter off: x: -2.648±40.362, y: -18.729±515.476, z: -19.198±155.027
Tested on the first antineutrino sample