Reconstruction Algorithms

Last update: 05 Jul 2023 [History] [Edit]


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.

Migration of existing HLT algorithms

The main tasks in migrating existing trigger code to AthenaMT are:

  1. Migrate HLT::FexAlgo to a plain AthAlgorithm
  2. Reading/writing of trigger features via get/attachFeature is replaced by a Read/WriteHandle. See the MultiThreadingEventDataAccess for further details.
  3. Access to conditions data needs to be migrated following MultiThreadingConditionsAccess
  4. Monitoring histograms should be migrated to the new thread-friendly Monitored infrastructure

The 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.

Reconstruction in views

The reconstruction algorithms in the trigger can be executed in two different ways:

  1. for the the full event as it is the case for regular offline reconstruction
  2. and within a “view” (region) of the event.

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.

Saving EDM objects

The reconstructed objects that are created by algorithms typically need to be recorded following these steps:

  • in the python configuration of the algorithm an instance of the 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.
  • The collection (type and name) has to be listed in TrigEDMConfig.TriggerEDMRun3 together with the required output formats. Typically the object should be stored at least in BS, ESD and AOD. Consult the Trigger EDM coordinator if in doubt.
  • Ensure that in HLTEDMCreator.h and .cxx the type that you intend to record is listed. If not, it needs to be added following the recipe in the header file.
  • Decorations can be added to the output by specifying them in the Aux container entry, separated by dots (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: filename filename 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.