WIP: [PRChecker] Change logic of counting visible tracks from PV

It is suggested here to change the logic of counting the number of tracks from a PV in PrChecker. Currently all tracks that have a Velo segment are counted for nbVisible, i.e. as tracks contributing to the PV. This would also include secondary tracks that have a Velo segment.

The implementation here would only count tracks that come directly from the PV. This might not be the best way to do it either. The MR is rather intended to open a discussion on the subject.

/cc @adudziak @twojton @msokolof

It's probably not as easy as this. I had a look today in a different context and saw that the number of tracks from part->originVertex() == vertex is far less than for example (part->primaryVertex()->position()-vertex->position()).mag2()<1e-6 && trackInfo.hasVelo(part) && part->p()>100*Gaudi::Units::MeV, which is similar to https://gitlab.cern.ch/lhcb/Rec/blob/master/Tr%2FPatChecker%2Fsrc%2FPrimaryVertexChecker.cpp#L949

Attached is a file that compares the two conditions running on 40 events of minbias MC for the data challenges (https://gitlab.cern.ch/lhcb-datapkg/PRConfig/blob/master/python/PRConfig/TestFileDB.py#L1285-1375). In the plot, vincinity means

(vertex->position()-part->originVertex()->position()).mag2()<1e-6 && trackInfo.hasVelo(part) && part->p()>100*Gaudi::Units::MeV

and equality

vertex== part->originVertex() && trackInfo.hasVelo(part) && part->p()>100*Gaudi::Units::MeV

nprompt.pdf

assigned to @mstahl

So what's the plan for this MR? :) still WIP?

marked as a Work In Progress

changed the description

changed title from WIP: Change logic of visible tracks from PV to WIP: [PRChecker] Change logic of counting visible tracks from PV

changed the description

mentioned in issue #132 (closed)

closed