Reconstruction Algorithms

• Introduction
• Features of reconstruction algorithms
• Reconstruction in whole event or in event fragment
• Testing
• Examples
• Saving EDM objects
• Troubleshooting

Introduction

Unlike earlier, 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 use-case 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. Other difference is that the algorithm instances may be executed multiple times per event in EventViews (briefly mentioned later).

Features of reconstruction algorithms

1. It is required that the algorithms used by HLT are reentrant, that is inherited from AthReentrantAlgorithm. In practice this means that the execute method does not modify any state variable of the algorithm itself.
2. The I/O of data items needed by the algorithm is done identically as in offline case and is documented here MultiThreadingEventDataAccess.
3. Access to conditions data needs to be migrated following MultiThreadingConditionsAccess
4. Monitoring histograms should be migrated to the new thread-friendly Monitored infrastructure
5. The algorithm should be typically associated with a python configuration fragment as is the case all components.

Reconstruction in whole event or in event fragment

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

1. for the full event as it is the case for regular offline reconstruction
2. and within EventView (regions) 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.

Testing

The algorithms, once developed, are executed within the complete HLT menu configuration.

Examples

A good simple example of a real reconstruction algorithm is the re-entrant (MT ready) fast e/gamma cluster maker algorithm.

Saving EDM objects

If the reconstructed objects that are created by algorithms need to be recorded in the output file these steps should be followed:

1. contact trigger EDM coordinator found on trigger Core s/w twiki
2. 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 and no trivial typos sneak in between name of the container .
3. The collection (type and name) has to be listed in TrigEDMConfig.TriggerEDMRun3 together with the required output file types in which it should be recorded. Typically the object should be stored at least in BS, ESD and AOD. Consult the Trigger EDM coordinator about this. Especially about the AOD formats where the size is constrained.
4. 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.
5. 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: checkxAOD.py filename checkSG.py filename checkFile.py filename.

Troubleshooting

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.

---