Event Filter TrigMuonEF documentation

Introduction

A distinctive feature of the ATLAS Event Filter (EF) is the use of offline reconstruction and analysis algorithms within the TDAQ framework. The EF normally runs after LVL2 trigger algorithms as shown in the following picture. The EF feature extraction algorithms (FeX, in yellow) use information from the indicated detectors (in pink) in order to reconstruct muon segments, combine them into tracks, extrapolate tracks to interaction vertex, and combine them with inner detector (ID) reconstructed tracks.

The offine packages ``Muon Object Oriented REconstruction'' (MOORE) and ``MuonIdentification'' (MuId) have been developed in the ATHENA framework for the purposes of muon reconstruction and identification in ATLAS. The former performs track reconstruction in the Muon Spectrometer while the latter extrapolates the track to the interaction point (MuId Standalone) and combines the muon and Inner Detector track segments (MuId Combined). All this offline packages are now written as tools and the wrapper for these tools is called TrigMuonEF. For reference, the previous implementation of the muon trigger using offline algorithms, it was called TrigMoore. The TrigMuonEF package is divided in four FeX algos that perform the different tasks: TrigMuonEFSegmentFinder, TrigMuonEFTrackBuilder, TrigMuonEFExtrapolator, TrigMuonEFCombiner.

Interfaces / Data sources

The detector data access is entirely performed at the first step: TrigMuonEFSegmentFinder. It can be seeded by LVL1 or by LVL2. The standard behaviour, LVL2 seeding, is activated when a TrigRoIDescriptor, attached with a key "forMS" to the TriggerElement, is found. Currently the LVL2 algorithm muFast update the TrigRoIDescriptor with this key. In case this key is not present, the TrigRoiDescriptor is got from LVL1. This can happen when LVL2 is not running, as an example.

The TrigRoIDescriptor is used to found the η,φ region of the RoI. Then the RegionSelector is used to found the DetHashIDList for each technology (RPC,CSC,MDT,CSC). The hash IDs are then decoded to PrepRawData. Optionally the decoding of the whole event, not only within the RoI, could be performed. This was the default until the development of tools for data access. Enabling the data decoding for the current RoI only can be done setting to true the flag doEFRoIDrivenAccess. Currently (TrigMuonEF-00-00-52) this is not yet enabled for CSC technology.

There is not a "full scan" flag, but the full scan could be requested by setting at 3.0 the Δη, Δφ around the RoI center.

Description of the algorithm

First are reconstructed the segments through TrigMuonEFSegmentFinder, then segments are combined into tracks within TrigMuonEFTrackBuilder. Tracks are extrapolated to the vertex in TrigMuonEFExtrapolator. Finally the extapolated tracks are combined with inner detector tracks with TrigMuonEFCombiner. At each step is possible to perform checks on the parameters of the reconstructed object in order to stop the chain processing using hypothesys algorithms. In the following schema is possible to recognize on the left the TrigMuonEF wrappers and on the right the offline tools invoked.

Between two TrigMuonEF FeX there is a corresponding TrigMuonEFHypo that uses the previous information collected in order to do the selection. With the last tag of TrigMuonHypo (TrigMuonHypo-00-00-87) there are implemented TrigMuonEFTrackBuilderHypo, TrigMuonEFExtrapolatorHypo and TrigMuonEFCombinerHypo. By default they are in AcceptAll mode. If suitably configured, they select only muons that have pT over a given threshold. As an example in this way

TrigMuonEFCombinerHypoConfig(lvl2Conf,thresholds[sig_id][2])

the TrigMuonEFCombinerHypo is configured to use the same thresholds that were used for TrigMooreHypo. In this case a cut on the combined muon pT is applied. Note that currently dedicated thresholds for TrigMuonEFTrackBuilder and TrigMuonEFExtrapolator need to be defined.

In the picture it is also shown that the Event Filter starts from Inner Detector algorithms. This is true for the current (TriggerMenuPython-00-02-20) implementation of Muon.py.

The heart of TrigMuonEFSegmentFinder is the findSegment call of the offline tool MooSegmentCombinationFinder Input are the pointers for the per-detector PrepDataCollection, while the output are pointers to the resulting MuonSegmentCombinationCollection, MuonPatternCombinationCollection and Trk::SegmentCollection. These collections are attached to the TriggerElement for subsequent use. For debug purpouses it is possible to activate, via the variables recordSegmentCombinations and recordPatternCombinations, the writing into StoreGate of the MuonSegmentCombinationCollection, MuonPatternCombinationCollection. In the following table are reported the keys used to store the containers.

The TrigMuonEFSegmentFinder configuring variables are collected in the following table. The default values are taken from the initialization value in the constructor. These values can be overwritten in the python class TrigMuonEFSegmentFinderConfig in TrigMuonEFConfig.py or TrigMuonEFCosmicConfig.py. The variables of type useXXXData get their values from the muonRecFlags used also in reconstruction jobs.

In TrigMuonEFSegmentFinderConfig it is also possible to change the values of the tool MooSegmentCombinationFinder and of the subtools invoqued by it. In particular the following properties are set, in order to avoid StoreGate writing in trigger algorithms:

The configuration for running on cosmic events is different.

-- SergioGrancagnolo - 30 Sep 2008