• Main analysis framework for the FCC collaboration
  • Built on ROOT RDataFrame — declarative, multi-threaded
  • Reads EDM4hep data natively
  • C++ kernels with a Python user interface
• Served the Feasibility Study Report phase well
  • Fast simulation studies, parametric performance analyses
  • Now evolving to meet the demands of the Reference Design phase — full simulation, larger datasets, stricter reproducibility
• Manages the full analysis chain
  • Dataset metadata resolution
  • Local & distributed execution
  • Staged and histmaker analysis styles
• Distributed in the Key4hep stack:
  source /cvmfs/sw.hsf.org/key4hep/setup.sh
• github.com/HEP-FCC/FCCAnalyses

• Analysis is composed from functions/functors operating on RDataFrame columns — ideally small and stateless
  • Particle kinematics, jet finding (FastJet), dN/dx, ML inference (ONNX, TMVA), …
• Two layers of analyzers:
  • External (ROOT RVec, EDM4hep utils, RAL)
  • FCCAnalyses standard library — encourage upstream contributions
• Analysis-specific extensions via .hxx header
  • JIT-compiled by ROOT at startup — no extra build step
  • Old CMake-based extension method deprecated
• Fork development model creates analyzer copies across groups
  • Goal: reduce duplication by upstreaming shared functions
• podio::DataSource — native EDM4hep reading in RDataFrame
  • Lazy reading being added to ROOTReader and RNTupleReader — podio#949

• Analysis is now encapsulated in a Python class
  • CLI arguments passed through, for user level arguments
• Helper functions widely used in practice
  • Multiple RDataFrame Define / Filter calls wrapped into a single operation
  • Often the C++ expression strings are templated
• Unified CLI interface:
  fccanalysis run ana.py
fccanalysis final final.py
fccanalysis plots plots.py
• Dataset metadata resolved automatically from FCC Physics Events
  • Interface under overhaul → API calls
• New Job class recent
  • One unit of local work → one output ROOT file
  • Encapsulates RDataFrame setup, event counts, benchmarking info

Staged

• Analysis split into multiple sequential stages — each writing intermediate output to disk
• Often requires running algorithms typically done at reconstruction level — e.g. vertexing, jet clustering
• Specialised ML training stage often inserted between stages — not managed by FCCAnalyses; inference then run back through FCCAnalyses
• Intermediate files written to disk — each stage can be re-run independently
• Well-suited for analyses working with large datasets where re-running the full chain is expensive

Histmaker

• Single-pass: histograms filled directly from EDM4hep input
• No intermediate ntuples — lower disk footprint
• Uses RDataFrame RunGraphs for concurrent processing of all samples
• Good for exploratory work and quick iteration on observables
• Well-suited for well-defined analyses with a fixed set of observables

• Physics reach assessment
  • Benchmark analyses: e⁺e⁻ → ZH, WW, Z pole, …
  • Results hosted in FCCeePhysicsStudies and FCChhPhysicsPerformance
  • Process started to define analysis-level format and technical solution
  • In process of nominating flagship analyses to drive software requirements
• Physics groups under FCC PED new
  • Formal physics group structure now in place for the Reference Design phase
  • Groups drive analysis requirements and coordinate physics reach studies
• Detector performance
  • Multiple concepts studied in parallel: IDEA, CLD, ALLEGRO, ILD, ALFA
  • Full simulation samples from ddsim + k4geo
  • Detector-specific analyzers (dN/dx, track parameters, …)
  • Simultaneous support for fast simulation (Delphes) and full simulation

Integrated within FCCAnalyses

Distributed execution driven from within FCCAnalyses

• HTCondor — production-ready
  • fccanalysis submit ana.py
  • Widely used in combination with centrally produced samples
• DIRAC / iLCDirac — grid submission
  • Serious dataset production campaign planned for October
  • iLCDirac application for FCCAnalyses planned
• RDataFrame distributed module
  • Apache Spark, Dask as possible backends — not yet used at FCC
• Future: Slurm and other batch platforms

External workflow management

FCCAnalyses used as an executable orchestrated from outside

• Flare — b2luigi-based orchestration
  • Handles complex multi-stage analysis pipelines
  • Integrates directly with Key4hep executables
  • Runs on HTCondor, Slurm and LSF — DIRAC (via gbasf2) and others possible
  • See also: Flare: an open source data workflow orchestration tool — C. Harris et al., this conference
• Other workflow tools possible — Key4hep has no preferred tool

• Dataset production via DIRAC/iLCDirac
  • Testing campaign ongoing — first serious campaign planned for October
  • Starting efforts for DiracX at FCC new
• Dataset management via Rucio
  • ~1.4 PB registered across 6 sites: CERN, BARI, CNAF, MIT, DESY, GLASGOW, IEP SAS
  • Token-native, role-based setup being finalized
  • ESCAPE xRIDGE data challenge completed — concluding testing phase
  • Open to test users Q3 2026; distributed compute integration Q4 2026
• FCC Physics Events — dataset metadata portal
  • API endpoint for JSON metadata — FCCAnalyses resolves sample locations via it
  • More APIs planned: dataset request, provenance, catalog access, …
  • Designed to be tooling-agnostic — any framework can consume them
• Dataset Request System in development
  • Formalises how physics requests enter the production pipeline
  • Plans to integrate with FCC Physics Events

• Analysis registries — FCCeePhysicsStudies and FCChhPhysicsPerformance
  • Community hubs for analysis code, results and documentation
• eedE — EDM4hep Event Data Explorer
  • Web-based, interactive EDM4hep event content exploration
• Phoenix — web-based 3D event display
  • Interactive detector and track visualization
• CMS Combine — statistical analysis framework
  • GSoC 2026: proper integration into the Key4hep stack and FCCAnalyses in progress
• Improve plotting tools — effort started, may involve external tools
• Upstream improvements: TupleWriter in k4FWCore, podio::DataSource performance
• Overcoming silos: Key4hep ↔ PyHEP ↔ DiracOS ↔ Rucio
• Full simulation flagship analyses will drive requirements in the Reference Design phase
• Interoperability with the broader HEP software ecosystem is a key goal

High priority

• Analysis-level data model
  • Identify needed observables & reco algorithms; define suitable file format
• Reorganize analyzer library
  • Improve coherence and coverage; coordinate with ROOT RDF team
• ML as first-class citizen
  • Rethink architecture to properly support current ML analysis needs
• Debug-level visualization
  • Visual debugging at any stage of the event processing chain

Medium priority

• Event weights & systematic uncertainties support
• Redesign plotting — quick plots, ratio plots, publication-level
• Expand distributed computing — GRID, Slurm, GPU resources
• Robust analysis APIs & full dataset provenance
• User-driven workflow management
• Fitting tools integration — CMS Combine, zfit, RooFit, …

• Particles
  • MCParticle — generator-level particle access
  • ReconstructedParticle — reco particle kinematics & selection
  • ReconstructedParticle2MC, ReconstructedParticle2Track — associations
• Tracks
  • ReconstructedTrack, TrackUtils — track parameters & utilities
• Jets
  • JetClusteringUtils — FastJet interface
  • JetConstituentsUtils, JetFlavourUtils, JetTaggingUtils

• Vertexing
  • VertexFinderActs, VertexFinderLCFIPlus
  • VertexFitterActs, VertexFitterSimple
• Smearing & fast simulation
  • SmearObjects, Smearing
• ML inference
  • WeaverUtils — ONNX-based neural network inference
• Calorimetry & utilities
  • CaloNtupleizer, EventFilter, Algorithms
• FCC-hh specific: Analysis_FCChh