LCIO 2.0 improves simulation coordination

Over the years, the linear collider input/output event data model has facilitated data sharing between the world’s linear collider detector groups

| 8 December 2011

The data model that transformed the linear collider detector community from a computational Tower of Babel into a group that inputs with one voice has gotten an update.

ILC software developers released LCIO 2.0 this autumn. The new version of LCIO, a particle event data model, includes features that help scientists cope with the increasingly sophisticated data being fed into particle event simulations.

“We considerably improved the data model – in particular for the description of charged particle tracks – and put in little things from users’ requests or features we thought would improve physicists’ lives,” said DESY’s Frank Gaede, one of the main developers of LCIO and coordinator of ILCSoft, one of two software packages for which LCIO is the core.

Once upon a time, ILC physicists’ lives were direly in need of improvement when it came to sharing simulation data with other regions. As an ostensibly international project, ILC detector groups’ simulation efforts were decidedly not global: three different regions used three different computing formats to describe a simulated particle event.

Illustration of the way LCIO works with multiple software formats. Image: DESY

To produce simulations, scientists first generate a particle event – say, a collision between a positron and electron with 250 gigaelectronvolts of energy – using a standard format. But in subsequent steps, they typically use their own programs to run the event through different scenarios. From those scenarios’ outcomes, they again use their own codes to reconstruct and analyse the collision picture.

In itself, it’s not startling that different detector groups accomplish their tasks using different software formats. Each of the four detectors at the Large Hadron Collider in Switzerland, for example, uses its own in-house definition for event elements such as cluster, hit, particle and track. As large, effectively competing experiments with thousands of scientists working on them, there’s little incentive to develop a common description of a particle event for all four.

“It makes sense,” said SLAC’s Norman Graf, who leads the American Linear Collider Physics and Detector Simulations Working Group. “Each wants to hold its reconstruction close to its chest so it can beat the other guy.”

The linear collider detector community, on the other hand, is smaller and global. It makes sense for them to agree on a computational definition of a particle event.

“We’re a very open collaborative, cooperative environment in the linear collider, so when someone writes an algorithm, they share it with the world community and we run it,” Graf said.

But in the beginning, the multiplicity of software formats used by detector groups hamstrung exchange between them. Asian and European groups were using C++ software and some legacy Fortran. US groups were using a mix of Java and C++ to write their code.

“Physicists are real keen on standards,” Graf said. “Unfortunately, the mantra is, Standards are good, so let’s have lots of them.”

It’s a plight that all ILC researchers contend with – striving for harmony in a setting where the internationality of the work brings with it unavoidable differences. Scientists who work on accelerator physics for the ILC deal with regional differences in machinery by instituting plug-compatibility for machine components. Though a machine part made in Asia may not be identical to its European analogue, if both fulfil the same function and can be easily joined to the rest of the machine through plug-compatible couplers, the machine can run with that kind of variety.

Folks working on detectors decided they needed to be plug-compatible in their own way.

In 2003 Graf and Tony Johnson from SLAC and Ties Behnke and Gaede from DESY got together at SLAC to begin the development of a common data model that would replace the many different formats then on the market.

The result of the four scientists’ effort was LCIO – linear collider input/output. It established precise computational definitions for particle events that could be read out by any program. Soon it was adopted by most groups involved in the ILC around the world. The event element ‘track’, for example, would be defined in the same way for everyone, and subtle definitional variations would no longer be a complicating factor for event readouts.

A t {ol}t{/ol} event simulated and reconstructed using ILCSoft, one of two software programs with LCIO at its core. Image: DESY

“You save people in various groups from always having to understand what the other group’s data format is, translate it into the right code, and translate it into their own data format,” Gaede said.

Now, thanks to LCIO, a group in Hamburg, Germany can read a file written with Java in Palo Alto, US into their C++ Marlin application.

LCIO isn’t only for those who work in pure simulations. Scientists who work on test beams also use LCIO to store real particle events from brick-and-mortar prototype detectors.

Nor is its use limited to the ILC. The CLIC detector groups use LCIO, and there is talk of adopting it for another lepton collider, the proposed muon collider.

Earlier this year developers worked to extend LCIO to LCIO 2.0 to accommodate the evermore-detailed particle flow algorithms scientists are developing for event reconstructions. They also incorporated a feature called direct access. This saves users the trouble of having to wade through an entire file to find a particular event. With direct access, a user can easily locate a specific indexed event for study.

The scientists that started the LCIO effort were doggedly determined to persuade the world’s linear collider detector researchers to converge on a single data model for global use, and, said Gaede, scientists are now glad they did.

“Most people would agree that this was worth it – it’s made everyone’s lives easier.”

Recent Comments

Comments are closed.