GenerateTriggerFcl

Intro

In this page, we organized the info needed to generate and run a Trigger executable within the Mu2e Offline. All of this is a working progress and we encourage the users to provide us with comments and feedback.

How to generate and run a Trigger executable

The Mu2e offline provides a dedicated python script Trigger/scripts/genTriggerFcl.py that allows the user to generate an fcl starting from a trigger configuration file. Examples of config file can be found on Trigger/scripts/inputs directory. The configuration file allows the user to set a general event prescale factor and also a second prescale factor that is applied to the good events.

caloCosmicMuon 10 100
tprDeMSeed
cprDeMSeed
...

To run the python script, you need to use the following command:

python Trigger/scripts/genTriggerFcl.py -c myInput.config -o myTrigFcl.fcl 

where myInput.config contains the list of the trigger paths you want to include in the fcl, together with their prescale factors if needed, myTrigFcl.fcl is the name of the file that will be generated by the script. By default, the generated fcl will include also the ReadTriggerInfo module in the output path; this module is a useful tool that provides summary info of the Trigger results.

In case you want to generate an fcl to be used in the Online environment, one needs to add an option in the previous python command line:

python Trigger/scripts/genTriggerFcl.py -c myInput.config -o myTrigFcl.fcl -t Trigger/scripts/main_online.fcl

Trigger paths available

The simplest way is to run the python script with the help option:

python Trigger/scripts/genTriggerFcl.py -h

In the following we report the list of the currently available trigger paths:

Physics triggers

In this category, we consider the trigger paths designed for selecting Conversion Electron and Conversion Positron signals together with their side-bands. We have 4 different track-based trigger paths:

tprDeMSeed
tprDePSeed

corresponding to those paths that use the Tracker-only pattern recognition. "DeM" and "DeP" refers to the two searches: downstream electron and positron. The other two:

cprDeMSeed
cprDePSeed

corresponding to those paths that use the calorimeter-seeded pattern recognition. All these track trigger paths apply filters at each stage of the online reconstruction: (1) TimeCluster-search, (2) Helix-search (pattern recognition) and (3) Track-seed fit.

Then we have the calorimeter-only trigger, that has been optimized only for the Conversion Electron search:

caloOnly

Support triggers

In this category belongs the skeleton of the unbiased and minimum bias triggers that have been developed so far. All the following triggers will operate with pre-scale factors > 1. There is no study yet that demonstrated the required pre-scale factors. More likely, the pre-scale factors will be set in a way that the required impact on the total bandwidth will be less than 10%:

• unbiased: random trigger based on the event-id;
• minimumbiasSdCount: events with a minimum number of reconstructed StrawDigis (digitized output from the Tracker's digitizers). The threshold value is set below the expected average StrawDigi counts;
• largeSdCount: events with a minimum number of reconstructed StrawDigis set pretty higher than the expected average. This Trigger might be quite useful for spotting panels in the Tracker that, due to the noise or other factors, are digitizing more hits than expected;
• minimumbiasCdCount: events with a minimum number of reconstructed CaloDigis (digitized output from the Calorimeter's digitizers). The threshold value is set below the expected average CaloDigi counts;
• largeCdCount: events with a minimum number of reconstructed CaloDigis set pretty higher than the expected average. This Trigger might be quite useful for spotting regions in the Calorimeter that, due to the noise or other factors, are digitizing more hits than expected;

Changes needed to perform timing tests

One of the fastest ways to benchmark the timing performance of the Trigger executable is to run it in the Offline environment but to get the info in a useful way the user needs to include at the begging of the Trigger path (before the trigger sequence) the instance of the module that fetches the digis. The fetching of the input data is an operation quite time-expensive that over-estimates the unpacking process that will happen in the Data Transfer Controller board (DTC) in the DAQ servers.