TrgTools
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.
TrgLines
GltLine - One of the 24 GLT lines before FCT prescaling.
(Example: D2, 2M)
FctLine - One of the 24+8 FCT lines after prescaling
and applying the trigger mask. Includes random triggers.
(Example: cyclic1)
L3InputLine - One the of the L3 input lines, typically
L1Open, Bunch and Cyclic -- not very useful.
L3ScriptFlag - The result of an individual L3 script, before
combining it to output lines -- very useful.
(Example: IP1TrackScript, Bhabha2ProngVetoScript)
OepInputLine - One of the L3 output lines before OEP
prescaling, i.e., the input to OEP.
(Example: L3OutBhabha)
OepOutputLine - The L3 output lines after OEP prescaling, plus
the lines generated by binned prescaling.
(Example: L3OutBhabhaFlat)
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"
[...]
TrgLineFilterSequence(this)
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
exit
 Use these if you want to filter a set of events according to a
given combination of trigger lines.
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;
else
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.
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(); iter.next() )
{
if ( iter.passed() )
ErrMsg(routine) << " line passed: " << iter.name() << endmsg;
}
Use these if you want to access the state
of every configured trigger line inside a module.
|
