Speaker
Description
To get the most information out of the LHC dataset, a physics analysis has to be globally optimized from event generation to statistical inference.
Automatic Differentiation (AD) is one of the cornerstones of ML/AI. Applying AD to simulation and analysis codes is also very appealing for optimizing next-generation HEP analysis. For example, augmenting simulated data with gradients helps to extract more information from the simulation, which is very expensive in terms of compute power, especially in the HL-LHC era.
Another example of applying ML tools to HEP analysis is to learn analytical surrogate models for simulated data, for use in Simulation-Based Inference (SBI).
To maximize the potential of such approaches, we need to bridge the gap between traditional HEP research codes and modern ML techniques to build sustainable, transparent, and reproducible ML-driven physics analysis.
Mainstream ML tools such as PyTorch, TensorFlow, and JAX are primarily developed for commercial use cases. These tools are often not well-suited for HEP applications: they assume Python-based workflows, are difficult to integrate with established C++ codebases, and are not compatible with long-term support models characterising HEP software. Moreover, the governance and development priorities of these tools rarely align with those of the research community and such priorities are difficult to influence.
Continued reliance on external, industry-driven ML tools introduces long-term risks. These include loss of technical control, limited flexibility to adapt tools for novel research directions, and potential incompatibility with established HEP software environments.
For example: we can already anticipate from following LLM development that the boundary between model training and deployment becomes more blurry. The most advanced models continue training themselves in production. As the aforementioned Python libraries are difficult to integrate into our C++ production software, we risk being unable to implement such advanced online/continuous learning techniques.
CERN and the broader HEP community should invest in in-house software to mitigate these risks.
ROOT already hosts key technologies that bridge the gap between HEP codes and the Python AI ecosystem, and also a solid Automatic Differentiation engine:
* Cling: a just-in-time C++ interpreter, enabling dynamic execution and integration of compiled and interactive code.
* Clad: an AD engine for C++, already integrated with frameworks like RooFit and CMS Combine.
* Python bindings: enabling hybrid C++/Python workflows for increased flexibility.
This means there is no high remaining cost to turn ROOT into a framework for differential analyses that natively supports deep learning, and also integrates well with existing HEP codes written in C++.
The technological cornerstones listed above have demonstrated initial success:
* Differentiation through complex, branching C++ code (e.g., RooFit, CMS Combine). [1]
* Early prototypes supporting autodiff in stochastic simulations, such as Geant4 (via HepEmShow). [2]
* Modernization of ROOT’s statistical tools for compatibility with ML surrogate models for SBI. [3]
We propose targeted R&D to consolidate these capabilities into a coherent, ML-compatible infrastructure for simulation-based analysis and beyond. This includes:
- Enable AD for ROOT classes and functions that are relevant for differential analysis and implementing deep learning models in C++ (e.g. linear algebra, vector operations, LorenzVectors).
- Supporting stochastic models, random number generators, and uncertainty propagation in autodiff pipelines.
Extending AD support for C++ code bases beyond ROOT (e.g. Delphes for fast simulation and detector studies). - Build a complete differentiable physics analysis demonstrator from simulation to statistical analysis using ROOT plus an external simulator/reconstruction software.
Ultimately, this should lay the groundwork for future analyses that tightly integrate ML without relying on industry codes and that run in stable production environments, both online and offline.
[1] https://indico.cern.ch/event/1291157/contributions/5889615/attachments/2900877/5087038/roofit_ichep_2024.pdf
[2] Aehle, Max, et al. "Optimization using pathwise algorithmic derivatives of electromagnetic shower simulations." Computer Physics Communications 309 (2025): 109491.
[3] https://indico.cern.ch/event/1338689/contributions/6016195/attachments/2953278/5192036/RooFit%20CHEP%202024-2.pdf
CERN group/ Experiment
EP-SFT
| Working area | Area 4: AI Infrastructure for Model Training |
|---|---|
| Project goals | Intermediate goal 1: Make sure ROOTs basic math and Linear Algebra functions can be differentiated by AD tools like Clad and can be used to compose neural network architectures that natively integrate into ROOT and can incorporate ROOT’s HEP specific Math functions. Intermediate goal 2: Implement differentiable solutions/approximations for other operations in typical HEP analyses (e.g. Monte Carlo simulation, random number generators, histogramming, uncertainty estimation and propagation) to provide all primitives needed for differential analysis from simulation to statistical interpretation. Final goal: Turn ROOT into a framework for differential analyses that natively supports deep learning, and also integrates well with existing HEP codes written in C++. |
| Timeline | Year 1: Reach intermediate goal 1 : implement differential primitives for neural networks in ROOT, adapting current ROOT Math Year 2: Reach intermediate goal 2 : assemble necessary functionality for differential analysis in ROOT - from event loop to statistical interpretation, which is the part of the analysis usually implemented in ROOT Year 3: To show that the final project goal has been achieved: build full differentiable analysis example that uses ROOT at its core, but also uses other common HEP C++ code codes, e.g. Delphes for parametric simulation. |
| Available person power | 0 |
| Additional person power request | 1 Graduate (2 - 3 years) |
| Is this an already ongoing activity? | No |
| Indicative hardware resources needs | 1 PC with GPU |