Replace Second dBeta Cut with DNN

[GNiendorf]

Work in progress, may adjust the cut value. The second dBeta cut is very tight and causes quite a loss of pT5 efficiency (especially in a few bins outside the barrel as you can see below, eta -1.5). This PR has a looser cut right now to address this issue, which you will probably see with the increase in FR.

edit: Honestly, I'm just going to close this PR and start fresh considering how much #124 changes the efficiency plots.

[GNiendorf]

/run all

[github-actions]

The PR was built and ran successfully in standalone mode. Here are some of the comparison plots.

The full set of validation and comparison plots can be found here.

Here is a timing comparison:

   Evt    Hits       MD       LS      T3       T5       pLS       pT5      pT3      TC       Reset    Event     Short             Rate
   avg     42.8    323.4    114.8     71.9     99.9    498.0    123.3    137.4    140.5      1.6    1553.7    1012.9+/- 264.7     425.6   explicit_cache[s=4] (target branch)
   avg     43.4    318.7    114.3     71.9    118.3    499.8    129.3    137.1    149.7      2.0    1584.5    1041.3+/- 277.0     434.3   explicit_cache[s=4] (this PR)

[github-actions]

The PR was built and ran successfully with CMSSW. Here are some plots.

OOTB All Tracks

The full set of validation and comparison plots can be found here.

[GNiendorf]

May tighten further to 95.0% depending on the results, seems like this is still a bit of a loose cut in the barrel.

/run all

[github-actions]

The PR was built and ran successfully in standalone mode. Here are some of the comparison plots.

The full set of validation and comparison plots can be found here.

Here is a timing comparison:

   Evt    Hits       MD       LS      T3       T5       pLS       pT5      pT3      TC       Reset    Event     Short             Rate
   avg     42.8    320.5    115.6     73.1     99.5    495.9    122.3    139.0    140.7      2.4    1551.8    1013.1+/- 265.8     426.0   explicit_cache[s=4] (target branch)
   avg     43.7    320.4    116.0     73.1    121.2    497.6    126.0    138.7    147.5      2.1    1586.4    1045.0+/- 280.9     431.9   explicit_cache[s=4] (this PR)

[github-actions]

The PR was built and ran successfully with CMSSW. Here are some plots.

OOTB All Tracks

The full set of validation and comparison plots can be found here.

[slava77]

May tighten further to 95.0% depending on the results, seems like this is still a bit of a loose cut in the barrel.

please post FR plots with the type breakdown as well. It takes an effort to follow the updates otherwise.
Thank you.

[GNiendorf]

To illustrate the issue with the second delta beta cut, here is its current signal efficiency on 100% matched tracks as a function of abs(eta):

[0.996, 0.995, 0.996, 0.996, 0.915, 0.839, 0.912, 0.968, 0.994, 0.999] : efficiency
[0, 0.25, 0.5, 0.75, 1.0, 1.25, 1.5, 1.75, 2.0, 2.25, 2.5] : abs(eta) bins

You can see that at around abs(eta) 1.25 the efficiency drops to a low of 84%.

[slava77]

To illustrate the issue with the second delta beta cut, here is its current signal efficiency on 100% matched tracks as a function of abs(eta):

[0.996, 0.995, 0.996, 0.996, 0.915, 0.839, 0.912, 0.968, 0.994, 0.999] : efficiency [0, 0.25, 0.5, 0.75, 1.0, 1.25, 1.5, 1.75, 2.0, 2.25, 2.5] : abs(eta) bins

You can see that at around abs(eta) 1.25 the efficiency drops to a low of 84%.

I'm curious if there is an issue (bug) in the math for 2S layers.
please break this down to T5s starting from B1 and B2, if possible.
Another check could be to set runQuintupletdBetaCutBBEE and separately runQuintupletdBetaCutBBBB to return true to localize the issue.

[slava77]

I'm curious if there is an issue (bug) in the math for 2S layers.

at a glance, the code is written in a way to account for the full spread in dBeta in the possible range along the strip length. It could be some sign flip or min/max swap that leads to this inefficiency.

[GNiendorf]

The issue is in runQuintupletdBetaCutBBEE. Here is the efficiency plot if I turn just that function off:

[GNiendorf]

Fixed in PR #124 hopefully.

[GNiendorf]

Honestly, I'm just going to close this PR and start fresh considering how much #124 changes the efficiency plots.