ROOT zur wissenschaftlichen Analyse von Petabyte-Daten

 (root.cern)
1 Punkte von GN⁺ 2024-06-02 | 1 Kommentare | Auf WhatsApp teilen
  • Unterstützt die für Großforschung wie Hochenergiephysik nötige Massendatenverarbeitung und wissenschaftliche Analyse; derzeit sind in ROOT-Dateien mehr als 2 Exabyte Daten gespeichert
  • ROOT wurde auch bei der Entdeckung des Higgs eingesetzt und ist damit ein Werkzeug mit bewährten Praxiseinsätzen in der Analyse experimenteller Daten
  • Als Open Source frei nutz- und veränderbar; über einen öffentlichen Entwicklungsprozess werden Beiträge von Nutzern angenommen
  • Der mitgelieferte C++-Interpreter eignet sich für schnelles Prototyping, und über dynamische Python-Bindings ist der Zugriff auf alle Komponenten möglich
  • Unterstützt auch Jupyter Notebooks, sodass Analysen auf Basis von C++ und Python in Notebook-Umgebungen erweitert werden können; zudem werden weiterhin Neuigkeiten zu Releases, Schulungen und Hackathons veröffentlicht

Die Rolle von ROOT in der Datenanalyse

  • ROOT ist ein Werkzeug, das die Verarbeitung großer Datenmengen und wissenschaftliche Analysen ermöglicht

Open-Source-Entwicklung und Beiträge

Nutzung mit C++, Python und Notebooks

Blog- und Release-Neuigkeiten

  • Zu den jüngsten Blog-Einträgen gehören Einladungen zur YouTube-Premiere der C++-Dokumentation, ein Trailer zur ROOT- und C++-Dokumentation, der ROOT Advanced Course 2026 sowie Beiträge zum 3rd ROOT Hackathon
  • Die Liste der neuesten Releases enthält die folgenden Versionen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-06-02
Hacker-News-Kommentare

  • Das weckt Erinnerungen. Als ich in der Teilchenphysik gearbeitet habe, habe ich ROOT viel genutzt und hatte eine Hassliebe dazu.
    Einerseits gab es viel technische Schuld und eigenartige Trägheiten, andererseits waren manche Dinge in ROOT deutlich einfacher als mit „moderneren“ Optionen wie matplotlib. Zum Beispiel Histogramme, stark strukturierte Daten, bei denen Objekte mit Feldern in „Spalten“ liegen, oder das direkte Zeichnen von Funktionen, ohne separate x/y-Arrays zu allokieren.
    Auch die intuitive objektorientierte API mochte ich. Sie fühlte sich eher wie altmodisches C++ oder Java an als wie pandas/matplotlib mit Method Chaining, überstrapazierter []-Syntax und allerlei magischem Verhalten. Nicht elegant und ziemlich wortreich, aber für wissenschaftliche Analysen kann das sogar ein Vorteil sein.
    Als ich vor etwa fünf Jahren ausgestiegen bin, war ROOT im Wandel: Der alte CINT-Interpreter wurde entfernt und man war auf eine clang-basierte Codebasis umgezogen. Soweit ich weiß, kann man heute Analysen in C++ oder Python in Jupyter laufen lassen, und ich habe gehört, dass die Codequalität deutlich besser geworden ist.

    • Das Beste an ROOT war die Art des Datenladens. TTrees, die spaltenbasiert von der Platte geschnitten gelesen werden, waren eine wirklich gute Idee, und auch nach meinem Wechsel in die Industrie nach dem Abschluss suche ich immer wieder nach etwas, das genauso funktioniert.
    • Vielleicht weil matplotlib nicht histogrammzentriert ist, oder weil heute genug RAM vorhanden ist, sieht man oft nutzlose Streudiagramme mit viel zu vielen überlappenden Punkten. Schwer anzusehen.
    • Alle haben eine Hassliebe zu ROOT. Es fühlt sich ein bisschen wie Stockholm-Syndrom an.
    • Ich frage mich, ob Haskell gut geeignet wäre, so etwas zu bauen.
    • Heutzutage ist die furchtbare API von matplotlib dank ChatGPT nicht mehr so ein großes Problem wie früher.

  • Es gibt nicht viele Gründe, warum neue Analysen standardmäßig ROOT verwenden sollten. Besser nimmt man etwas Benutzerfreundlicheres und Vernünftigeres wie uproot.
    Es mag Legacy-Workflows geben oder Experimente, die viele eigene Patches auf ROOT aufgebaut haben, aber rein für physikalische Analysen kann das eine Entscheidung sein, mit der man sich selbst quält.
    Die 404-Seite gefällt mir auch. Und nein, es geht nicht um room 404.
    https://github.com/scikit-hep/uproot5
    https://root.cern/404/

    • Eine häufige Kritik an uproot ist, dass es unflexibel wird, wenn Berechnungen zeilenweise kompliziert werden. Der Grund ist, dass for-Schleifen in Python zu langsam sind.
      In solchen Fällen kann man Numba verwenden oder, wenn es gerade gut funktioniert, ansonsten als schamlose Eigenwerbung Julia: https://github.com/JuliaHEP/UnROOT.jl
      Frühere HN-Diskussion über Julia in der Teilchenphysik: https://news.ycombinator.com/item?id=38512793

  • Es ist beeindruckend, große Softwareprojekte zu sehen, die für wissenschaftliche Entdeckungen genutzt werden.
    Ein weiteres Beispiel: Bei LIGO wurden Gravitationswellen mit GStreamer gefunden: https://lscsoft.docs.ligo.org/gstlal/

    • Hier ist es eher das Gegenteil. CERN brauchte ein Framework zur Datenanalyse, also hat CERN es entwickelt, gepflegt und veröffentlicht.
      Ob es allerdings eine gute Idee ist, dass Außenstehende es tatsächlich verwenden, weiß ich nicht. Meine Erfahrung ist vielleicht etwas veraltet, aber es war ziemlich grob und altbacken. Der große Vorteil bei CERN- oder Teilchenphysik-Arbeit ist, dass es praktisch Standard ist und die interne Zusammenarbeit erleichtert.
    • Diese beiden Beispiele sind ziemlich unterschiedlich. ROOT ist ein mächtiges Datenanalyse-Framework, aber trotz seiner Stärke wurde es nie ausreichend allgemein nutzbar und einfach bedienbar, sodass es kaum über die Hochenergiephysik hinausgekommen ist.
      GStreamer dagegen ist eine schön entworfene Plattform, deren Architektur so gut ist, dass sie sich leicht abstrahieren und in völlig anderen Szenarien wiederverwenden lässt, die sich die ursprünglichen Entwickler vermutlich nie vorgestellt hätten.
    • Nicht beeindruckend ist, dass ROOT von Leuten „entworfen“ und gebaut wurde, die offenbar überhaupt nicht wussten, wie man große Softwareprojekte betreibt.
      Die Spuren sieht man überall. Es ist ein riesiger Monolith, sodass man ständig kämpfen muss, sobald man etwas auch nur leicht Ungewöhnliches tun will. Zum Glück muss ich es nicht oft verwenden, aber ich habe immer noch bis zu einem gewissen Grad damit zu tun.
    • „Gravitationswellen wurden bei LIGO mit GStreamer gefunden“? Wie bitte?!

  • Persönlich finde ich, dass ROOT zu viel auf einmal sein will, ein schlechtes API-Design hat und vor allem ROOT als Bibliothek und ROOT als Programm nicht voneinander getrennt sind.
    Es gibt viel globalen Zustand, und es liegt die Annahme zugrunde, dass die Leute es im Stil des ROOT-Programms verwenden sollen. ROOT 6 hat begonnen, einige Dinge zu korrigieren, aber das dauert, und persönlich glaube ich, dass die starke Abhängigkeit von llvm und clang die Build-Zeiten weiter verlängert und es als Projekt schwerer reparierbar gemacht hat.
    Lange Zeit war auch die Dokumentation des Ein-/Ausgabeformats dürftig, und es gab nur eine Implementierung.
    Heute kann man dank groot, uproot, freehep, openscientist und anderen ROOT-Daten lesen und schreiben, ohne das gesamte ROOT mitzuschleppen. Interoperabilität bei Daten halte ich für sehr wichtig. Sie ist notwendig, wenn man hoffen will, diese einzigartigen Daten auch in 20 oder 30 Jahren noch einmal lesen zu können.
    https://go-hep.org/x/hep/groot
    Ich bin der Hauptentwickler von go-hep.

    • Soweit ich weiß, hat uproot das Lesen von TEfficiency immer noch nicht richtig implementiert, und ehrlich gesagt ist das schade.

  • Ach, root … ich bin dankbar, dass ich nicht jeden Tag eine Version vor 6 verwenden muss.

    • Root war einer der Gründe, warum ich mich gegen ein Studium der Teilchenphysik entschieden habe.
    • Ich warte immer noch auf Version 7, die root endlich gut machen sollte, selbst wenn dafür Interfaces gebrochen werden. Ich glaube, ich habe um 2016 zum ersten Mal davon gehört; es wirkt wirklich wie ein verdampftes Versprechen.

  • Das erinnert mich an die späten Nächte, in denen ich Code von brillanten Physikern ohne Informatikhintergrund debuggt habe.

    • Um 2013 habe ich bei einer Online-Kreditplattform gearbeitet, die Teilchenphysiker eingestellt hatte, um Modelle zur Risikovorhersage zu bauen.
      Sie verwendeten ROOT für das Modeling und bauten die Interfaces in Ruby, und aus Sicht des Software Engineering war das ein Monster. Aus statistischer Sicht war es aber ziemlich ordentlich.
      Das war lange bevor das Python-Ökosystem groß wurde, und auch die Machine-Learning-Pakete in R standen gerade erst am Anfang.
    • Ich stelle mir eine main() mit 2000 Zeilen vor.

  • Root ist zwar das Rückgrat enorm vieler Arbeit in der experimentellen Teilchenphysik, aber für neue Doktoranden auch ein Albtraum.
    Es ist praktisch tief in der Teilchenphysik verankert, daher dürfte sich daran in absehbarer Zeit nichts ändern.

    • Heute gibt es pyroot und uproot, sodass neue Doktoranden leichter zu lernende Optionen haben; so schlimm ist es also nicht mehr.
      Das Problem liegt meist in Legacy-Code, der als Teil experimenteller Services gewartet werden muss.

  • Der Teil von Root, den ich nutze, ist Cling, der C++-Interpreter, und Xeus für Jupyter-Notebooks.
    Eines Nachts habe ich das schnellste n-body von benchmarkgames in Xeus mit Python 3 verglichen. Auf derselben Binder-Instanz brauchte Xeus 15,58 Sekunden, während der schnellste Python-Code mit dem Python3-Kernel 5 Minuten dauerte. Die Ausgabe war bei beiden Läufen exakt gleich.
    Selbst wenn man den Overhead für dynamische C++-Ausführung in diesem Programm mit etwa 300 % ansetzt, ist Cling sehr schnell. SIMD oder Vektorisierung wurden nicht genutzt, nur der Code von benchmarkgames. Ich verwende Cling hauptsächlich als schnellen JIT-Ersatz für Sprachen, die nach C++ kompiliert werden.

    • Ich verwende Cling für die JIT-Kompilierung meines nativen Clojure-Dialekts: https://github.com/jank-lang/jank
      Der Versuch besteht darin, C++ in die Clojure-Welt zu bringen und Clojure sowie interaktive Programmierung in die C++-Welt.

  • Quellcode: https://github.com/root-project

  • „Debugging von CERN-ROOT-Skripten und ROOT-basierten Programmen in der Eclipse-IDE“
    Meine Güte, da kommen Albträume hoch. Es zeigt eindeutig, dass man selbst in schrecklichen Umgebungen Außergewöhnliches schaffen kann.

    • Ich bin mir nicht sicher, ob es hier um Eclipse geht.