Content-type: text/html Manpage of TRGCONFIG
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...)


Section: BaBar Trigger Documentation (5)
Updated: December 2001
Index Return to Main Contents



TrgConfig - Trigger configuration file



A TrgConfig file is an ASCII representation of a BaBar Trigger configuration. It is stored in the configuration database and can be accessed either through the TrgConfig API or via certain standalone applications. TrgConfig files have the extension .tcf. See getTrgConfig(1) for a tool to retrieve and display the Trigger configuration.

TrgConfig is the single authoritative source of configuration data for all components of the Trigger system. It is used to configure the trigger lines of the Global Trigger (GLT) and the Fast Control and Timing System (FCT), which form the Level 1 Accept decision, as well as the input and output lines, and the so-called execution web of the Level 3 Trigger. (See below.)
  A TrgConfig file is organized in eight sections, which are preceeded by the following keywords: L1Lines, L3InputLines, L3Sequences, L3Modules, L3Scripts, OepLines, L3OutputLines, OepPrescales.

The sections must appear in the above order as their definitions build on one another. Some of the sections may be empty in certain configurations, although for normal data taking, usually all sections are filled. The following are the exceptions. It is possible to have only an L1Lines section and nothing related to Level 3. For backward compatibility with older configurations, the OepPrescales section may be omitted. The FctTimePoint section was introduced for Trickle Injection running and is also optional.

Each section consists of a number of definitions. All definitions have the general format:

<identifier>: [<arguments ...>]

The identifier defines either a trigger line name, or a module, sequence or script name in the context of the Level 3 sections.

This section defines the up to 32 lines of the L1 Trigger. Lines 1-24 define the trigger logic that is applied by the GLT. The next four lines (25-28) correspond to external signals on the Fast Control Gate Module (FCGM). The last four lines (29-32) configure software triggers that are generated for the Fast Control Partition Master (FCPM).

A GLT line is defined by a logical expression formed in terms of one or more of 17 GLT object count cuts.

The GLT object counts are:

nB,nA,nA' (short, long, high-pt track from the DCT)


(MIP, intermediate, high-Energy cluster, high-E cluster in the backward barrel, MIP in the forward endcap from the EMT)

nU (3-bit pattern decoding hit topologies in the IFR)

nB*,nA*,nM*,nG*,nE*,nEM (back-to-back combinations of tracks and clusters)

nBM,nBMX (track-cluster matches)

A GLT line definition contains an expression with one or more cuts. By convention, the L1 line names directly reflect or abbreviate this cut expression. For example, "2B&1A" stands for (nB>=2 and nA>=1).

Each definition contains an explicit line number, which defines the priority of that line.

A GLT line definition has the format:

<L1 line>: "(" <object count cuts> ")" number=<1-24>


This (optional) section defines L1FctTimePoint objects, which hold information about a special type of event that happened earlier in the data stream (such as a Trickle Injection pulse), and which are generated by Dataflow markers.

FctTimePoint names are associated with the logical "OR" of one of more FCT (non-GLT) lines from the L1Lines section. The FCT time point definitions have the format:

<FCT time point>: <FCT line> [ or <FCT line> ... ]


This section defines the Level 3 input lines, which represent the logical "OR" of one of more L1 lines from the L1Lines section. Generally, every L1 line will be attached to at least one L3 input line. The L3 input line definitions have the format:

<L3 input line>: <L1 line> [ or <L1 line> ... ]


This section defines the Level 3 sequences (or tools) that are run on the L3 scripts. The current sequences are "L3DSequence" (from L3Dch) and "L3ESequence" (from L3Emc). At present, sequence definitions are empty, i.e., they have the trivial format:

<L3 sequence>:


This section defines the Level 3 modules, which are usually filters, that are run on the L3 scripts. An L3 module definition has the format:

<L3 module>: <L3 module prototype> "{" [ <tcl parameter> = <value> ... ] "}"

where the <tcl parameter> must be declared for the module prototype and the <value> can be an integer or a real number.


This section defines the central part of the Level 3 algorithms, the Level 3 scripts. An L3 script definition has the format:

<L3 script>: <L3 input line> "{" [ <L3 sequence> ... ] [ <L3 module> ... ] "}"

where all of <L3 input line>, <L3 sequence>, and <L3 module> must be defined in the previous three sections.


This section defines the lines that are passed on to OEP for logging. The Level 3 logging decision is a logical "OR" of all OEP lines. OEP lines can be assigned a prescale factor, which is 1 by default, and an enable flag that, if set to disable, excludes that line from the logging decision.

An OEP line definition has the format:

<OEP line>: prescale=<factor> <enable flag>

with <enable flag> being either "enable" or "disable".


This section defines the Level 3 output lines, which are a subset of the OEP lines. L3 output lines are given as a logical "OR" of the result of L3 scripts (script flags) with possible vetos on other L3 scripts.

The format is:

<L3 output line>: "(" <L3 script> [ or <L3 script> ... ] ")" [ and not <L3 script> ... ]

If no veto is specified the parentheses around the scripts to "or" can be omitted. The C++ operator symbols "||", "&&" and "!" can be used instead of "or", "and" and "not", respectively.


This section defines OEP lines that are subject to more sophisticated methods of prescaling. There are currently two different kinds of prescalers.

The first type is a binned prescaler, which applies different prescale factors depending on the value of an observable in the event. [This is primarily used to flatten the selected distribution of Bhabha events in polar angle.] Note that in this format the square brackets are part of the syntax. It is:

<OEP line>: <L3 output line> <L3 module> "{" <prescale factor> "[" <bin boundary> "]" ... <prescale factor> "}"

The other method is that of a weighted prescaler. This controls the output of one trigger line by making it pass events at the rate of another line. [This is in primarily used to select background trigger events weighted by luminosity.] The syntax for this type is:

<OEP line>: <L3 output line> <L3 weight line> prescale=<factor>



At the time of this latest updated to the man page, "Physics-75.tcf" is the configuration file for normal data taking, which can be retrieved under the alias "PHYSICS" alias (or key 2512). Other files in use were "Cosmics-22.tcf" and "Background-75.tcf" with corresponding run-type aliases. The getTrgConfig(1) command can be used to fetch and display these configurations.



Rainer Bartoldus <>.



Report bugs to



Software developed for the BaBar Detector at the SLAC B-Factory.
Copyright © 2001 BaBar Collaboration




More documentation on TrgConfig and the BaBar Trigger can be found on the BaBar web site /BFROOT.




This document was created by man2html, using the manual pages.
Time: 00:21:45 GMT, February 20, 2005