Skip to content

How to deal with Particle-PV association

We have a lot of discussions on how to deal with the PV associated to a long lived particle, typically a B. Let's write them down here, so we can make a decision once for all.

A few observations on how it is done in legacy software:

  1. The first time a cut is applied on a quantity that requires a single PV, like a lifetime or DIRA, the IRelatedPVFinder tool of IDVAlgorithm is called.
  2. Then a single "best" PV is assigned to the B and kept throughout the chain. It is saved in a P2PV map in DVCommonBase, which can be stored on the TES (default: true).
  3. Any subsequent point cut is applied wrt this best PV

In principle the candidate is a pair (B,PV). There could be another pair (B,PV') that also satisfies all selection cuts. It is not possible to perfectly predict at early stages of the selection which pair will pass the final MVA selection. To my knowledge the effective lifetime of Bs->J/psiKs https://arxiv.org/abs/1304.4500 and subsequent papers are the only ones who passed all (B,PV) pairs through the chain consistently. It is a very small effect, 0.1% according to LHCb-ANA-2012-049. It may become a larger issue as there are more PVs and more ambiguities in Run 3.

The new event model may give us the opportunity to revise that at low (zero?) CPU cost in HLT.

  1. The association between candidate and PV must be stored in a Relations table. It's a typical case of @graven's talk here.
  2. This Relation table will store several compatible PVs per B candidate, according to some criterion.
  3. Each time a pointing-style cut is applied, some pairs (B,PV) get killed.
  4. Once no pair is left the B is killed to as there's no remaining good PV left.
  5. There should be a way for this to be parallelised: You apply the same cut to all elements of the table. However I don't know how this would like like in the Relations table. Will it be updated? Will elements be removed?

(Side note on a very similar situation: In very early LHCb days around 2003 we had the concept of best PID, assigning the hypothesis with the largest DLL to a particle. It was killed because a genuine B->pipi candidate could be killed if a pion was decaying in flight. The muon hypothesis was then better and so the particle was no longer a pion.)

In the end it's a CPU versus physics problem, where physics is not only efficiency but also bias. This issue should not slow down the HLT significantly.

Tagging @gligorov @graven @mvesteri @erodrigu @mveghel . Please add more.

Discuss.