ROOT, para analizar científicamente datos a escala de petabytes

 (root.cern)
1 puntos por GN⁺ 2024-06-02 | 1 comentarios | Compartir por WhatsApp
  • Soporta el procesamiento de grandes volúmenes de datos y el análisis científico que se requieren en investigaciones a gran escala, como la física de altas energías; actualmente, los archivos ROOT almacenan más de 2 exabytes de datos
  • ROOT también se usó en el descubrimiento del Higgs, por lo que es una herramienta con casos de uso reales comprobados en el análisis de datos experimentales
  • Al ser open source, se puede usar y modificar libremente, y recibe contribuciones de usuarios mediante un proceso de desarrollo abierto
  • El intérprete de C++ incluido es adecuado para prototipado rápido, y los bindings dinámicos de Python permiten acceder a todos sus componentes
  • También soporta Jupyter Notebook, lo que permite extender los análisis basados en C++ y Python a un entorno de notebooks; además, se siguen publicando noticias sobre releases, capacitaciones y hackatones

El rol de ROOT en el análisis de datos

  • ROOT es una herramienta que permite el procesamiento y el análisis científico de grandes volúmenes de datos

Desarrollo open source y contribuciones

Formas de uso basadas en C++, Python y notebooks

Noticias del blog y releases

  • Entre las entradas recientes del blog hay publicaciones sobre una invitación al estreno en YouTube del documental de C++, el tráiler del documental de ROOT y C++, el ROOT Advanced Course 2026 y el 3rd ROOT Hackathon
  • La lista de releases más recientes incluye las siguientes versiones

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-06-02
Comentarios en Hacker News

  • Me trae recuerdos. Cuando trabajaba en física de partículas usaba mucho ROOT y tenía una relación de amor-odio con él
    Por un lado, tenía mucha deuda técnica e inercias raras, pero por otro había bastantes cosas que eran más fáciles en ROOT que en opciones más “modernas” como matplotlib. Por ejemplo, histogramas, datos altamente estructurados con objetos que tienen campos metidos en “columnas”, o graficar funciones directamente sin asignar arreglos x/y por separado
    También me gustaba su API orientada a objetos e intuitiva. Se sentía más cercana al C++ o Java clásico que al method chaining de pandas/matplotlib, al abuso de la sintaxis [] y a varios comportamientos medio mágicos; no era elegante y sí verbosa, pero en análisis científico eso incluso puede ser una ventaja
    Cuando me fui, hace unos 5 años, ROOT estaba en transición, quitando el viejo intérprete CINT y migrando a una base de código basada en clang. Entiendo que ahora se pueden correr análisis en Jupyter con C++ o Python, y he escuchado que la calidad del código ha mejorado bastante

    • Lo mejor de ROOT era la forma de cargar datos. TTree, con lectura por columnas desde disco, fue una idea realmente buena, y desde que me gradué y me fui a la industria sigo buscando cosas que funcionen de la misma manera
    • Como matplotlib no está centrado en histogramas, o tal vez porque hoy en día hay suficiente RAM, ahora se ven muy seguido diagramas de dispersión inútiles con demasiados puntos superpuestos. Da dolor verlos
    • Todos tienen una relación de amor-odio con ROOT. Casi parece síndrome de Estocolmo
    • Me pregunto si Haskell también encajaría bien para construir algo así
    • Hoy en día, gracias a ChatGPT, la horrible API de matplotlib ya no es un problema tan grande como antes

  • No hay muchas razones para que un análisis nuevo tenga que usar ROOT por defecto. Es mejor usar algo como uproot, que es una opción más amigable y más sensata
    Puede haber flujos de trabajo legacy o casos donde cada experimento trae un montón de parches personalizados encima de ROOT, pero si hablamos solo de análisis de física, puede ser una forma de hacerse sufrir a uno mismo
    También me gusta la página 404. Y no, no hablo del cuarto 404
    https://github.com/scikit-hep/uproot5
    https://root.cern/404/

    • Una crítica común a uproot es que no es muy flexible cuando los cálculos por fila se vuelven complejos. Eso pasa porque los bucles for de Python son demasiado lentos
      En esos casos puedes usar Numba, cuando funciona bien, o si me permiten hacer autopromoción descarada, puedes usar Julia: https://github.com/JuliaHEP/UnROOT.jl
      Discusión anterior en HN sobre usar Julia en física de partículas: https://news.ycombinator.com/item?id=38512793

  • Es genial ver proyectos de software a gran escala usados para descubrimientos científicos
    Otro ejemplo: en LIGO usaron GStreamer para encontrar ondas gravitacionales: https://lscsoft.docs.ligo.org/gstlal/

    • Aquí en realidad es casi lo contrario. CERN necesitaba un framework para análisis de datos, así que CERN lo desarrolló, lo mantuvo y lo publicó
      Pero no sé si realmente sea buena idea que gente externa lo use. Mi experiencia puede estar algo desactualizada, pero era bastante tosco y anticuado. La gran ventaja en CERN o en trabajo de física de partículas es que es un estándar de facto, así que colaborar internamente es fácil
    • Son dos ejemplos bastante distintos. ROOT es un potente framework de análisis de datos, pero a pesar de toda su potencia, nunca lograron hacerlo lo bastante general y fácil de usar como para salir realmente de la física de altas energías
      En cambio, GStreamer es una plataforma con un diseño hermoso, con una arquitectura tan buena que se puede abstraer y reutilizar fácilmente en escenarios completamente distintos, probablemente fuera de lo que imaginaron quienes la crearon originalmente
    • Lo que no es genial es que ROOT fue “diseñado” y construido por gente que no tenía idea de cómo llevar un proyecto de software grande
      Se nota por todas partes. Es un monolito enorme, así que cada vez que quieres hacer algo apenas fuera de lo normal terminas peleándote con él. Menos mal no tengo que usarlo seguido, aunque todavía me toca lidiar un poco con eso
    • ¿“Encontraron ondas gravitacionales con GStreamer en LIGO”? ¿Qué?

  • Personalmente, creo que ROOT intenta hacer demasiadas cosas, su diseño de API no es bueno y, sobre todo, ROOT como librería y ROOT como programa no están separados
    Tiene muchísimo estado global y parte de la idea de que la gente debe usarlo al estilo del programa ROOT. ROOT 6 empezó a arreglar parte de eso, pero tomará tiempo, y personalmente creo que al apoyarse tan profundamente en llvm y clang aumentaron todavía más los tiempos de compilación y volvieron el proyecto más difícil de arreglar
    Durante mucho tiempo la documentación del formato de entrada/salida fue pobre y solo existía una implementación
    Ahora, gracias a groot, uproot, freehep, openscientist y otros, ya se puede leer y escribir datos ROOT sin arrastrar todo ROOT completo. Creo que la interoperabilidad es crucial en los datos. Es indispensable si quieres mantener la esperanza de poder volver a leer esos datos únicos dentro de 20 o 30 años
    https://go-hep.org/x/hep/groot
    Soy el desarrollador principal de go-hep

    • Hasta donde sé, uproot todavía no implementa bien la lectura de TEfficiency, y la verdad es una lástima

  • Ah, root… cada día agradezco no tener que usar versiones anteriores a la 6

    • Root fue una de las razones por las que decidí no estudiar física de partículas
    • Sigo esperando la versión 7, que supuestamente por fin iba a arreglar root aunque rompiera compatibilidad. Creo que oí hablar de eso por primera vez por 2016, pero de verdad parece una promesa evaporada

  • Me trae recuerdos de desvelarme depurando código escrito por físicos brillantes pero sin formación en ciencias de la computación

    • Hacia 2013 trabajé en un sitio web de préstamos en línea donde contrataron físicos de partículas para construir modelos de predicción de riesgo
      Ellos usaban ROOT para el modelado y Ruby como interfaz, y desde la perspectiva de ingeniería de software era un monstruo. Aun así, desde el punto de vista estadístico estaba bastante bien
      Fue mucho antes de que explotara el ecosistema de Python, y cuando los paquetes de machine learning en R apenas arrancaban
    • Me imagino un main() de 2000 líneas

  • Root sí es el núcleo de una cantidad enorme de trabajo en física experimental de partículas, pero también es una pesadilla para estudiantes de posgrado nuevos
    Está tan profundamente incrustado en la física de partículas que no parece que vaya a cambiar pronto

    • Ahora existen pyroot y uproot, así que los estudiantes nuevos ya tienen opciones más fáciles de aprender, y la cosa no está tan mal
      El problema suele estar en el código legacy que hay que mantener como parte del servicio experimental

  • La parte de Root que yo uso es Cling, el intérprete de C++, y Xeus para notebooks Jupyter
    Una noche comparé el n-body más rápido de benchmarkgames entre Xeus y Python 3. En la misma instancia de Binder, Xeus tardó 15.58 segundos, y el código Python más rápido ejecutado en un kernel de Python3 tardó 5 minutos. La salida fue exactamente la misma en ambos casos
    Aunque a este programa le atribuyeras un overhead de ejecución dinámica en C++ de alrededor de 300%, Cling sigue siendo muy rápido. No usé SIMD ni vectorización, solo el código de benchmarkgames. Uso Cling principalmente como un reemplazo rápido de JIT para lenguajes que se compilan principalmente a C++

    • Estoy usando Cling para la compilación JIT de mi dialecto nativo de Clojure: https://github.com/jank-lang/jank
      Es un intento de llevar C++ al mundo de Clojure, y Clojure y la programación interactiva al mundo de C++

  • Código fuente: https://github.com/root-project

  • “Depurar scripts de CERN ROOT y programas basados en ROOT en Eclipse IDE”
    Dios mío, eso me trae pesadillas. Sin duda demuestra que se pueden construir cosas extraordinarias incluso en entornos horribles

    • No estoy seguro de que eso hable de Eclipse