Also check for LHCb::Track pointer equivalence.
Charged particles should be considered as perfectly overlapping if their ProtoParticle objects are the same or if their Track objects are the same. This MR adds the check for the latter.
This matches the pointer-based implementation in LoKi::CheckOverlap (added in !74 (merged)), but omits the more detailed, measurement-based implementation.
Usecase
The usecase is for analysis of Turbo data. In DaVinci, we dynamically create a merged container of the long and downstream ProtoParticles created in HLT2, and then link this merged location to the Brunel location (Rec/ProtoP/Best
). This is nice because all the DaVinci stuff expects ProtoParticles to be in the Brunel locations, so we don't need to configure much.
The problem is that the creation of the merged container creates copies of the ProtoParticles. One then takes a Turbo candidate, whose ProtoParticles will point back to one of the original HLT2 locations, and StdLoosePions
for example, whose ProtoParticles will point back to the merged container, and the default CheckOverlap
tool fails to spot overlaps because the ProtoParticle pointer comparison fails (the assumption that there is only 'one true container' of ProtoParticles has been violated).
Fix
We don't create a merged container of Tracks, so we can compare Track pointers, in addition to ProtoParticle pointers, to check for overlaps.
LoKi::CheckOverlap
Differences with Using the LoKi::CheckOverlap
tool with CombineParticles also 'fixes' the problem, because it performs the Track pointer check. But I think fixing the default CheckOverlap tool is worth doing partly because it is the default (so we don't need to tell every Turbo analyst doing combinatorics to use LoKi::CheckOverlap
) but also because LoKi::CheckOverlap
makes additional, measurement-based checks, such as with track slopes, and I imagine that some users might not want such comparisons (they could turn them off, but that's even more configuring).
Interestly, there is a difference when using the (fixed) CheckOverlap
tool to when using LoKi::CheckOverlap
. Firstly with the default:
Xb SUCCESS Number of counters : 10
| Counter | # | sum | mean/eff^* | rms/err^* | min | max |
| "# J/psi(1S)" | 3035 | 3088 | 1.0175 | 0.13348 | 1.0000 | 3.0000 |
| "# Phys/myUpsilionStar" | 3035 | 3392 | 1.1176 | 0.38206 | 1.0000 | 8.0000 |
| "# Phys/myUpsilon" | 3035 | 3088 | 1.0175 | 0.13348 | 1.0000 | 3.0000 |
| "# Upsilon(4S) -> J/psi(1S) psi(2S) " | 3035 | 23 | 0.0075783 | 0.19451 | 0.0000 | 9.0000 |
| "# input particles" | 3035 | 6480 | 2.1351 | 0.45943 | 2.0000 | 11.000 |
| "# psi(2S)" | 3035 | 3392 | 1.1176 | 0.38206 | 1.0000 | 8.0000 |
| "# selected" | 3035 | 23 | 0.0075783 | 0.19451 | 0.0000 | 9.0000 |
|*"#accept" | 3035 | 9 |( 0.296540 +- 0.0987001)%| ------- | ------- |
|*"#pass combcut" | 3523 | 23 |( 0.652853 +- 0.135684 )%| ------- | ------- |
|*"#pass mother cut" | 23 | 23 |( 100.000 +- 4.34783 )%| ------- | ------- |
And secondly with LoKi:
Xb SUCCESS Number of counters : 10
| Counter | # | sum | mean/eff^* | rms/err^* | min | max |
| "# J/psi(1S)" | 3035 | 3088 | 1.0175 | 0.13348 | 1.0000 | 3.0000 |
| "# Phys/myUpsilionStar" | 3035 | 3392 | 1.1176 | 0.38206 | 1.0000 | 8.0000 |
| "# Phys/myUpsilon" | 3035 | 3088 | 1.0175 | 0.13348 | 1.0000 | 3.0000 |
| "# Upsilon(4S) -> J/psi(1S) psi(2S) " | 3035 | 21 | 0.0069193 | 0.19112 | 0.0000 | 9.0000 |
| "# input particles" | 3035 | 6480 | 2.1351 | 0.45943 | 2.0000 | 11.000 |
| "# psi(2S)" | 3035 | 3392 | 1.1176 | 0.38206 | 1.0000 | 8.0000 |
| "# selected" | 3035 | 21 | 0.0069193 | 0.19112 | 0.0000 | 9.0000 |
|*"#accept" | 3035 | 8 |( 0.263591 +- 0.0930707)%| ------- | ------- |
|*"#pass combcut" | 3523 | 21 |( 0.596083 +- 0.129688 )%| ------- | ------- |
|*"#pass mother cut" | 21 | 21 |( 100.000 +- 4.76190 )%| ------- | ------- |
This is combining a J/psi(1S)
Turbo candidate with a psi(2S)
particle made with PersistReco objects. The LoKi tool removes two more candidates than the default.
I have no idea if this would be an issue for an analysis, presumably it's strongly analysis dependent, but it's interesting to see anyway.
(For completeness: without the fix in this MR, the default CheckOverlap
tool creates 3445 candidates!).