Computers are nice, until you get to know them. Working in physics involves (as far as I can tell) spending a reasonable amount of time bathing our eyes in the cold light of a computer screen.
The days were all the data was recorded by hand, in a small logbook next to the experiment itself are long gone. Today’s huge experiments imply the generation of huge amounts of data, and an infrastructure that is able to record that information and store it for subsequent analysis. As you may have guessed, this is where computers enter the game.
Even though we have tools that make our work easier, there is no commercial package that will single-handedly crunch all the data, and spit a ready-to-be-published paper with all the results, that’s actually our job. Due to the uniqueness of the devices that we use (most detectors are “one of a kind”) it is very difficult to use software that was meant for a previous experiment to analyse our new data. That’s why, in most of the cases, physicists have to design, write, and run their own software. And that’s why we spend hours and hours in front of the screen trying to make the computer do what we want to do, as opposed to let it do what it wants to do.
How do we make a computer work for us? Easy, we use a programming language. We learn how to write plain text instructions in an specific language that would be then transformed into something that the computer can understand, and hopefully run.
An analogy to this is the HTML code in which this very page is written into. If you look through the menues of your internet browser, you’ll see an option that allows you to look at the source code of this page. This seemingly cryptic text contains information that will tell the browser how to nicely format the webpage you’re looking at. But HTML is only used to format web pages, if we want to do something with need some other language. Most of the times I use C++, which I think is the lingua franca of software development in high energy physics.
If you’re working in a big collaboration, it’s very hard for a single individual to put together a complete analysis suite for the data. The collaborations usually have a group of people (most of the times consisting of a mix of software engineers and physicists) that dedicate their time to write the software that would be used by their colleagues. So you end up having a huge software package that will do thousands of marvelous things and, with a little bit of work from your part, will allow you to extract the values that you’re looking for from the raw data.
The IceCube software bootcamp
Luckily for me, IceCube organizes every year a “software bootcamp”, where all the gadgets available in the official analysis and simulation packages are presented to the newcomers. The software development team will come to Madison and they’ll tell us how to use all the tools they have made available to the collaboration in this week-long workshop, and we’ll end up knowing not only a little bit more about programming, but also about what’s in (and what’s not in) the data.
I had been working with the IceCube software even before the bootcamp, and I had a reasonable amount of experience from my work in Auger, so the transition was relatively smooth for me. I still have a lot to learn about programming, but I consider that I have a nice amount of experience in the subject, which doesn’t mean that I enjoy doing it. Let me give you an example of why that’s the case.
When you write code, and your code is supposed to do a lot of complicated things, there’s a good chance that the first time you try to compile it, the compiler (a program that converts your plain text code to machine-readable instructions) won’t like what you wrote. Most of the times, it’s just a typo, or the syntax that you used for a function is wrong, or something like that. But even when the compiler finishes without errors, that doesn’t mean that you’re getting any closer to your results. Many times a program would just crash for a variety of reasons, and you’ll have to go through the code looking for the error in a slow and tedious process known as “debugging” the code. Sometimes, the program will run perfectly, but when you look at the results it would be total nonsense, so it’s debugging time again!
This debugging process takes a good amount of time, anything from a minute to a couple of days, and I’m going through it at the moment. So now you understand why physicists have such a problematic relationship with computers, and that is why today I hate programming, although that could change to love tomorrow if I happen to find the bug in my code… 🙂
