Why ATLASWatchMan: A Little Story From Everyday Life...

A little story from everyday life...

Analyzing experimental data.

This is the goal for all of us.

We all want to easily access the data, easily read them, easily implement the idea of analysis that we had going by car to the office, in the morning...

We would like to easily test if our idea is good or not, and if with our strategy we can explore that feature of data or not.

So we go to our office, ready to start coding in order to implement our own idea!! But when we then start, we realize that we have to face plenty of other stuff, before actually writing our own custom code for our analysis.

We have to learn the Atlas framework Athena and how plug in our software into it; we have to learn the Atlas data format and how to access data and the objects inside; we have to learn how to filter those objects, using the tools provided by the Atlas framework.

Thus, before actually writing the code to implement our anlaysis...we have to learn a lot of things and then implement and test and debug a lot of code related only to the Atlas framework itself.

Then, after having set up the code " au contour ", finally, we can start to write the code to implement our own analysis....and we run on data!!

And we happily analyze data!!

[ ... a week after ... ]

A week after, we want to start another analysis, to implement a new strategy which came to our mind at the coffee table, in the afternoon...

So we copy-and -paste part of our code from the week before into another file, and we start coding the new analysis. And we run on data. Nice!

[ ... after some more days ... ]

After some days, we see that we could modify our analysis so in order to build a new version to compare to the old one, we copy-and-paste our first class into another file and we modify it.

But in the meantime a container inside the data format changed the name, or the conveners of our working group decided to change an object selection cut. So after having copied and modified the class for our new analysis, we also have to open the two files, plus the other one we created the week before, in order to change the container name and the value of the cut.

The copy-and-paste approach.

This approach works, of course. But in this example we have only 3 files to be managed.

Let's imagine what happens when we start to have many versions of our analysis, or many different analyses....and we end up with tens of files containing code!

We will have tens of code files to be maintained, debugged and validated!!!

and those files actually have most of the code in common!!!!

Very often two class containing analysis code, only differ by some small algorithm, formula or value. All the other code is in common: setting the environment, accessing and reading data, book the ROOT objects, filling the ROOT TTress, and so on...

And even the most common formulas for physics analysis are in common: let's think about the cut on lepton pt's, or on number of jets, and so on... Easy formulas, of course; but repeated tens and tens of times inside all our analysis code!!! Tens of lines to be maintained, spread among many files....

For example, if we want to change the order of our event selection cuts inside our analyses, we have to open them and change the code, one by one; with the risk to involuntary add typo or bugs inside the code. And this just to change the order of our cuts!!

Analyzing Atlas data should not be cumbersome for physicists. They should only say "I want to select events with those two cuts, and I want to use those particles, selected with those other cuts, and I want to plots this quantity, and then combine it with that other one, and then store everything in another branch...." and so on.

But

No need to know how to write code

...You only have to think about your analysis strategy!!

-- RiccardoMariaBianchi - 27 Jul 2009