Basic HLT2 persistency
This builds on top of !317 (merged) to add persistency for LHCb::Particle
objects created by HLT2 lines, towards LBRTAPLAN-140.
The logic is inspired by that in the old Run 2 HltAfterburner
implementation; I haven't taken much effort to improve the general flow because there's so much work to do on the Run 3 persistency in general I figured there was little point in making the old stuff nicer.
Using the changes here I'm able to create ntuples in DaVinci (using DecayTreeTuple
) from an HLT2 output file. There's a tutorial file included that explains how to do this.
@sgweber added a test that checks the output file contains associated Particle
objects in every event a given trigger line fires.
Assumptions
- All outputs (the final algorithm in each
HltLine
definition) are containers ofLHCb::Particle
objects. - The outputs are created by
DVAlgorithm
algorithms. - The HLT2 output is being written to a DST.
- The HLT2 reconstruction comes from the file (i.e. from Brunel).
These are all met by the current HLT2 line development flow, but will require revisiting once we're able to run the reconstruction on the fly.
Supported functionality
- Saving line candidates and associated objects
- Pretty similar to the information made available in Run 2, but see 'Unsupported functionality' below.
- Saving
LHCb::Particle
containers created by 'extra selections' on HLT2 lines- Enabled by the new
extra_outputs
property on theHltLine
object. This isn't an ideal extension of the API because in principle HLT1 lines can now declare these, but nothing will be done with them.
- Enabled by the new
Unsupported functionality
- Writing objects in the CALO event model 'above' the
CaloHypo
(i.e.CaloCluster
,CaloDigit
, and ADCs).- These are not persisted by Brunel, so if we wanted to persist them we'd first have to create them.
- Writing clusters associated to tracks.
- The track cluster cloner only supports Run 1 subdetectors.
- Saving the full HLT2 reconstruction a.k.a. PersistReco.
-
Can't use the output for bandwidth studies asInputCopyStream
is used, so all input data is copied to the output (for events which pass HLT2).- No longer using
InputCopyStream
due to its dependence on incidents. UsingOutputStream
instead, and hard-coding assumed input locations to be propagated to the output.
- No longer using
Depends on
gaudi/Gaudi!1010 (closed) to be able to run theInputCopyStream
algorithm (see gaudi/Gaudi#102).- Phys!624 (merged) to be able to instantiate the CALO digit cloner (even though it won't find any digits).
-
Phys!625 (merged) to be able to use
ToolHandle
s for the line output cloner. -
Phys!694 (merged) to patch the
CopyLinePersistenceLocations
algorithm for correctToolHandle
behaviour (see gaudi/Gaudi#116 for details)