Babar logo
HEPIC E,S & H Databases PDG HEP preprints
Organization Detector Computing Physics Documentation
Personnel Glossary Sitemap Search Hypernews
Unwrap page!
Det. Search
Who's who?
Intern. region
Vertex Tracker
Drift chamber
Run Coordination
Contact Experts
Shift Takers Info
Operations Manual
Electronic Logbook
Ops Hypernews
Shift Signup
Check this page for HTML 4.01 Transitional compliance with the
W3C Validator
(More checks...)


There are essentially three different interfaces that provide access to trigger line information. They are implemented to cover different use cases. All of them work on the basis of trigger line names.

Note that the meaning of the trigger bits and their order is configuration-dependent. Which lines are present in the event and what the logic and cuts of the algorithms were, is determined for the configuration cycle.

One purpose of these interfaces is that they hide from the user the task of getting the right configuration (TrgConfig). The interpretation of trigger data for events that correspond to different configuration keys is done transparently.

Also, the internal representation of the bits varies among the different types of the trigger lines, e.g., words for GLT/FCT, arrays for L3/OEP. Another feature of the TrgTools is that they provide a common interface.



One of the 24 GLT lines before FCT prescaling.
(Example: D2, 2M)


One of the 24+8 FCT lines after prescaling and applying the trigger mask. Includes random triggers.
(Example: cyclic1)


One the of the L3 input lines, typically L1Open, Bunch and Cyclic -- not very useful.


The result of an individual L3 script, before combining it to output lines -- very useful.
(Example: IP1TrackScript, Bhabha2ProngVetoScript)


One of the L3 output lines before OEP prescaling, i.e., the input to OEP.
(Example: L3OutBhabha)


The L3 output lines after OEP prescaling, plus the lines generated by binned prescaling.
(Example: L3OutBhabhaFlat)

TrgLine Filters

The easiest way to retrieve an event sample that has a given set of trigger lines on (or off) is to use the Trg*Filter modules. There is a filter module for each type of trigger line, before and after prescaling, if applicable.

  • TrgGltLineFilter
  • TrgFctLineFilter
  • TrgL3InputLineFilter
  • TrgL3ScriptFlagFilter
  • TrgOepInputLineFilter
  • TrgOepOutputLineFilter

The TrgLineFilters can be set up to perform

  • A logical OR of trigger lines required to be "on".
  • A logical AND of trigger lines required to be "off".
Optionally, the OR can be turned into an AND, requiring all of the given trigger lines to be "on".

Example code

Somewhere in your AppUserBuild, add:

#include "TrgTools/TrgLineFilterSequence.hh"



Example tcl fragment

sourceFoundFile TrgTools/TrgLineFilterSequence.tcl

path append mypath TrgLineFilterSequence

module talk TrgL3ScriptFlagFilter
# verbose set true
  linesOn  set BhabhaAcceptScript
  linesOff set Bhabha1ProngVetoFilter
  linesOff set Bhabha2ProngVetoFilter
# allOn set true
Use these if you want to filter a set of events according to a given combination of trigger lines.

TrgLine Inspectors

A more direct way of accessing trigger line information is to use the Trg*Inspector objects. Again, there is an inspector for each type of trigger line.

The line inspectors can be used inside a module, for example to perform different tasks for different combinations of trigger lines, such as filling specific histograms. They provide the same functionality as the line filters and like those, they are configured using a list of line names and an optional second list of line names to veto on.

Example code

AbsParmVector<RWCString> _myLines;
AbsParmVector<RWCString> _myVetos;


TrgOepOutputLineInspector myInspector;
myInspector.use( _myLines.value(), _myVetos.value() );

if      ( myInspector.all( theEvent ) )
   ErrMsg(routine) << " all lines fired and no veto " << endmsg;
else if ( myInspector.any( theEvent ) )
   ErrMsg(routine) << " some lines fired but none of the vetos " << endmsg;
   ErrMsg(routine) << " nothing fired or there were vetos " << endmsg;
Use these if you want to test one trigger line or a combination of lines inside a module.

TrgLine State Iterators

If the state of all trigger lines of a given kind has to be checked, the TrgLineStateIterators allow to access them one-by-one.

The state iterators provide access to the state ("on" or "off") and the name of each trigger line in the current event.

Iterating over the lines to find a particular one rarely makes sense, one should use the line inspectors instead.

Example code

#include "TrgTools/TrgLineStateIterator.hh"
#include "TrgTools/TrgGltLineArray.hh"


TrgLineStateIterator<TrgGltLineArray> iter( theEvent );

for ( ; iter.notAtEnd(); )
    if ( iter.passed() )
      ErrMsg(routine) << " line passed: " << << endmsg;
Use these if you want to access the state of every configured trigger line inside a module.

Page author: Rainer Bartoldus
Last update: 21-Mar-2002 Expiry date: 01-Jan-2003