Trigger

A trigger, in the context of particle detectors, is a collection of devices, usually a combination of electronics and informatics components, providing a fast signal whenever some interesting event has happened. Typically, a trigger is associated with some particle detector(s), and the trigger signal causes the information pertaining to these and other detector(s), or parts thereof, to be recorded or processed. The event as seen by the trigger must allow one to evaluate conditions that are predicted to be characteristic for interesting events; these conditions are often called the event signature. Conditions may be as simple as identifying a charged track passing through a few scintillation counters within a time gate (typical trigger in a test beam), or as complicated as effective mass criteria between identified leptons that have to be satisfied in high-energy collisions (e.g. the intended triggers at the 40 MHz Large Hadron Collider at CERN).

In many experiments, data taking, through the dead time it causes, is a critical factor limiting statistics and hence physics potential; an efficient trigger system is then the critical cornerstone for transmitting data that have a high probability of containing good physics, and rejecting, with respect to the possibilities of the detector, all or most of the background, viz. trivial physics or non-physics events. Clearly, not only the data elements, i.e. transmission, electronics and computing, are needed for the trigger, but equally important are detector and readout parts that provide the data to be checked in a trigger system.

Depending on the accelerator used, triggers may be gated (e.g. by bunch crossings at a collider), or permanently active (like for cosmic rays or during the flat top of a fixed-target experiment). Implementations may be synchronous and time-critical, or made from various asynchronous local subsystems operating independently in parallel, and reporting to a control unit (which also has the task of resynchronizing). The implementations of trigger conditions range from simple AND/OR gates through field-programmable gate arrays to algorithms written in general-purpose processors. Transmission delays depend on data volumes (and often on local resource occupation), and algorithms may have a data-dependent execution time; to avoid dead times at too many levels, multiple (FIFO-type) buffers smooth the fluctuations.

In large experiments, triggers are implemented in multiple levels; typically, a fast and synchronous trigger (``level 1) identifies candidate events from a subset of events, reducing the rate by some factor. Subsequently, data are digitized, transmitted to more permanent buffers and to the next (asynchronous) trigger, and more complex algorithms based on more complete data reduce the rate again (``level 2). Eventually, after perhaps a third and fourth iteration, the entire event is transmitted to permanent storage.

Implementations of triggers not only depend on the detector design and the readout, but also on the rapidly evolving technology of data transmission and processing. The comparatively complex data flow situations can most often be understood only using Monte Carlo data and modelling programs. Queuing theory allows one to predict behaviour at the (simpler) local level. For introductory reading, see Bock90. Examples for trigger implementations at LEP are Bocci95 and Arignon93.

0.00 (0 votes)