Use recoil tracking's extrapolated position in EcalVeto

[tvami]

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

What are the issues that this addresses?

Resolves #1494

Introduced recoil_from_tracking_ boolean, which if switched on will propagate the recoil track to the ECAL face and use that to make the projections.
For now I kept the default boolean False, and switched it on for the ecalPN sample, where we run the tracking anyway.

Check List

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

Unfortunately the ecalPN sample we have did not save the tracking simhits so I cannot rerun tracking on with.
I ran on the kaon samples tho which did keep the hits. I'll show the results at the SWAN meeting on Monday.

Much of this work was done by @JYoo001 who also made plots quantifying the distance between the projected and real positions in the ECAL (this we showed at a tracking meeting)

[tvami]

OK the non-ecal-pn tests failed just because I added an extra printout for the BDT score, but all the K-S passes.
Otherwise, for the ecal-pn, there is quite some change:

1. fidiciality changes as expected

• recoil y a little:

• recoil x quite a lot:

Honestly the y distribution with the recoil tracking seems more natural. Sure we expect this to be asymmetric. But I dont think we expect it to be completely on the left side, so having some tracking ending in the right looks OK to me. One thing that's interesting is that the tracking propagation should include both magnetic field and material. I dont actually know how the SP y is made.

2. This will change the projections

• photon separation

• ep angle

looks less peaky in the high end, which to me a good sign

• photon containment energy

• ele cont energy

3. As a consequence the MIP tracking changes too

• lin-reg tracks

I'm kinda surprised this failed the K-S, usually the changes in the tails dont bother the K-S, but ok, from first principles this is expected

• str8 tracks

So here it's a bit weird, I don't know what to make of it. It's not bad for a cutflow tho.

[tvami]

@therwig I thought I'd bring your attention to the validation plots I posted here too. Quite a lot more tracks in the ecal PN as well

[tvami]

I was talking with @danyi211 about this, she pointed out that if the recoil track is on the left, that means that the photon projection is on the right. But if you mismeasure by the tracking that the recoil track is on the right, then the photon projection will be on left -- but that's where the real electron shower is!! so you'll find MIP tracks bc there are MIP tracks from the electron.

[therwig]

Thanks for sharing these - interesting. The straight tracks are quite striking :)
Thinking about your explanation, can we correlate this pathological reconstruction with the electron containment energy? I wonder if some requirement that E/p~1 (something loose, like within ~2 sigma?) or some level of track-to-cluster matching for the electron would clean up this case. We could also look at track quality.
OK, probably you already had some similar ideas about how to fix this, but its gratifying to see a nice explanation here!

[tvami]

This should actually be

Suggested change

	ldmx::Track::TrackState &TargetState = trk_ts.value();
	ldmx::Track::TrackState &EcalTrackState = trk_ts.value();

[tomeichlersmith]

Also, please have the variable be snake_case instead of CamelCase so that it is easy to visually distinguish from classes (CamelCase) and functions (someWeirdJavaThing).

[tomeichlersmith]

Also, please have the variable be snake_case instead of CamelCase so that it is easy to visually distinguish from classes (CamelCase) and functions (someWeirdJavaThing).