Remove hard limits on PV reconstruction

The current PV reconstruction relies on several hard-limits, namely: max_number_vertices, max_number_subclusters, max_number_of_clusters and max_number_clusteredges (see https://gitlab.cern.ch/lhcb/Allen/-/blob/master/device/PV/beamlinePV/include/PV_Definitions.cuh#L10). It would be desirable to remove all these limits in preparation for production, to minimise the risks of overflowing a buffer relying on these.

There are several techniques that can help with the removal of these limits, for that see the following discussion: !764 (comment 5232352)

assigned to @freiss

mentioned in merge request !764 (merged)

assigned to @thboettc

I wanted to bump this issue because we're having issues with this in PbPb MC in events with large numbers of fake PVs. It looks like this is probably an issue with the beam conditions used to create the MB PbPb sample, but it'd still be nice if Allen didn't just crash on these pathological events.

Thanks @thboettc

@freiss would you have some time to look at this?

I'm going to have a look over the weekend, at least to understand how much effort this actually would take

thanks!

@thboettc could you tell me how to run over the PbPb sample?

You can find an old file with incorrect beam conditions here: /eos/lhcb/wg/rta/samples/mc/upgrade-202004-PbPb-EPOS-b-6_14fm/all_Gausstest_MB.mdf. Some of these events end up producing a lot of fake PVs. There are some new xdigi files here: /eos/lhcb/wg/IonPhysics/Simulations/PbPb_MB_EPOS_Upgrade. These have the correct beam position and could potentially fix the issue, but I haven't had a chance to test them.

The sequence I've been using for testing is here: https://gitlab.cern.ch/lhcb/Allen/-/blob/ift_rta_workshop/configuration/sequences/hlt1_PbPb_veloSP.py, but I guess what you really need for testing is a PV sequence with no GEC and no retina banks.

mentioned in merge request !925 (closed)

I created !925 (closed) to at least try to avoid crashing when these limits are exceeded. This is done by overwriting the array with peaks, PVs, etc from the beginning when the limit is met, so this is only a temporary solution.

I also added contracts to the PV finding to make it easier to spot such cases

@freiss @mgiza @adudziak a good one to keep in mind when reoptimising the PV finding