TriggerDevelopment: Difference between revisions
No edit summary |
|||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 6: | Line 6: | ||
==What to do for creating an additional trigger path== | ==What to do for creating an additional trigger path== | ||
So far, the Physics trigger filters that have been developed rely on the info from the calorimeter reconstruction or the tracking one. The filters that use only the calorimeter reconstruction are in the directory <code> | So far, the Physics trigger filters that have been developed rely on the info from the calorimeter reconstruction or the tracking one. The filters that use only the calorimeter reconstruction are in the directory <code>CaloFilters</code>, while those that use the info from the tracking reconstruction are in <code>TrkFilters</code>. For both cases, the filters default instances and the sequences definition are in the <code>fcl/prolog_trigger.fcl</code> file under the respective directories. The "general" filters, like the pre-scale filter and the minimum-bias filters, are housed in the <code>Trigger</code> directory. | ||
In case the new filter module does not belong to one of these three categories, we will need to create a new one accordingly, so it is better to discuss it in the Trigger meeting. Then next two important steps are: | In case the new filter module does not belong to one of these three categories, we will need to create a new one accordingly, so it is better to discuss it in the Trigger meeting. Then next two important steps are: | ||
<ul> | <ul> | ||
| Line 15: | Line 15: | ||
<li>include in the <code>Trigger/fcl/templates.fcl</code> file the new <code>prolog_trigger.fcl</code> file.</li> | <li>include in the <code>Trigger/fcl/templates.fcl</code> file the new <code>prolog_trigger.fcl</code> file.</li> | ||
</ul> | </ul> | ||
</ul> | |||
It is important to note that in all the trigger sequences defined so far, we have been including two event pre-scale filter instances at the very beginning and at the very end. In this way we have an handle to eventually reduce the number of times the sequence is run and/or pre-scale on the group of "good" events selected by the filter. | |||
Latest revision as of 20:32, 3 May 2019
Intro
In this page, we present our current set of tools you can use to test the Trigger executable in the offline and online environments. We also provide some guidance the user should look at if he/she wants to develop a Filter module for the Trigger Menu.
Run the Trigger executable
The best way to run Trigger jobs is to generate your own fcl file using the script GenerateTriggerFcl. Our current best example of the full Trigger menu is implemented in the fcl Trigger/fcl/runGlobalTrigger.fcl.
What to do for creating an additional trigger path
So far, the Physics trigger filters that have been developed rely on the info from the calorimeter reconstruction or the tracking one. The filters that use only the calorimeter reconstruction are in the directory CaloFilters, while those that use the info from the tracking reconstruction are in TrkFilters. For both cases, the filters default instances and the sequences definition are in the fcl/prolog_trigger.fcl file under the respective directories. The "general" filters, like the pre-scale filter and the minimum-bias filters, are housed in the Trigger directory.
In case the new filter module does not belong to one of these three categories, we will need to create a new one accordingly, so it is better to discuss it in the Trigger meeting. Then next two important steps are:
- update the corresponding prolog_trigger.fcl file to include the new sequence required to run the new filter;
- in case a new directory was made:
- create a file
fcl/prolog_trigger.fclthat includes the filter default instance and also the sequence required to run it; - include in the
Trigger/fcl/templates.fclfile the newprolog_trigger.fclfile.
- create a file
It is important to note that in all the trigger sequences defined so far, we have been including two event pre-scale filter instances at the very beginning and at the very end. In this way we have an handle to eventually reduce the number of times the sequence is run and/or pre-scale on the group of "good" events selected by the filter.