the FPE reported in ATLASRECTS-6516 is caused by combining an ID track:
13:04:16 * loc1 : 26.2559471 13:04:16 * loc2 : -449.6217335 13:04:16 * phi : -2.0887670 13:04:16 * Theta : 0.2636617 13:04:16 * q/p : 0.0000428 13:04:16 * charge: 1.0000000 13:04:16 * covariance matrix = 0xeb7d28f0 13:04:16 * corresponding global parameters: 13:04:16 * position (x, y, z ) = (22.8118425, -12.9997923, -449.6217335) 13:04:16 * momentum (px, py, pz) = (-3012.6240677, -5286.5079685, 22540.2672344) 13:04:16 associated surface:
and the MS track
13:04:16 Trk::PerigeeSurface: 13:04:16 Center position (x, y, z) = (0.0000000, 0.0000000, 0.0000000) 13:04:16 13:04:16 * TrackParameters on Surface 13:04:16 * loc1 : 0.0000000 13:04:16 * loc2 : 0.0000000 13:04:16 * phi : -3.0787095 13:04:16 * Theta : 0.5001232 13:04:16 * q/p : -0.0002370 13:04:16 * charge: -1.0000000 13:04:16 * covariance matrix = 0xec83c2b0 13:04:16 * corresponding global parameters: 13:04:16 * position (x, y, z ) = (-363.7110210, -1048.2188476, 6785.0000000) 13:04:16 * momentum (px, py, pz) = (-2019.1807883, -127.1399870, 3702.3208500) 13:04:16 associated surface:
resulting in a chi2/nDoF value at the order of
1.e14 due to their large kink and any attempt to kill the track postfit without triggering an FPE failed as any operation on the weight matrix in the fitter leads to a double overflow. However, when we look at the angular separation between MS/MSOE tracks in particle gun MC events, we find that they are typically below 0.2 in eta and phi, respectively. So we can assume that this combination is a fake that should never be brought into existence. The changes, which I propose here are on the first hand to narrow down the deltaEta window from 0.5 -> 0.2 and the phi window from 1. to 0.2 and on the second hand to slightly modify the matching approach by following the ID track to its last measurement in the Inner detector and to find the first measurement of the MS/MSOE track in the MS. Then the angular differences between the two measurements are used to evaluate the cut. Detailed studies based on simulation were presented in the last two MCP meetings Vol I and Vol II. The summary of the study is that we can bring down the average consumed CPU time of MuonCombinedAlg from 690 ms -> 380ms in the mu=50 pile-up data17 test sample. A test on a single data16 run is currently ongoing.
Tagging @wleight, @rosati for their opinion on my proposal and @sroe, @christos for coding comments. I also tag @amete, @emoyse, @elmsheus to make them aware that we will hopefully observe soon a drop in the SPOT CPUt plot.