Track pairing for secondary vertex reconstruction based on particle energy

[dudarboh]

Dear experts,

I have tried to check performance of the vertex reconstruction, assuming perfect pi/K/p ID for my PFO objects, updating their mass and energy parameters accordingly.

Looking at the vertices with low momentum protons, I have noticed, that after updating mass and the energy of the PFOs, number of reconstructed vertices has reduced significantly! (see number of entries in red vs black histograms)

Debugging this issue, I found out that the algorithm which is responsible for creating secondary vertices uses a cut based on the PFO energy to accept/reject pairs of tracks to form a vertex:

https://github.com/lcfiplus/LCFIPlus/blob/8a4629883c1e1b8baef1feb2b6871859ecdda735/src/VertexFinderSuehara.cc#L447-L453

which is with default steering parameters is: (v1+v2).M() > min(v1.E(), v2.E())

Could somebody explain the motivation of this cut? What is its impact of this cut on vertex reconstruction? Is it necessary? Does it properly works with any mass parameters in mind?

I would naively expect that vertexing algorithm should work only with the track information (e.g. d0, z0, momentum, etc.). So I am puzzled to see energy cut here. It means that two different particles (types) with identical tracks (and momentum) might get a very different cut to reject a vertex.

And as my study shows, providing PFOs with kaon or proton mass rejects too many "good" vertices.

And here is one particular example, where vertex reconstruction goes wrong because of this cut:

@suehara

cheers, Bohdan

[suehara]

Sorry I missed your post and thank you for reminding me. I think the cut reduces fakes as Masakazu pointed out, but only assuming the mass of each particle (assuming pion) is negligible. Maybe it's good to change it for kaons. However we do not want to change the default behavior since it is already widely used. We may think of adding an option to do it, like treating each particle massless (or keeping backward compatibility assuming pion mass any time).

Would you try to switch it off (or fix it with pion mass) temporary in your repository and check if the efficiency would be recovered? If confirmed we would think of adding an option.