Preserving LHCb::Particles constancy in Flavour Tagging
In their current implementation, taggers write temporary data to the LHCb::Particle::additionalInfo fields, which requires the use of const_cast. To avoid const_cast, the whole tagging interface would need to be changed to expose the LHCb::Particles to potential changes (which is not desired). These additionalInfo fields are not mutable and are likely not intended to be mutable once particle properties have been computed in stages like Rec. Afaikt, in FT this is done for two reasons
- To reuse the IPPUsig value computed from the raw tracks entering BTaggingTool in the individual taggers
- To mark a particle as being used as a tagging particle by a specific tagger. Such a flagged particle is skipped by other single taggers that care about overlaps.
Personally, I disagree with the second approach; overlap is not harmful, but this is how things have always been done. When BTaggingTool finalizes an event, this info is carefully erased again, although some code duplication seems to have occurred over the last decade. This practice seems to be limited to FlavourTagging downstream of Rec. On this experimental branch, I introduce an alternative static member of BTaggingTool that keeps track of this data in an equivalent way, without the need to put LHCb::Particle constness into question.
Update: After running over 10 JpsiKstar LDST, the only difference I observe is in the deprecated OSElectronTagger on the level of 10e-8 for 15 out of 10000 events. This is negligible. As far as I can tell, this code change is valid. Suggestions for further checks are welcome. If accepted, removing the only two FT-specific additionalInfo fields from LHCb::Particle would be the logical next step.
For the inclusive tagger, !1114 (merged) this change would make the implementation less verbose, but it is probably not essential.