Tag: CERN

Back from CERN

Posted on1 Comment

Bad blogger me, late as usual.
On Thursday I got back from a longer trip to CERN, Geneva. The purpose of the trip was to sit shift for the HLT subsystem in ALICE, on behalf of the University of Bergen. While not a prerequisite for completion, its was part of my senior project.

Due to the whole volcano ash thing, we had to take the train from Tønsberg, Norway to Geneva, Switzerland(!!). Actually we didn’t have to, but we wanted to go, and after 4 days of “ash clouds, maybe there will be a flight, maybe there wont” we decided to just get there on our own.
The trip turned out a bit less smooth because the ordinary night trains from Copenhagen to Basel were full, so we had to wait 8 hours in Copenhagen and switch between several small regional trains in Denmark in the middle of the night. But hey, we got to see Copenhagen also 😉

The mainline news coverage of the volcano ash business has been all but sickening, but the following little comic made me laugh hard. Especially because of the supposed-to-look-icelandish language used:

'Put 30 billion euro in the garbage can infront of the icelandish embassy tonight, and we will turn off the vulcano! Don't call the police!'

‘Put 30 billion euro in the garbage can in front of the Icelandic embassy tonight, and we will turn off the volcano! Don’t call the police!’

Down at CERN, most of the shifts were pretty uneventful as there was seldom “stable beams”. The beam refers to the particles being accelerated (in the LHC in ALICEs case), and stable means that collisions are happening in a controlled manner so that you can actually start data-taking.
So, when you’re not taking data, sitting shifts mostly means noting down problems that occur with your subsystem, and possibly notifying the on-call expect if deemed serious enough. Actually, being a shifter on HLT should be like that all the time, as it is supposed to be a completely autonomous system in this aspect.
I got to work a bit on my senior project, a bit on MyPaint, a bit on other things, but didn’t really get to be as productive as I would have liked. Especially on the night-shift, I found it hard to do any serious work. Strange, as I often have my most productive times after midnight when at home.

One thing I regret the most is packing too much clothes, and not bringing a camera. Even if we didn’t really do a lot of very exciting stuff, it still would have been nice to have pictures; Capturing the moment, binding the state of mind at that instant to something physical, for easier retrieval at a later time.

GPGPU in ALICE workshop

Posted on1 Comment

I’ve attended a small workshop/seminar in Bergen (at IFT) about nVidia CUDA and its use in the ALICE project at CERN. The goal for me and the other students from Vestfold University College was to get a concrete task for our senior project and to get up to speed on some of the things we need to get started.

The three days were heavily packed with information, so this will just be a tiny tiny summary. I will probably write up some posts explaining some parts in more detail later. If I can get a hold of the presentations given I will link them here.

Talks/topics

Day 1:

Why parallelize and why GPGPU?

Computing units does not scale simply by frequency anymore so we need to parallelize to increase performance. GPUs are commodity hardware designed for massive parallelism driven forward by  a huge consumer market in 3D graphics => provides high performance, low cost, is flexible and easy to use compared to DSP, FPGA, custom vector CPUs etc.

The Nvidia CUDA platform

Describes the underlying hardware platform and a concept for accessing this from a high level language (C with some C++ and custom extensions). Current generation has approx 200 stream processors and is designed to have several thousand threads running at the same time. There are cards especially for GP-computing (Tesla-series), but for a lot of computations the high end GeForce cards are good enough. Practically all newer GPUs from nVidia is CUDA capable, all the way from the Ion found in netbooks/net-tops.

CUDA programming model

Functions called kernels are executed on the device. All threads will run this same code, differentiation on which threads do what is done by using their IDs in statements. Threads are grouped into blocks, blocks are grouped into grids.  The number of threads/blocks is specified on kernel invocation and used for scaling to different devices. Memory is divided into several parts, each of which needs be handled manually. Device <=> host transfers is also done manually.

Day 2:

The TPC and HLT in ALICE.

Incredibly high data rates, not feasible or wanted to store all raw data  => some processing/analysis needs to be done in real-time (“online”). This can be done now using a large cluster of machines (the HLT). Using GPUs will allow this cluster to consist of a smaller number of nodes => cheaper and will free resources for other things like offline analysis.

Optimizing CUDA code.

Calculations are fast, (global) memory is slow => Focus on reducing and optimizing memory access. Designed for massive parallelism => make sure your problem sizes are big enough and that you’re split the problem in a good way.

Day 3:

OpenCL

Basically the CUDA model + vendor/platform independence – C++ features, otherwise only minor differences => Should be easy to port to and understand when you know CUDA. Implementations on the way, also for CPUs (x86 with SSE and Cell) and DSPs (Texas Instruments). Likely to be a good candidate for scientific computing in the future.

CUDA-ified tracking code

We had a look at how CUDA has been implemented to do a task within the AliRoot framework used in the HLT allready. Some concept mismatches leads to having to wrap code in somewhat ugly ways.  Further uglified/complicated by the fact that the same code should be able to run on either the CPU or GPU.

Our task: Vertex finding

More about this in a later post!

Other

I brought a camera along, but as I’m not used to having one with me I completely forgot to take pictures. We did get to see Bergen a little bit, tho we spent most of our time on the CUDA/CERN stuff.
And there was rain. Every day, all day pretty much. Not sure how I’d cope with that if I lived there.

Senior project confirmed

Posted onLeave a comment

I will be implementing algorithms on nVidia graphic cards using CUDA for use at CERN. Its a collaboration project between my school, the university of Bergen and a university in Germany (presumably Heidelberg). While a lot of the specifics are still up in the air, it will most likely be for the High Level Trigger system for the ALICE sensor.

ALICE is the sensor system which will be used for studying the biggest particle collisions at CERN when their new particle accelerator gets up and running again this fall and throughout next year. They will be colliding lead nucleus in order to recreate the conditions that existed under 1 billionth of a second after the Big Bang.  In these experiments one hopes to find out more about quark-gluon plasma.

Needless to say this is a really exiting project for me. Not a lot of people are so lucky and get to work on such a grand thing for their senior project.  I expect plenty of good technical challenges. And who knows, maybe there is even an opportunity for more than a senior project here?

First up is an introductory course in Bergen on the 5th-7th of October to get up to speed and a concrete assignment. I also hope to get some exploratory coding with CUDA before that time.