Main luminosity line

Logically, the main luminosity line has the following flow

1. Select all events with the appropriate ODIN EventType bit (Lumi).
2. Run (independent instances of) the relevant reconstruction.
3. Compute counters based on the reconstruction output. All counters must be produced for every event, even if reconstruction "failed" (e.g. due to a mandatory GEC for PbPb).
4. Write counters into a HltLumiSummary raw bank (no bank when there's no lumi trigger).

In some cases it might be necessary to have more than one luminosity lines. They will only differ in the ODIN selection and scaling, whereas the computation of counters (including the necessary reconstruction) must be identical. When two lumi lines fire in the same event, the counters would be recorded only once in the output raw bank.

There are two fundamental properties that HLT1 must respect (as any other part of the data flow):

1. The decision to accept a lumi trigger does not depend on the activity in the event.
2. Any unintended loss (e.g. an application crash) must lead to an identical inefficiency for physics and lumi triggers.

The things that need to be done for a minimal functional skeleton are:

1. Create a new minimal sequence with the luminosity line or extend the physics sequence.
   • The dedicated reconstruction algorithms producing the lumi counters and subsequently the HltLumiSummary raw bank writing need to run only for events where the ODIN EventType::Lumi bit is set.
   • Configure at least the VELO reconstruction (without GEC) and corresponding PV finding. With this we demonstrate that (at least parts of) the reconstruction can be configured independently of the main reconstruction for physics lines.
   • Since the multi-event scheduler (!429 (merged)) is ready to use, we can directly integrate the lumi line (with its dedicated algorithms) into the main physics sequence.
2. Write (an) algorithm(s) (host or device?) to access the number of reconstructed VELO tracks, the number of PVs (both total per event and after a fiducial cut).
3. Collect the output of the new algorithm(s) and put them in a new raw bank of type HltLumiSummary.
4. Make the decoded HltLumiSummary object available when running Allen from Moore.
5. Setup a test similar to the existing test_hlt1_lumi_minbias.qmt in Moore. If the lumi lines are not implemented in the default sequence, this test is going to be disabled in the nightly builds (see #215 (closed)).
   • use ODINEmulator to rewrite the ODIN bank such that there are some events with the expected event type
   • check that the number of produced raw banks is as expected
   • configure a dedicated lumi monitoring algorithm (#222) and add some test validation that checks the lumi counters
6. Once we support multiple sequences (#215 (closed)), add a lumi-only sequence to the build and adapt the test.