Partial event building in athenaMT HLT

Background

Partial event building allows to save a subset of detector data in a given stream. In order for HLT to inform the TDAQ infrastructure of this subset, a list of ROB and/or SubDetector IDs has to be attached to the corresponding StreamTag in the HLT output. The list can be constant (e.g. all data from the RPC detector) or dynamically generated per event based on event properties (usually based on RoIs processed by the corresponding HLT chains). Empty list of ROBs/SubDets in a StreamTag signalises full event building to the TDAQ infrastructure. A special case of PEB is "data scouting", i.e. saving only a special small HLT result and no detector data in the stream. In this case, there is one "ROB" in the list - the one containing the special HLT result. Both features were used successfully in Run 2. It should be also possible (but wasn't in Run 2) to save the special HLT result and a subset of detector data in a stream.

Implementation overview

The implementation is not too different from Run 2. To create an HLT chain producing PEB output, we add a chain step (typically as the last step), which produces a list of ROBs and/or SubDets for PEB. When processing the final HLT decision and producing the output, the PEB information is collected from all chains and attached to their corresponding StreamTags.

To adapt this idea to the new framework, I created a Hypo algorithm which produces pass-through decisions with attached PEB information. PEBInfo is attached as a TrigComposite Detail (with decision->setDetail(...)). Only one Hypo alg class is needed. It uses dedicated AlgTools to create and attach the PEBInfo. The tools share a common base class and can be implemented depending on the specific needs of the users. Most use cases will be covered by a static PEBInfo writer adding the same ROBs/SubDets to all events (implemented in this MR), and a generic RoI-based PEBInfo writer translating RoIs into ROB IDs using the region selector (not yet implemented).

The information is collected from the decisions and translated into StreamTags in the StreamTagMakerTool. Based on the trigger menu, the StreamTagMakerTool is informed at configuration about chains producing PEBInfo and the StoreGate keys of their decisions. At runtime, it reads all these decisions and creates chainID->PEBInfo map for each event. Then it iterates over the passed chains and looks up the corresponding PEBInfo, attaching it to the corresponding StreamTag.

Implementation details

New package

I added a new package TrigPartialEventBuilding which supersedes TrigDetCalib, where Run-2 PEB algorithms were defined.
TrigPartialEventBuilding defines the following classes:
PEBInfoWriterAlg - the Hypo algorithm which produces pass-through decisions with attached
PEBInfoWriterToolBase - the base class for AlgTools, implements the method attaching PEBInfo to the decision
StaticPEBInfoWriterTool - the simplest concrete implementation of the tool, attaches the same PEBInfo to all events
In future, it will include also other concrete implementations suited for specific needs of the clients

Making StreamTags

I adapted the StreamTagMakerTool to do what I described above. I redefined the ChainToStream property, which now maps chain name to a StreamTagInfo tuple {name, type, obeysLumiBlock, forceFullEventBuilding}. The last value serves as a protection suggested by @wiedenma to avoid a situation where a chain associated with physics_Main produces a PEBInfo and the full event data is lost. It should be "True" for Main and all other full-event streams, and "False" for PEB streams.

Testing and menu integration

I created a new test in TrigUpgradeTest - test_peb.sh running the pebTest.py job options. This is basically a fullMenu test, but with a few PEB chains defined. In order to integrate PEB in the menu, I had to create a MenuSequence which consists of a pass-through InputMaker (output=input), one instance of PEBInfoWriterAlg and some (in my case one) PEBInfoWriter tools for the alg. I'm not sure if the InputMaker is needed at all, but I didn't know how else to define a ChainStep with just a hypo.

A single PEB "strategy" means one particular configuration of PEBInfoWriter tools in the sequence. There can be many chains using one strategy. In practice one strategy usually corresponds to one stream, but it doesn't have to. I implemented two example strategies (and streams) pebtestone and pebtesttwo. I then defined three electron chains - one standard chain and two PEB chains writing some LAr ROBs to the pebtestone stream. I also added two muon chains - one standard chain and one writing full RPC data to the pebtesttwo chain. I had to make a minor modification in TrigEgammaHypo/TrigL2CaloHypoTool.py to prevent the Egamma configuration from parsing the pebtestone keyword as an Egamma tool option in the electron+peb chains.

Important note: in order to make different PEB strategies possible, each strategy needs its own instance of the PEB sequence (chain step) with unique names of its elements. Furthermore, the same instance cannot be used in different step numbers (e.g. step 2 of one chain and step 3 of another). This would lead to a stall in execution, because the algorithm instance would be waiting for inputs which can be only given in the subsequent step, but couldn't proceed to the next step without producing an output.

Status

• All basics in the offline code are implemented, the test is running and producing HLTResultMT with correct StreamTags
• The online framework testing options TrigExPartialEB/MTCalibPeb.py have been adapted and run well with athenaHLT producing output BS files with correct information in the stream tags
• The code is fully functional and all ctests pass, except for NewJO where the failure is unrelated to this MR
• Still need to fully implement data scouting as the next step - will be done in a subsequent MR
• Tagging @wiedenma, @smh, @tbold, @tamartin, @bernius, @fpastore - please comment and feel free to add more people

JIRA: ATR-19360