How To Cite FLARE

If you use FLARE to orchestrate your Monte Carlo production or FCCAnalyses workflows, please cite us using the below citation.

@article{COOPERHARRIS2026110062,
    title = {FLARE: FCCee b2Luigi Automated Reconstruction and Event processing},
    journal = {Computer Physics Communications},
    volume = {322},
    pages = {110062},
    year = {2026},
    issn = {0010-4655},
    doi = {https://doi.org/10.1016/j.cpc.2026.110062},
    url = {https://www.sciencedirect.com/science/article/pii/S0010465526000445},
    author = {Cameron {Cooper Harris} and Aman Desai},
    keywords = {Future circular collider, Collider physics, b2luigi, Automated workflow, Key4HEP},
    abstract = {FLARE is an open source data workflow orchestration tool designed for the FCC Analysis software and Key4HEP stack. Powered by b2luigi, FLARE automates and orchestrates the fccanalysis stages from start to finish. Furthermore, FLARE is capable of managing the Monte Carlo (MC) data workflow using generators inside the Key4HEP stack such as Whizard, MadGraph5_aMC@NLO, Pythia8 and Delphes. In this paper the FLARE v0.1.4 package will be explored along with its extensible capabilities and a feature rich work environment. Examples of FLARE will be discussed in a variety of use-cases, all of which can be found at https://github.com/CamCoop1/FLARE-examples. The open source repository of FLARE can be found at https://github.com/CamCoop1/FLARE PROGRAM SUMMARY Program title: FLARE CPC Library link to program files: https://doi.org/10.17632/dj4d6fsg3j.1 Developer’s repository link: https://github.com/CamCoop1/FLARE Licensing provisions: MIT license Programming Language: Python Supplementary material: https://pypi.org/project/hep-flare/, https://zenodo.org/records/15694669 Nature of problem: FCC Analysis tooling [1] and by extension the Key4HEP stack [2] are excellent packages easily served by the Cern Virtual Machine File System. However, little exists to rigourously automate the running of these packages, making workflow management and reproducibility difficult to handle. FLARE aims to fill this need by building the architecture necessary to manage and run these packages for an user with very little input. Solution method: FLARE uses the b2luigi [3] python package to bundle the FCC analysis package [1] and various Monte Carlo generators from the Key4HEP stack [2] into so called ’Tasks’. These Tasks are built using a design philosophy similar to Github Actions, which we refer to as FLARE Workflows. These Workflows are declared inside a YAML file and programmatically bundled into b2luigi Tasks. FLARE can automatically run the entire workflow for a user from a single command line execution, ensuring the correct ordering of Tasks occurs and runs the entire workflow to completion without the need for a users input. FLARE can also connect its FLARE Workflows to build even bigger more complex chains of Tasks all of which will be ran and handled by b2luigi in the background. Although originally designed to solve a problem specific to the FCC Analysis tooling, extensibility is at the heart of FLARE. New FLARE Workflows can be added in the future to bundle other CLI packages similar to FCC Analysis and allows for any FLARE Workflow to be joined together to create larger more dynamic and complex data pipelines. Additional comments including restrictions and unusual features: FLARE can generate Monte Carlo using a variety of generators such as MadGraph5_aMC@NLO [4], Whizard [5], Pythia [6–7] and Delphes [8]. It also has the ability to generate any number of Monte Carlo datasets in parallel by submitting to the local batch system of a server. This is a feature of b2luigi that FLARE leverages, enabling a user to submit to HTCondor [9], LSF [10] and Slurm [11] batch systems. This powerful feature of b2luigi allows FLARE to generate any number of Monte Carlo datasets using any number of generators at the exact same time. Additionally, FLARE can easily generate Monte Carlo using different Key4HEP Physics Detector cards, enabling a user to easily conduct analyses on different detector configurations References:1.C. Helsens, E. Perez, M. Selvaggi, V. Volkl, L. Forthomme, and J. Munch Torndal, Hep-fcc/fccanalyses: v0.11.0 (2025).2.A. Sailer et al. (Key4hep), The Key4hep software stack: Beyond Future Higgs factories, in 21th International Workshop on Advanced Computing and Analysis Techniques in Physics Research: AI meets Reality (2023), arXiv:2312.08151 [hep-ex].3.A. Heidelbach et al., belle2/b2luigi: v1.2.2 (2025).4.J. Alwall et al., The automated computation of tree-level and next-to-leading order differential cross sections, and their matching to parton shower simulations, JHEP 2014, 10.1007/jhep07(2014)079.5.W. Kilian, T. Ohl, and J. Reuter, WHIZARD-simulating multi-particle processes at LHC and ILC, Eur. Phys. J. C 71, 1742 (2011).6.T. Sjöstrand, S. Mrenna, and P. Z. Skands, PYTHIA 6.4 Physics and Manual, JHEP 05, 026, arXiv:hep-ph/0603175.7.T. Sjöstrand et al., An introduction to PYTHIA 8.2, Comput. Phys. Commun. 191, 159 (2015), arXiv:1410.3012 [hep-ph].8.J. de Favereau et al. (DELPHES3), DELPHES 3: A modular framework for fast simulation of a generic collider experiment, JHEP 02, 057, arXiv:1307.6346 [hep-ex].9.D. Thain, T. Tannenbaum, and M. Livny, Distributed computing in practice: The Condor experience, Concurrency: Practice and Experience 17, 323 (2005).10.IDM Platform LSF, Platform LSF version 9 release 1.3.11.A. B. Yoo, M. A. Jette, and M. Grondona, Slurm: Simple Linux Utility for Resource Management (2003).}
}