Many scientists have probably been here: you work with a software and figure out later that its output is incompatible with other analysis parts. More than never-racking, incompatibility between (often) used software and libraries is highly inefficient, requires high maintenance, and wastes resources. Furthermore, much basic code needs to be developed to investigate new detector concepts for new colliders. However, often similar solutions have already been developed for another experiment. How great would it be to reuse solutions and save time?! A turnkey software stack called Key4hep is key.
“The main motivation for Key4hep was to create a turnkey software stack with interoperable components and examples that allows you to very quickly get started with implementing your ideas for a new detector technology, rather than reinventing the wheel. This way, the scientists can focus on the new physics and R&D challenges rather than on software technicalities,” DESY software expert and Key4hep co-convenor Frank Gaede explains.
This “turnkey software stack” – a collection of independent components that work together to support the execution of an application – seeks to have all the libraries needed for HEP experiments, including the generation, simulation, reconstruction, and analysis of collider events under one umbrella, converting a set of separate packages into a turnkey system. The project aims to define a common software framework for all future collider projects such as CEPC, CLIC, FCC, ILC, and the Muon Collider.
The ILC community has for the last twenty years developed common generic software tools in the iLCSoft framework. These tools were jointly developed, maintained and used by ILD, CLICdp and SiD for many linear collider studies in the past. With new the new circular machines now proposed as alternatives for a Higgs factory, it has become time to enlarge the activity of developing common tools and actively contribute to the wider Key4hep project. “We will bring many of the tools and experience from iLCsoft to Key4hep and at the same time use this opportunity to modernise our software stack for the next decades of Future Collider studies,” says Gaede.
The idea emerged as consensus among different communities in the “Future Collider Software Workshop,” which took place in Bologna in 2019 and was organised by F. Bedeschi (INFN Pisa), M. Caccia (INFN and Univ. Insubria) and P. Giacomelli (INFN Bologna)—and is also an important project for the future in the CERN Strategic R&D Programme on Technologies for Future Experiments. The main goal of Key4hep is to re-use established solutions, integrate and further develop packages to create a whole data processing framework that can be user-friendly, low-maintenance, and long-lasting. It contains around 300 packages, where 60 are experiment-specific, 50 are HEP-specific, and 200 are general-purpose.
To build a consistent stack of software, it is necessary to carefully choose the standards to be adopted to build its foundation. The components should speak the same language, the ‘Event Data Model.’ The new EDM4hep is one of the Key4hep ingredients, and it was inspired by the LCIO and FCC-edm event data models, which have been successfully used in the past years. Another key ingredient is the data processing framework, which consists of the skeleton of the software infrastructure. Here, the choice was the software architecture GAUDI, developed initially by LHCb and now used by ATLAS and FCC. For the geometry information or detector description, the choice was DD4hep, which is already largely used by the community. The scientific package manager Spack allows for an efficient and consistent link between the packages. This foundation in a shared software environment will also make writing specialised components easier.
Finally, Key4hep aims at not only librarians and developers but also users, including examples for simulations and reconstruction for detectors, making the days of battling with numerous incompatible software programs a thing of the past.
Further reading:
https://link.springer.com/content/pdf/10.1140/epjp/s13360-021-02213-1.pdf
Recent Comments