EleEleOLR should use absolute delta phi

@fcostanz noticed that the EleEleOverlapTool does not use the absolute value of delta phi here, when it checks if two electrons are close, but rather the signed delta phi, which is returned from here. In the same if condition the absolute value of delta eta is used, as expected. I cannot see any possible reason why the signed value of delta phi should be used and conclude that this is a bug. @fcostanz and @yoyamagu agree.

While convincing myself that this is indeed a bug, I checked my fake analysis (Z+fake selection) for possible effects of this. I selected events, where the electrons are close in eta (<0.75), because only these should be affected by the bug. In addition, I require that the subleading lepton is in -0.2 < phi < 0.2. And then I plot the phi of the leading lepton. This distribution is slightly asymmetric. It shows that the leading lepton prefers positive phi values.

Looking at the critical line in the EleEleOverlapTool, it requires that (phi1-phi2) is negative. If that’s the case, the lepton with smaller pT gets removed. So if I fix the subleading lepton phi to ~0 in my selection cuts, the initial requirement simplifies to phi of the leading lepton being negative. In that case, we lose events. And I think that this is what we see in the attached plot.