Hacker News Reader

Comment by amelius | Hacker News Reader

Is there even a bound on the computational power we'd need to make an advancement here?

> Although these techniques would be able to work out the paths even after the upgrades, “the problem is, they are too slow”, says Cécile Germain, a computer scientist at the University of Paris South in Orsay. Without major investment in new detector technologies, LHC physicists estimate that the collision rates will exceed the current capabilities by at least a factor of 10.

Sounds like the LHC’s physicists have an idea.

No, but CERN Is known to be careful with their PR. Presumably, and this is just my intuition speaking, a big enough cluster of computers would solve this, but they're taking an opportunity to experiment with different techniques and methods for this experiment, and that's pretty much it.

If CERN had an unlimited budget, I suspect they'd do it however they did it before.

This is not a problem that can be solved just by throwing more compute resources at it. It's not as simple as simply having too much data to process, the real issue is that each detector has a time resolution that goes down to about a nanosecond. If you get one collision per nanosecond then it's pretty straight forward to associate every one of the (possibly) million detector hits to a single event and reconstruct it accordingly. The issues arises when you have more than one event (i.e. collision) within each nanosecond window. You end up with detector readings for each event overlapping each other without a simple way of disambiguating them. This is called "pile up".

When I last worked there in 2015 a typical pile up situation was having about 50 collisions per detector reading. It is no simple problem to simultaneously reconstruct 50 collisions from the same set of overlapping detector measurements.

Just to insert the usual analogy, if a single collision is the proverbial smashing of two clocks, and then trying to discern their makeup from the wreckage, this is akin to smashing dozens of clocks at the same time. How can you tell where one gear fragment was meant to fit when it’s such a mess?

One thing that might help is that the collision vertex is slightly different each time. If you already had all of the tracks reconstructed, you'd find that you could point them together into n different centers of mass from which they originated.

This is already what happens. The problem is that forming tracks and vertices becomes much harder as the number increases.

Vertex finding is the first step in most track reconstruction algorithms. But it's still very difficult. The number of trajectories that can be formed from discrete points blows up combinatorically. When you have hundreds of thousands of points you usually don't end up with a few easy to find vertices.

From what I've heard, the amount of pile-up ATLAS and CMS can handle is limited by the CPU time it takes to reconstruct events, which can be alleviated by throwing more resources at it, but it is much better to develop quicker reconstruction algorithms.

Towards the end of last year, they had to start levelling the instantaneous luminosity to 75% of what they could achieve,† primarily to reduce the load on the grid.

† Edit: the maximum peak luminosity is still 200% of the design value, so the performance is beyond initial expectations.

To be fair, 50 PU is above design peak luminosity, much less mean. And I'm sure I've seen plots from both ATLAS and CMS at the end of LS1 that show improvements in the processing time at 100 PU by factors of roughly 10.

Reply on news.ycombinator.com