Draft: Add PV splitting for vertex resolution studies (primarily BGI)

Adds PVSplitter which takes as input a set of VELO tracks, reconstructs PVs in the event and then splits and re-fits each PV using a specified algorithm for dividing the tracks into two subsets. Also modifies LumiPVs_nobeamline to tuple split-vertex information. Addresses #183.

Example options to test in Moore:

from Moore import options
from RecoConf.decoders import default_VeloCluster_source
from RecoConf.legacy_rec_hlt1_tracking import all_velo_track_types
from RecoConf.config import Reconstruction, run_reconstruction
from PyConf.application import make_odin, default_raw_banks, default_raw_event
from PyConf.Algorithms import HltRoutingBitsFilter, LumiPVs_nobeamline, PVSplitter
from PyConf.reading import get_decreports

default_raw_event.global_bind(stream="beamgas")

def make_reconstruction():
    phys_filter = HltRoutingBitsFilter(
        RawBanks=default_raw_banks('HltRoutingBits'),
        RequireMask=(0x0, 0x0, 0x80000000)
        )
    algs = []
    for splitalg in ['random', 'byvelohalf', 'equalvelohalf', 'bytopbottom', 'equaltopbottom']:
        pvsplit = PVSplitter(
            InputVeloTracks=all_velo_track_types()['v1'],
            SplitMethod=splitalg
            )
        tuple_maker = LumiPVs_nobeamline(
            name=f'PVs_{splitalg}',
            ODIN=make_odin(),
            InputPVs=pvsplit.OutputPVs,
            InputSplitPVs1=pvsplit.OutputSplitPVs1,
            InputSplitPVs2=pvsplit.OutputSplitPVs2,
            InputHlt=get_decreports('Hlt1')
            )
        algs += [pvsplit, tuple_maker]
    return Reconstruction("BeamGasTuple", algs, [phys_filter])

options.input_files = ['root://xrootd.echo.stfc.ac.uk//lhcb:prod/lhcb/LHCb/Vdm24/BEAMGAS.DST/00242987/0000/00242987_00005402_1.beamgas.dst']
options.ntuple_file = 'split_pvs.root'
options.input_type = 'ROOT'
options.evt_max = 100
options.geometry_version = 'run3/2024.Q1.2-v00.00'
options.conditions_version = 'master'
options.simulation = False

with default_VeloCluster_source.bind(bank_type="VPRetinaCluster"):
    run_reconstruction(options, make_reconstruction)

To do before un-drafting:

• Get things building against master
• Test PVSplitter runs and produces some output
• Test PVSplitter produces sensible output. Probably the easiest way to do this is to run over a reasonable sample of BGI vertices, and check the resolution de-convolved bunch width is approximately stable along z/with changing ntracks
• Add reco options in separate MR to Moore, alongside/to replace pvreco_beamgasstream_tupling_vdm_2024.py?

cc Lumi conveners @efranzos @vazhovko @elniel @fferrari

added RTA label

I just want to point out that the nominal vertex resolution monitor is here:

https://gitlab.cern.ch/lhcb/Moore/-/blob/master/Hlt/RecoConf/python/RecoConf/track_data_monitoring.py#L141

this run in Monet for the pp region and splits tracks too.

Maybe your needs are some special and you cannot use this particular approach, but it would be good to understand if they diverge, and if so, why itd.

Hi Agnieszka, thanks for pointing this out; I was aware of this, so I should probably have explicitly mentioned in the MR, apologies.

There are two main differences here:

1. Allowing more configuration of how the tracks are split
2. Explicitly vetoing both split vertices and the combined vertex if either of the split vertex fits fail, and preserving 100% efficiency for matching the split vertices

Of course, the first point is a non-issue and could be addressed with the existing tool by simply writing a modified version of RandomVeloTrackContainerSplitter using the desired splitting.

The second point however would be my reason for preferring this approach. In the Run 2 BGI analysis we have already found biases from the split-vertex method at the percent level that we don't fully understand, and which currently contribute the largest systematic. Therefore, I'd strongly prefer to avoid introducing other potential sources of bias to the method. In particular, I wonder if/how that matching efficiency depends on z-position, beam-gas vs beam-beam, number of tracks etc, and how this would affect things. I don't immediately see a way to ensure this in the other approach, but of course let me know if you think it's possible, or whether you think this is a valid reason for diverging.

Hi Nial,

To add to the second point, it is possible to ensure that vertices are vetoed if they are not matched. The only missing component is an additional tool, similar to VertexCompare. This tool would first match vertices from two subsets based on their z-position and then further match them with the combined vertex using the average z-position of the subset.

If any of these matching steps fail, the combined vertex and the two corresponding subset vertices should be removed from the input containers. Once this tool is in place, all previously implemented monitoring scripts can be used without modification.

Hi @nmchugh

As far as I know the RandomVeloTrackContainerSplitter is flexible enough to allow for any kind of splits. Also the splitter for Allen tracks

velo_tracks_RS1, velo_tracks_RS2 = make_velo_tracks_ACsplit(
        decoded_velo, split_alg="random"
    )

is flexible enough to accommodate other types of the split following implementation by @bokutsen @dovombru

Saying that I do not know which method has been used in Run2 BGI analysis, however I want to point out that the same method is used for the SMOG as for the pp region. Of course on Monte Carlo we can use PrimaryVertexChecker to validate the procedure with respect to the VertexChecker. You can look at the plots prepared by @samarian for https://arxiv.org/pdf/2412.14966 (Fig.11 and Fig.12 right) get some feeling how the resolution looks for beam-gas and low multiplicity. Last year, we also made some preliminary studies to get the z resolution on data for SMOG using the VertexCompare, but these studies were not concluded due to lack of time.

I think I would be interested to test whether two methods actually diverge, as I believe we all can learn from each other and improve our overall understanding of the methodology we are using. I also believe the more coherent we are in our choices, the better so that we can compare easily the resolution on SMOG, pp etc, while introducing new methods there is always a risk that we then compare apples with oranges. Anyway, I am happy to see your MR, and if I find time, I would more than happy to learn more and digest into it.

It sounds like a presentation and discussion in a WP4 meeting could be useful to understand the limitations of the exising vertex resolution method and whether it can be extended or a new tool is really needed.

Any thoughts @freiss @poluekt ?

I anyway owe the talk @freiss and @poluekt with the PV resolution for 2024 data, so I can summarize also my studies from November.

Here are some proof of concept slides from today's meeting with some studies we did on SMOG:

https://indico.cern.ch/event/1495987/contributions/6429500/attachments/3035482/5360352/2025-03-18-PVResol-2024.pdf

Thanks for the link @adudziak, unfortunately I could only connect later to the WP4 meeting yesterday, so I missed the discussion on your presentation. Was there a conclusion on the tools for SMOG / BGI use cases?

@dovombru @nmchugh was not there, so we didn't have much discussion, thus I linked slides for their information. The only thing is that we see SMOG data in our NTuples for block1 and block5 and @samarian said he would be happy if we had a look at these data, so we plan to obtain some resolutions from data.