Validate track reco

[jdkio]

We can measure the amount of true visible energy from a particle on a track / true visible energy from the particle. This has a peak at about 80% for LAr-TMS true muons, which means about 20% of the hits are missed.

We need to investigate why this is happening.

One theory is that the true endpoint isn't found. This is what I get for LAr->TMS true muons. Most are in the last plane but there's a few outside that big peak. I get about 35% outside 10cm in z.

X has an uncertainty around 10cm, which seems high too

The event display doesn't plot all hits, just hits on track. This doesn't let us know about missed hits, so it's difficult to know what's happening. So that needs to be checked

[jdkio]

One suggestion was that maybe vis E was miscalculated. So instead we can look at n hits on track / n hits from particle, and compare. If there's a large difference, then maybe it's a miscalculation issue. But it turns out n hits gives a similar answer, with a peak around 70%

[jdkio]

So I think what's happening is that some hits are on two or more bars inside the same plane. But reco only includes one of the two in the track. Maybe a good event display would make this more clear. Here's the plot of the two divisors for the nhits plot, and you can see true hits > 100. The only way that can happen for this sample of muons is if you get more than 1 hit per plane.

We don't have exactly what we need in the output to check. But here I count the z positions of all hits from either all reco hits or all hits on a track (using only events with a single reco track that is a true muon). So I'm plotting the count of all z positions in Line_Candidates.RecoHitPos and Reco_Tree.TrackHitPos as a proxy for plane number. You cans see more 2 plane cases in the all reco hit cases

One way to fix this would be to merge nearby hits before doing reco. Probably do a energy weighted merge. Then reco would maybe need to know a bit more about the width of the hit after merging. And the code would need to understand average positions between two bars.

Another way to fix would to do reco and then go in after the fact and add hits that are touching your track. And then you'd have some sort of function to adjust track position based on the new information