Fix MIP tracking implementation issues

[tvami]

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

What are the issues that this addresses?

• This resolves Fix EcalVeto MIP Tracking Implementation Issues #1355

• An extra was to add the allowance to a half-cell offset in X/Y since that was introduced in v14 geometry (and so with that the MIP tracking of exactly behind in XY does not work anymore)

• I also applied clang-format, sorry that kinda messes up the diffs

Check List

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

Running the validation config file leads to the relevant printout of

 [ EcalVetoProcessor ] 0 : Straight tracks found (before merge): 5
 [ EcalVetoProcessor ] 0 : Begining track merging using 5 tracks
 [ EcalVetoProcessor ] 0 : Straight tracks found (after merge): 4
 [ EcalVetoProcessor ] 0 : Track 0:
 [ EcalVetoProcessor ] 0 :   Hit 0: [-16.8555, -12.512, 14]
 [ EcalVetoProcessor ] 0 :   Hit 1: [-16.8555, -12.512, 12]
 [ EcalVetoProcessor ] 0 :   Hit 2: [-16.8555, -12.512, 10]
 [ EcalVetoProcessor ] 0 :   Hit 3: [-16.8555, -12.512, 8]
 [ EcalVetoProcessor ] 0 : Track 1:
 [ EcalVetoProcessor ] 0 :   Hit 0: [-12.0397, -12.512, 11]
 [ EcalVetoProcessor ] 0 :   Hit 1: [-12.0397, -12.512, 9]
 [ EcalVetoProcessor ] 0 :   Hit 2: [-12.0397, -12.512, 7]
 [ EcalVetoProcessor ] 0 :   Hit 3: [-12.0397, -12.512, 5]
 [ EcalVetoProcessor ] 0 :   Hit 4: [-9.63173, -8.34132, 6]
 [ EcalVetoProcessor ] 0 :   Hit 5: [-9.63173, -8.34132, 4]
 [ EcalVetoProcessor ] 0 :   Hit 6: [-9.63173, -8.34132, 2]
 [ EcalVetoProcessor ] 0 :   Hit 7: [-9.63173, -8.34132, 0]
 [ EcalVetoProcessor ] 0 : Track 2:
 [ EcalVetoProcessor ] 0 :   Hit 0: [-2.40793, -12.512, 8]
 [ EcalVetoProcessor ] 0 :   Hit 1: [-2.40793, -12.512, 6]
 [ EcalVetoProcessor ] 0 : Track 3:
 [ EcalVetoProcessor ] 0 :   Hit 0: [-4.81586, -8.34132, 5]
 [ EcalVetoProcessor ] 0 :   Hit 1: [-4.81586, -8.34132, 3]
 [ EcalVetoProcessor ] 0 :   Hit 2: [-4.81586, -8.34132, 1]
 [ EcalVetoProcessor ] 0 : Finding linreg tracks from 60 hits
 [ EcalVetoProcessor ] 0 :   MIP tracking completed; found 4 straight tracks and 1 lin-reg tracks
 [ EcalVetoProcessor ] 0 :   The pred > bdtCutVal = false

We also had a look at the efficiencies:

original
  >> nStraightTrcaks <= 1:
    >> ecal_pn eff =  0.109
    >> signal_mA_0.01GeV eff =  0.791
    >> kaon eff =  0.313
  >> nStraightTrcaks <= 1 && nLinregTracks <= 1:
    >>>> ecal_pn eff =  0.076
    >>>> signal_mA_0.01GeV eff =  0.775
    >>>> kaon eff =  0.252
after the fix
  >> nStraightTrcaks <= 1:
    >> ecal_pn eff =  0.033
    >> signal_mA_0.01GeV eff =  0.763
    >> kaon eff =  0.092
  >> nStraightTrcaks <= 1 && nLinregTracks <= 1:
    >>>> ecal_pn eff =  0.032
    >>>> signal_mA_0.01GeV eff =  0.762
    >>>> kaon eff =  0.09

--> you can see we loose 3% of signal but we kill 3.5 more kaons (!!!) (and generally pn bkgs too)

[tvami]

We expect the validation to fail both in the logs and in the num straight / lin reg tracks.

[tvami]

We expect the validation to fail both in the logs and in the num straight / lin reg tracks.

I had a look at the validation plots... well it seems we dont have the num straight / lin reg tracks in the DQM haha. So no FAIL there. The logs have changed as expected.

[tomeichlersmith]

Besides my technical question about enabling logging, could you add in the MIP tracking counts to the DQM? I feel like they would be good additions and would fit naturally within the EcalShowerFeatures DQM processor. If no time, then that is fine. I just know we will need to make a new release for #1358 and would be happy to include other fixes.

[tvami]

could you add in the MIP tracking counts to the DQM?
I feel like they would be good additions

I agree
and we are already doing in the "new BDT branch", so that's for the next PR, if you are OK with that