the trigger and event selection

Suppose a firehose of photographs blasted past you at a rate you could never hope to store — millions of pictures per second — and you were allowed to keep only a few hundred of them. You would need a snap-judgement rule for deciding, in a flash, 'keep this one, throw that one away.' The trigger is exactly that rule for a particle detector. Collisions happen far too fast and far too often to record them all, so the trigger is an automatic system that decides, in real time, which rare collisions are worth saving and lets the overwhelming majority go forever.

At the LHC, bunches cross about forty million times a second, and most crossings produce only humdrum, well-understood physics. Recording everything is impossible — there is not enough storage or bandwidth on Earth. So the trigger works in stages. A fast, hardware-based first level (the Level-1 trigger) makes a crude decision within microseconds, using simple signs of something interesting — say, a high-energy electron or a large amount of missing energy — to cut the rate from forty million down to a hundred thousand per second. A slower, software-based high-level trigger then runs a fuller reconstruction and trims that down to a few hundred or thousand events per second, which get written to disk.

The trigger is one of the most consequential and least-celebrated parts of any experiment, because a collision the trigger throws away is gone for good — no later analysis can ever recover it. This makes trigger design a high-stakes act of foresight: you must decide in advance which signatures to keep, which means you can only easily discover things you thought to look for. A subtle danger is trigger bias: the very act of selecting events distorts your sample, so any measurement must carefully account for, or correct out, exactly what the trigger let through and what it suppressed.