The evolution of the CMS@Home project

¹ INFN, Sezione di Padova,Padova, Italy
² CERN, Geneva, Switzerland
³ Brunel University of London, UK
⁴ University of California, San Diego, La Jolla, CA, USA
⁵ University of Notre Dame, South Bend, IN, USA
⁶ INFN, Sezione di Perugia, Perugia, Italy
⁷ DESY, Hamburg, Germany

^* Corresponding author: federica.fanzago@pd.infn.it

Published online: 7 October 2025

Abstract

Over time, the idea of exploiting voluntary computing resources as additional capacity for experiments at the LHC has given rise to individual initiatives such as the CMS@Home project. With a starting point of R&D prototypes and projects such as “jobs in the Vacuum” and SETI@Home, the experiments have tried integrating these resources into their data production frameworks transparently to the computing infrastructure. Many of these efforts were subsequently rolled into the umbrella LHC@Home project.The use of virtual machines instantiated on volunteer resources, with images created and managed by the experiment according to its needs, provided the opportunity to implement this integration, and virtualization enabled CMS code from a Linux environment to also run on Windows and Macintosh systems, realizing a distributed and heterogeneous computing environment.A prototype of CMS@Home integrated with the CMS workload management CRAB3 was proposed in 2015, demonstrating the possibility of using BOINC as “manager” of volunteer resources and adapting the “vacuum” concept with the HTCondor Glidein system to get CMS pilots and jobs to execute on volunteers' computers. Since then, the integration of volunteer machines with the CMS workload management WMAgent, the official service dedicated to data production, has been seriously considered. The characteristics of volunteer resources regarding bandwidth capacity, connection behavior, and CPU and RAM capacities make them suitable for low-priority workflows with low I/O demands.The poster describes how the configuration of volunteer resources has evolved to keep pace with the development of the CMS computing infrastructure, including using tokens for resource authentication, exploiting regular expressions to accept workflows, manual glideins to initiate pilots, and other implementation details to achieve successful workflows. Currently volunteers are able to execute task chains of multicore jobs and, despite their limitations, are contributing to CMS computing capacity with around 600 cores daily.