privilege daughter photon over Brem (supersedes !560)

Create dielectrons with and without Brem corrections. In the case of Brem overlap with the \pi^0/\eta daughter photon, use the dielectron without Brem. There are a number of subtleties here:

• Candidates with and without Brem are aligned by comparing the protoparticles of the \pi^0/\eta candidate's daughter photon, electron, and positron. Not all candidates will be matched because the \pi^0/\eta candidate may pass our selections only if Brem is (not) added.
• The default choice is to use the \pi^0/\eta with Brem. It is rejected if it has more than one Brem photon added to either electron or if a Brem photon shares a caloHypo with the daughter photon.
• If a Brem shares a caloHypo with the daughter photon, the corresponding \pi^0/\eta without Brem is used if it exists.
• If a \pi^0/\eta candidate without Brem has no match with Brem, it is also used.

Some additional branches have been added to the ntuple to elucidate this process:

• tag_withBrem indicates whether the particle came from the container that had Brem corrections. It is -1 for tag particles that are not \pi^0/\eta.
• tag_BremMatched indicates whether the particle had a match in the other container. It is -1 for tag particles that are not \pi^0/\eta.

NB: This means that some of our previous ntuple-level selections are obsolete. The photonBremOverlap should now always be False for \pi^0/\eta candidates, and the number of Brem added to any electron should always be \leq 1.

There are a few additional changes to the ntuple:

• The nBremAdded_e0 and nBremAdded_e1 branches have been replaced with nBremAdded_em and nBremAdded_ep, associating the number of Brem corrections to a specific electron/positron. Note that they will be -1 for \pi^0/\eta where Brem was not added. They are also now int instead of float.
• The photonBremOverlap branch now defaults to -1 for cases where it is not defined. It is also now an int instead of a float.
• The DTF versions of the material branches have been dropped. This was causing a bug where the VELO tool would get caught in an infinite loop, possibly because the daughter momenta had not been DTF-corrected. It is not obvious why this problem did not occur previously.

Also, resolve memory leak. (I think it was caused by ROOT-typing checks.)

Instructions

When creating your merge request:

• Add a label for your WG
• Mark as "Draft:" until you're happy with the CI results
• If the merge request supersedes a previous one, add a comment at the end of the header: (supersedes !<MR number>). Please state explicitly in the description if the superseded ntuples can be deleted immediately, or after the new merge request is finalised

When ready:

• Remove the "Draft:" from the title:
• Assign the merge request to you working group's DPA/RTA liaison

To find your working group's DPA/RTA liaison, see this page:

https://twiki.cern.ch/twiki/bin/viewauth/LHCbPhysics/LHCbWGLiaisons