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.