Event Processing at the Large Hadron Collider

First Published Monday, 21st November 2011 02:26 pm from TIBCO Software : Paul Vincent

The opinions expressed by this blogger and those providing comments are theirs alone, this does not reflect the opinion of Automated Trader or any employee thereof. Automated Trader is not responsible for the accuracy of any of the information supplied by this article.


class="alignright"

src="http://upload.wikimedia.org/wikipedia/commons/thumb/1/1c/CMS_Higgs-event.jpg/220px-CMS_Higgs-event.jpg"

alt="" width="220" height="203" />Earlier this month

Dr Neil Geddes gave a fascinating presentation at the title="BCS Oxford meeting on DP at LHC, Nov11"

href="http://www.oxon.bcs.org/2011/09/12/smashing-it-data-processing-at-large-hadron-collider/"

target="_blank">BCS on "Data Processing at the Large

Hadron Collider", describing how title="Wikipedia reference"

href="http://en.wikipedia.org/wiki/LHC" target="_blank">LHC

experiments create 1 Billion events per sec of which

they can record in detail 100 events per sec. Neil's

backgrounder on particle physics was certainly worthy of a an

award for the best Dummys Guide, covering everything from

molecules and atoms to leptons, mesons, baryons etc. The role of

the LHC is to help discover new particles like the title="Wikipedia reference"

href="http://en.wikipedia.org/wiki/Higgs_boson"

target="_blank">Higgs boson, as current astronomical

observations don't fit current physics theory (such as

the rotational speeds of stars indicating some unknown

gravitational force on galaxies).

The LHC uses

a proton collider to create new particles: the rates of the

experiment are approximately:

  • 40MHz of "proton bunch"

    collisions

  • which give 10E9 Hz proton

    collisions

  • which give 10E-5 Hz particle

    production

So one part of LHC

experiments are to do with creating these particles, and the

other part is "Complex Event Detection" -

detecting and tracking the particles that fly out due to the

proton collisions - and then doing data processing to try and

reconstruct the "collision event" as it

happened…

From an event detection

perspective, as one would expect, the detector hardware is

complex and layered to detect different types of

particles:

  1. Silicon CCD strips

    (similar conceptually to a digital camera sensor) providing 66M

    channels (c.f. camera pixels) detecting at 45MHz; these measure

    the curvature of particle tracks in a magnetic field, from which

    particle momentum can be calculated

  2. Calorimeter: measures the energy of particles by their absorption

    (and subsequent heat generation)

  3. Lead

    Tungsten crystals which create measurable light when heavier

    particles are absorbed, using layers of brass and crystals (with

    the brass apparently sourced from redundent Soviet artillery

    shells !)

  4. Drift chambers that provide the

    same function as the layer-1 silicon strips but are much larger

    and hence with fewer readout channels

The instrumentation of these sensors also has to deal

with the issue of detector latency, where for example a single

calorimeter reading could include the impacts of many events. The

design of the sensors tries to mitigate this as much as possible

- for example the average occupancy of the silicon detectors is

designed to be 2%.

In terms of event rates,

the numbers are staggering: 1 Bn proton-proton interactions per

sec means 1000 particle tracks created every 25 ns which leads to

100Pb event data per sec which needs to be mapped to 100Mb per

sec. So the approach in event processing is to make successively

more complex decisions on successively lower data rates. These

conversions are:

  1. 40Mhz reduced to

    100KHz via custom electronics

  2. 100KHz reduced

    to 1KHz initial processing

  3. 1KHz reduced to

    O(100Hz) or 3-10ms per event.

For

one of the LHC particle colliders (CMS: the others are known as

Atlas, Alice, and LHCb) the event processing is done via a PC

grid (up to 150K CPUs) using the approach of (a) identify high

energy particles and (b) network routes each event data to a

specific process. They use a huge disk buffer at the expirement

source in case of network failure, but otherwise distribute

processing in a cross-Europe WAN (such as the CERN-UK connection

handling 10Gb per sec).

Interestingly they

have found that:

  • the network has

    proved much better than expected so the nodes are increasingly

    being used for data caches

  • CPU use has more

    than doubled in the last ~18months

Also interesting is how much more hype there is for

"big data" (MapReduce, Hadoop, et al) versus

developments in "extreme event processing"

like that done at LHC.

Note: the

presenter used the term "data processing"

whereas I deliberately used the term "event

processing". Actually both are involved: event

detection and initial processing, then distribution / storage and

~batch-type data processing.

href="http://www.addtoany.com/share_save?&linkurl=http%3A%2F%2Ftibcoblogs.com%2Fcep%2F2011%2F11%2F20%2Fevent-processing-at-the-large-hadron-collider%2F&linkname=Event%20Processing%20at%20the%20Large%20Hadron%20Collider"> src="http://tibcoblogs.com/cep/wp-content/plugins/add-to-any/share_save_120_16.png"

width="120" height="16" alt="Share/Save/Bookmark" />

No related posts.

src="http://feeds.feedburner.com/~r/ComplexEventProcessing/~4/ZZq_78AJ_oo"

height="1" width="1" />

  • Copyright © Automated Trader Ltd 2013 - The Gateway to Algorithmic and Automated Trading

click here to return to the top of the page