Reco Track Endpoint Extrapolation Seems to Prefer One View Over Another

[jdkio]

I've been drawing event displays. Red dots are reco track hits while black squares are reco hits. Specifically Reco_Tree.KalmanPos and Line_Candidates.RecoHitPos respectively. Sometimes you get something like below:

We get different behavior after about z=17000mm. I think this is the endpoint extrapolation prefering one view over another. I'm open to other interpretations.

This is using these test files which are ~main right now: /exp/dune/data/users/kleykamp/dune-tms/2024-09-24_test_23rd_version.tmsreco.root

I've attached a zip file with all event displays I generated. test_event_displays.zip. They're worth looking at. Quite a few miss the track endpoint by 1-2 planes. But there are also several where there's a clear track, but the reco finds nothing. Eg:

[AsaNehm]

Regarding the first event: This is a bit weird as the extrapolation works on both orientations independently. Most likely one direction is picking up the wiggles as the end point during the Hough transform and the extrapolation is then mislead by that while the other orientation doesn't have the wiggles and performs the extrapolation correctly. I accounted for this option by having the matching conditions relaxed, so that the full track is still identified. The individual hits play a slightly minor role in the momentum determination for now and the charge ID should be possible without those hits as well. So in my understanding this is actually showing that the reconstruction works fine. One could improve the extrapolation by looking a bit further than the last 3 hits to account for those wiggles, but then the higher curvature at the end of tracks might become an issue

[jdkio]

We need to get the last hit of the track to detect whether the . Sometimes this causes it to miss it

In fact, here is the reco Z of the track endpoints. The large peak at the end is from muons which escape the TMS. But looking more closely at the end, most tracks end in the third last plane. This reduces our containment volume and reduces the maximum energy muon we can capture.

Not all have a similar pathology to the ones I showed before. Some look like they're just missing the last 1-2 hits of the track, like the one below. Maybe we can adjust parameters to make them more likely to be added

[AsaNehm]

Tuning the parameters sounds like a good solution to me. The ones that I assume one would need to look at are the ExtrapolateLimit to allow for extrapolation even further away from the original end of a path (current value is taken from ND280 TPCs) and NumBarsEnd which gives the number of bars a hit can be away from the direction line at the end to be added. In addition one could look into using more than just the last three hits, which would need direct changes of the Extrapolation() function in TMS_Reco.cpp by changing the number from 3 to 5(?) in line 2659 [while (loop_iterator < 3 && itr!= TrackHits.rend()) {] and making changes in the following lines allowing for more hits to average over.