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.
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:
- 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
-
Calorimeter: measures the energy of particles by their absorption
(and subsequent heat generation)
- 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 !)
- 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:
- 40Mhz reduced to
100KHz via custom electronics
- 100KHz reduced
to 1KHz initial processing
- 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" />


