Prototype N-body Track combiner

An N-body LHCb::Track combiner, TrackCombiner, to get prototype Upgrade HLT1 two-body lines up and running. See LHCBPS-1819.

Motivation

1. Accept Track objects to avoid the (presumed costly) Track → ProtoParticle → Particle promotion needed to use CombineParticles.
2. A new, functional algorithm that is a much more 'minimal' CombineParticles, and so may be useful for benchmarking to understand where the bottlenecks will be in any combiner (e.g. combinatorics, vertexing, LoKi functor evaluation, ...).

The intention with this implementation is to work towards getting a full set of realistic prototype HLT1 lines up and running so that we can get a feeling for the numbers.

Implementation

Roughly:

1. Accept a single LHCb::Event::v1::Track vector
2. For each combination of N tracks in that vector:
   1. Create a RecVertex object filled with the current N tracks
   2. Apply pre-fit cuts to the vertex object (I'll come back to this)
   3. Fit the vertex
   4. Apply post-fit cuts to the vertex object
3. Return a LHCb::RecVertex vector of passing fitted vertices

Details

Input type

Currently accepting v1 tracks as this is the output of the algorithm I've been testing as the input.

Vertex fit

The fit is done with LHCb::TrackStateVertex, which is iterative. The TrackVertexUtils::vertex method is much faster for two-body vertices, and the TrackVertexUtils::addToVertex could be used to extend this to N-bodies. Or this could all soon be superseeded by a faster implementation that @wouter has been working on.

Pre-fit cuts

It would be nicer conceptually to cut on the vector of tracks before the fit rather than the unfitted vertex, however this would need a new class of functors. We already have the 'array' class, e.g. APT and ADOCACHI2, but these operate on vectors of Particle objects. We can consider if we want to create a 'track array' class of functors, e.g. ATrPT and ATrDOCACHI2, however today for HLT1 we can use the RecVertex class of functors like RV_MASS and RV_PT to evaluate most (all?) of the selections we'd like, so maybe there's no need for now.

The gross thing here is that the user currently needs to understand this implementation detail to avoid using, for example, the VCHI2 in the pre-fit functor string.

Feedback

I've been testing this locally by plugging it in to the new dataflow configuration in Brunel. It runs and the counters look reasonable (OK, not for an HLT1 line, but the selections are being applied).

TrackCombinerTw...SUCCESS Number of counters : 4
 |    Counter                                      |     #     |    sum     | mean/eff^* | rms/err^*  |     min     |     max     |
 |*"# passed combination cut"                      |     70500 |        456 |(0.6468085 +- 0.03019147)% |
 |*"# passed vertex cut"                           |       456 |        262 |( 57.45614 +- 2.315284)% |
 |*"# passed vertex fit"                           |       456 |        456 |( 100.0000 +- 0.000000)% |
 | "Nb created combinations"                       |        97 |      70500 |     726.80 |     835.98 |           0 |        3540 |

Any suggestions on where to put more permanent tests are welcome, as is all other feedback of course!