In Run-3 offline reconstruction algorithms can be used directly in the HLT without the need for wrapping them into trigger-specific base classes. Typically it is expected that the offline reconstruction algorithms are used in the precision reconstruction step, whereas trigger specific ones are used in the initial fast reconstruction step. An important difference in the trigger usecase is that the reconstruction algorithms are executed only if needed. This is done by embedding them between filter algorithms (control flow) that ensure that algorithms are only executed if the preceding steps passed.
The main tasks in migrating existing trigger code to AthenaMT are:
HLT::FexAlgo to a plain AthAlgorithmget/attachFeature is replaced by
a Read/WriteHandle. See the
MultiThreadingEventDataAccess
for further details.Monitored infrastructureThe consequence of the trigger-specific base class removal, is that there is
no distinction anymore between RoI-based and full-scan algorithms at the class-level.
The area of reconstruction is instead defined by EventViews.
The reconstruction algorithms in the trigger can be executed in two different ways:
In both cases the same reconstruction code can be used. Whether the algorithm
is executed in a view or not depends on the control flow (CF) configuration, i.e.
if it is executed after an EventView maker algorithm creating the views and filling
them with the appropriate input for the reconstruction algorithm.
More can be found in the dedicated section about the views.
The algorithms, once developed, are executed within the complete HLT configuration. However, in the initial development phase it is more convenient to setup a standalone test. Ideally, if the test data file contains the necessary objects that are needed by the new algorithm. Such file (e.g. ESD) can be created by running the HLT trigger or offline reconstruction. If no such file can be created a simplified setup to run on the raw data file containing L1Decoder can be setup. Example of it can be found here for running views.
A good example of a real reconstruction algorithm is the re-entrant (MT ready) fast e/gamma cluster maker algorithm.
The reconstructed objects that are created by algorithms typically need to be recorded following these steps:
recordable function from TrigEDMConfig.TriggerEDMRun3 needs
to be used when setting the name of the collection. It assures that
the naming convention of the HLT EDM is followed.BS, ESD and AOD. Consult the Trigger EDM coordinator if in doubt.MyContainerAux.decor1.decor2).
The type of each decoration needs to be also specified by entering its name in the right section of
TriggerEDMAuxAccessors.h.Once the above steps are done the object should appear in the relevant output files.
For POOL files (ESD, AOD) the content can be checked with one of the following scripts:
checkxAOD.py filename checkSG.py filename checkFile.py filename.
Typically a reconstruction algorithm uses many input data
objects. If one of them is not available the algorithm cannot be
executed and this results in a “stall” reported by the algorithm scheduler.
In that case, the scheduler prints the current state of all algorithms.
Already executed algorithms are listed as SUCCESS.
The algorithm causing the stall is typically in the state CONTROLREADY,
which means the algorithm’s control flow dependencies were satisfied but
the input data is missing. Verify which algorithms were supposed to produce
the inputs and check if it was indeed run.
Debugging missing data in the views can be hinted by the
ViewTestAlg described in the views section of this guide.