Optimize ECAL lin-reg MIP tracking

[tvami]

I am updating ldmx-sw, here are the details.

What are the issues that this addresses?

This resolves #1420

Check List

• I successfully compiled ldmx-sw with my developments
• I ran my developments and the following shows that they are successful.

This is a work together with @kawaterrysit
We optimized kaons vs signal, I'll attach the plot when we fully converge, but the 23 mm seems already pretty good. Edit: the best option actually seems to be 35 mm.

With the original setting we really were just looking in the front ECAL since the 9 mm setting would not reach the next layer in the back ECAL. So we expect much more tracks to be built like this.

[tvami]

With the original setting we really were just looking in the front ECAL since the 9 mm setting would not reach the next layer in the back ECAL. So we expect much more tracks to be built like this.

And indeed we see much more tracks.
For signal

For the kaons

For ecal PN

The plot that shows why 23 is pretty good already will come tomorrow

[tvami]

Here is the presentation that shows the effect of the different values
Optimizing Linear Regression MIP Tracking.pdf

[tvami]

signal

kaons

ecalPN

[tomeichlersmith]

This feels like a lot of tracks, but I also suppose we have low requirements and an entire shower to analyze.

One feature I would like to be considered is to "extend" tracks. How many of these tracks are just several 3-hit segments of something we would consider a single track? This may be too big of an ask and is venturing close to doing full-scale tracking which we could probably just use ACTS for at some point.

[tvami]

Yeah calling these "tracks" is actually an overstatement. All of these are 3-hit segments, so if you have a long track that makes 15 hits, that's going to lead to 5 "track" on this plot. And that's one reason for the inflation. The other is that in the past with the old radius we technically didnt use the back ECAL at all, so now adding all those makes more "tracks".

I think you have a good point, but I dont see how to do it with the current code. I kinda agree that we should just move away from the lin-reg approach for the further future. We actually played with ACTS w/ B=0 field for the reduced tracker that didnt really work out well, but the algo mentioned in #1491 could be explored for ECAL usage too

[tomeichlersmith]

Yea, the ECal situation is weird. We don't need a good track fit, we just want to be able to algorithmically recognize tracks out of a sea of hits.

I think this is good as is, I'm glad to hear there are two reasons for such a large increase in the number of "tracks". Since both signal and background overflow our histograms, maybe we need to extend the axis in DQM as well? Might need to be reserved for future, I have no idea how that will interact with our CI testing.

I also am very invested in using good vocabulary, so maybe the histograms and some other important locations could use a different word that track? tracklets? track segments?

[tvami]

I propose to extend and rename in the PR that addresses #1486

I do actually plan to tackle that soon too, although next week is tricky with Thanksgiving. But it should prob be done before the next ldmx-sw is cut.

Here is a normalized plot with an overflow bin btw:

(this is after trigger and fiducial, seems to change the ecalPN quite a lot)