Cleaning up the code

9 March 2009

Kirill Prokofiev and Andreas Wildauer clean some software



When it comes to spring-cleaning the ATLAS software, the Inner Detector crew is really ahead of the game. So far ahead, in fact, that they’ve finished before spring has even sprung. The deadline for the software clean-up for the whole detector looms at the end of this week, but the ID software folks decided to make the most of the lull before Christmas to get ahead with their chores.

“We also knew that there would be no beam in the spring, so we had some time to do this,” says interim ID Release Co-ordinator Kirill Prokofiev. “Because this really takes time,” he adds, “… several months.”

So how exactly do you go about ‘cleaning’ software, you might ask? For a start, you avoid adding any new functionality, and then you try and streamline, tidy up, and generally improve the efficiency of the code, according to Andreas Wildauer, who works closely with Kirill, and indeed performed the role of ID Release Co-ordinator before handing over to Kirill at Christmas.

“The ATLAS software framework [sets out] fairly clear rules about how things should be done,” he explains, “but since most of the developers in ATLAS are like us – physicists, not software engineers – the good coding stuff tends to divert a bit.”

New ATLAS developers usually start with an example package and use it as a guide for their own work. But if their example package was, unbeknownst to them, a poor one, then ‘bad code’ can easily spread through the whole repository.

‘Bad code’ is the insult thrown at script which – although it does the job that it was intended to do – takes too long to run or compile, takes up too much memory, or relies too heavily on dependencies between software packages.

“We have organised everything in packages – this one finds a track, another one finds a particular particle,” explains Andreas. But too many dependent links between packages could cause a domino effect if one of the base packages, upon which all the rest rely, is altered in a way that no longer fits for the dependent packages. Think of it like pulling out some bricks from the bottom of a stack. If the stack doesn’t collapse straight away, then it almost certainly will when you try to force some different shaped bricks back into the holes.

In the case of the ATLAS software, this principle also applies sideways as well as top-to-bottom. “If there are too many dependencies, it introduces massive problems when changing things,” warns Kirill. “The corrections were required not only because people used bad examples,” he qualifies, “but also because we improved the general structure – made it more robust and flexible.” This caused some packages that were previously sound became outdated as others around them were altered.

Given all this, it may come as some surprise to learn that the ID team began the ID software clean-up campaign in seemingly the worst place possible: at the bottom. “We did that to get an idea of how bad all the packages on top are,” explains Andreas. “Because if they are written in a bad way concerning their dependencies, they will fail if the base package is now clean.”

“In the beginning it looked pretty scary,” recalls Kirill of the scene that awaited them on the morning after the first night’s recompile. Thankfully, their tinkering was all done in a parallel ‘playground’ – a direct copy of the whole system – so that collaborators’ routine physics analysis work, which was ongoing in the meanwhile, was not disturbed. “Otherwise, our changes would have killed the whole software for weeks,” says Kirill. Only when they had a fully functioning new ‘software tree’ did they merge it back into the main one.

Between them, Andreas and Kirill identified all the packages in the ID and tracking domain, and made a list of which people were responsible for them. Then they drew up a set of rules about how to clean up the packages, and set about contacting the relevant developers amongst the 150 actively working on ATLAS ID software all over the world.

“It was taken very positively by the community,” says Kirill with an edge of relief in his voice. “Our developers really deserve to be recognised for this.”

Almost all the packages within the ID and Tracking remit – a total of 300 packages, comprising around 2000 files and goodness knows how many individual lines of code – were cleaned. “The tedious thing for us was the quality control,” remembers Andreas, who, as gatekeeper along with Kirill, had to read through each re-submitted file manually to check that they had been fixed correctly.

The work began in earnest in November, hit its peak in early January, and was wrapped up just a week or two ago. “It’s not like we were bored and wondering what to do for Christmas,” laughs Andreas, as he explains why the software clean-up was so crucial. “ATLAS has very strict limits on how much memory a reconstruction job is allowed to take. At the moment if you run the full reconstruction [for the full detector], we are completely at this limit.”

Cleaning up the code is an effective way to bring the memory usage down. Further improvements are expected when the other two main software areas – the calorimeter and muon groups, and the Combined Performance group – complete their own clean-up exercises.

 

 

 

Ceri Perkins

ATLAS e-News