ROOT, pour analyser scientifiquement des données à l’échelle du pétaoctet

 (root.cern)
1 points par GN⁺ 2024-06-02 | 1 commentaires | Partager sur WhatsApp
  • ROOT prend en charge le traitement de gros volumes de données et l’analyse scientifique nécessaires aux recherches de grande ampleur comme la physique des hautes énergies, et plus de 2 exaoctets de données sont actuellement stockés dans des fichiers ROOT
  • ROOT a aussi été utilisé pour la découverte du Higgs, ce qui en fait un outil disposant d’un cas d’usage réel et éprouvé pour l’analyse de données expérimentales
  • Disponible en open source, il peut être utilisé et modifié librement, et accepte les contributions des utilisateurs via un processus de développement ouvert
  • Le interpréteur C++ fourni convient au prototypage rapide, et les liaisons dynamiques Python donnent accès à tous les composants
  • La prise en charge des notebooks Jupyter permet aussi d’étendre les analyses en C++ et Python à un environnement de notebook, tandis que les annonces de releases, de formations et de hackathons continuent d’être publiées

Le rôle de ROOT dans l’analyse de données

  • ROOT est un outil qui permet le traitement de grands volumes de données et leur analyse scientifique

Développement open source et contributions

Utilisation avec C++, Python et les notebooks

Articles de blog et annonces de releases

  • Parmi les récents billets de blog figurent l’invitation à la mise en ligne sur YouTube du documentaire C++, la bande-annonce du documentaire ROOT et C++, le ROOT Advanced Course 2026 et un article sur le 3rd ROOT Hackathon
  • La liste des dernières releases comprend les versions suivantes

À lire aussi

1 commentaires

 
GN⁺ 2024-06-02
Commentaires Hacker News

  • Ça me rappelle des souvenirs. Quand je travaillais en physique des particules, j’utilisais beaucoup ROOT, et j’avais une relation d’amour-haine avec lui.
    D’un côté, il y avait beaucoup de dette technique et une inertie particulière, mais de l’autre, certaines choses étaient nettement plus faciles dans ROOT qu’avec des options plus « modernes » comme matplotlib. Par exemple les histogrammes, les données très structurées où des objets avec des champs sont stockés en « colonnes », ou encore le tracé direct de fonctions sans allouer séparément des tableaux x/y.
    J’aimais aussi son API orientée objet assez intuitive. Ça ressemblait davantage à du vieux C++ ou à Java qu’au chaînage de méthodes de pandas/matplotlib, à l’abus de la syntaxe [] et à toutes sortes de comportements magiques. Ce n’était pas élégant, c’était verbeux, mais en analyse scientifique cela peut au contraire être un avantage.
    Quand je suis parti il y a environ cinq ans, ROOT était en pleine mutation : l’ancien interpréteur CINT avait été retiré et le projet était passé à une base de code fondée sur clang. Je crois qu’aujourd’hui on peut lancer des analyses dans Jupyter en C++ ou en Python, et j’ai entendu dire que la qualité du code s’était beaucoup améliorée.

    • Le meilleur aspect de ROOT, c’était sa façon de charger les données. Le TTree, qui lit des tranches par colonnes depuis le disque, était vraiment une excellente idée, et depuis que je suis passé dans l’industrie après mon diplôme, je continue à chercher des choses qui fonctionnent de la même manière.
    • Peut-être parce que matplotlib n’est pas centré sur les histogrammes, ou parce qu’on a aujourd’hui assez de RAM, je vois souvent des nuages de points inutiles avec tellement de points superposés. C’est pénible à regarder.
    • Tout le monde a une relation d’amour-haine avec ROOT. Ça ressemble un peu au syndrome de Stockholm.
    • Je me demande si Haskell serait aussi adapté pour fabriquer ce genre de chose.
    • De nos jours, grâce à ChatGPT, l’API horrible de matplotlib n’est plus un aussi gros problème qu’avant.

  • Il n’y a pas beaucoup de raisons pour lesquelles une nouvelle analyse devrait utiliser ROOT par défaut. Mieux vaut utiliser une option plus conviviale et plus saine comme uproot.
    Il peut y avoir des workflows legacy, ou des expériences qui ont empilé beaucoup de patchs personnalisés sur ROOT, mais pour une analyse de physique en soi, cela peut être une façon de se faire du mal.
    J’aime aussi leur page 404. Et ce n’est pas une référence à la room 404.
    https://github.com/scikit-hep/uproot5
    https://root.cern/404/

    • Une critique fréquente d’uproot est son manque de flexibilité quand les calculs ligne par ligne deviennent complexes. C’est parce que les boucles for en Python sont trop lentes.
      Dans ces cas-là, on peut utiliser Numba, quand cela fonctionne bien, ou, pour faire une autopromotion éhontée, Julia : https://github.com/JuliaHEP/UnROOT.jl
      Ancienne discussion HN sur l’usage de Julia en physique des particules : https://news.ycombinator.com/item?id=38512793

  • C’est chouette de voir de grands projets logiciels utilisés pour des découvertes scientifiques.
    Autre exemple : LIGO a utilisé GStreamer pour détecter des ondes gravitationnelles : https://lscsoft.docs.ligo.org/gstlal/

    • Ici, c’est presque l’inverse. Le CERN avait besoin d’un framework d’analyse de données, donc le CERN l’a développé, maintenu et rendu public.
      En revanche, je ne sais pas si c’est une bonne idée pour des personnes extérieures de l’utiliser réellement. Mon expérience date peut-être un peu, mais c’était assez brut et vieillissant. Son grand avantage au CERN ou dans les travaux de physique des particules, c’est que c’est de facto un standard, ce qui facilite la collaboration interne.
    • Ce sont deux exemples assez différents. ROOT est un puissant framework d’analyse de données, mais malgré cette puissance, il n’a pas su devenir assez généraliste et facile à utiliser pour vraiment sortir de la physique des hautes énergies.
      GStreamer, en revanche, est une plateforme à la conception élégante, avec une architecture suffisamment bonne pour être abstraite et réutilisée facilement dans des scénarios totalement différents, que ses créateurs n’avaient probablement jamais imaginés.
    • Ce qui est moins chouette, c’est que ROOT a été « conçu » et construit par des gens qui ne savaient absolument pas comment mener un grand projet logiciel.
      On en voit les traces partout. C’est un énorme monolithe, et dès qu’on essaie de faire quelque chose d’un peu non standard, il faut se battre avec lui. Heureusement, je n’ai pas souvent à l’utiliser, mais j’y suis encore exposé dans une certaine mesure.
    • « LIGO a détecté des ondes gravitationnelles avec GStreamer » ? Pardon ?!

  • Personnellement, je trouve que ROOT essaie de faire beaucoup trop de choses, que la conception de son API est mauvaise, et surtout qu’il n’y a pas de séparation entre ROOT en tant que bibliothèque et ROOT en tant que programme.
    Il y a beaucoup d’état global, et l’hypothèse sous-jacente est que les gens doivent l’utiliser à la manière du programme ROOT. ROOT 6 a commencé à corriger une partie de cela, mais ça prend du temps, et personnellement je pense qu’en s’appuyant trop profondément sur llvm et clang, il a encore allongé les temps de build et rendu le projet plus difficile à corriger.
    Pendant longtemps, la documentation du format d’entrée/sortie était aussi très pauvre, et il n’y avait qu’une seule implémentation.
    Aujourd’hui, grâce à groot, uproot, freehep, openscientist, etc., on peut lire et écrire des données ROOT sans embarquer tout ROOT. Pour les données, l’interopérabilité est extrêmement importante à mes yeux. Elle est indispensable si l’on veut avoir l’espoir de relire ces données uniques dans 20 ou 30 ans.
    https://go-hep.org/x/hep/groot
    Je suis le développeur principal de go-hep.

    • À ma connaissance, uproot ne sait toujours pas lire correctement TEfficiency, et franchement c’est dommage.

  • Ah, root… ça me rend reconnaissant de ne pas avoir à utiliser tous les jours une version antérieure à la 6.

    • Root a été l’une des raisons pour lesquelles j’ai décidé de ne pas étudier la physique des particules.
    • J’attends toujours la version 7 qui devait enfin rendre root agréable, quitte à casser les interfaces. Je crois en avoir entendu parler pour la première fois vers 2016 ; on dirait vraiment une promesse évaporée.

  • Ça me rappelle les soirées passées à déboguer du code écrit par d’excellents physiciens, mais sans formation en informatique.

    • Vers 2013, je travaillais sur un site de prêts en ligne qui avait embauché des physiciens des particules pour construire un modèle de prédiction du risque.
      Ils utilisaient ROOT pour la modélisation et Ruby pour construire l’interface ; du point de vue du génie logiciel, c’était un monstre. Mais d’un point de vue statistique, c’était plutôt correct.
      C’était bien avant l’essor de l’écosystème Python, et les packages de machine learning en R en étaient tout juste à leurs débuts.
    • J’imagine un main() de 2 000 lignes.

  • Root est bien l’épine dorsale d’une quantité énorme de travaux en physique expérimentale des particules, mais c’est aussi un cauchemar pour les nouveaux doctorants.
    Il est tellement profondément ancré dans la physique des particules qu’il ne semble pas près de changer à court terme.

    • Aujourd’hui, avec pyroot et uproot, les nouveaux doctorants ont des options plus faciles à apprendre, donc ce n’est pas si terrible.
      Le problème se trouve généralement dans le code legacy qu’il faut maintenir dans le cadre des services expérimentaux.

  • La partie de Root que j’utilise, c’est Cling, l’interpréteur C++, et Xeus pour les notebooks Jupyter.
    Un soir, j’ai comparé le n-body le plus rapide de benchmarkgames entre Xeus et Python 3. Sur la même instance Binder, Xeus a pris 15,58 secondes, tandis que l’exécution du code Python le plus rapide avec le noyau Python3 a pris 5 minutes. La sortie était exactement la même dans les deux exécutions.
    Même en estimant l’overhead de l’exécution dynamique de C++ à environ 300 % dans ce programme, Cling reste très rapide. Je n’ai pas utilisé de SIMD ni de vectorisation, seulement le code de benchmarkgames. J’utilise surtout Cling comme alternative JIT rapide pour les langages qui se compilent principalement en C++.

    • J’utilise Cling pour la compilation JIT de mon dialecte Clojure natif : https://github.com/jank-lang/jank
      C’est une tentative d’amener C++ dans le monde Clojure, et Clojure ainsi que la programmation interactive dans le monde C++.

  • Code source : https://github.com/root-project

  • « Débogage de scripts CERN ROOT et de programmes basés sur ROOT dans Eclipse IDE »
    Mon Dieu, ça me rappelle des cauchemars. Cela montre clairement qu’on peut créer des choses extraordinaires même dans des environnements atroces.

    • Je ne sais pas bien si c’est Eclipse qui est visé.