ROOT para analisar dados em petabytes de forma científica

 (root.cern)
1 pontos por GN⁺ 2024-06-02 | 1 comentários | Compartilhar no WhatsApp
  • Dá suporte ao processamento de grandes volumes de dados e à análise científica necessários em pesquisas de grande escala, como física de altas energias; atualmente, mais de 2 exabytes de dados estão armazenados em arquivos ROOT
  • O ROOT também foi usado na descoberta do Higgs, sendo uma ferramenta com caso real de uso validado na análise de dados experimentais
  • Como software de código aberto, pode ser usado e modificado livremente, e recebe contribuições de usuários por meio de um processo de desenvolvimento aberto
  • O interpretador C++ incluído é adequado para prototipagem rápida, e os bindings dinâmicos para Python permitem acessar todos os componentes
  • Também oferece suporte a Jupyter Notebook, ampliando a análise com C++ e Python para o ambiente de notebooks, e continua divulgando novidades sobre releases, treinamentos e hackathons

O papel do ROOT na análise de dados

  • O ROOT é uma ferramenta que viabiliza o processamento de grandes volumes de dados e a análise científica

Desenvolvimento open source e contribuições

Formas de uso com C++, Python e notebooks

Blog e novidades de releases

  • Entre os posts recentes do blog estão um convite para a estreia no YouTube do documentário sobre C++, o trailer do documentário sobre ROOT e C++, o ROOT Advanced Course 2026 e textos relacionados ao 3rd ROOT Hackathon
  • A lista mais recente de releases inclui as seguintes versões

Leituras relacionadas

1 comentários

 
GN⁺ 2024-06-02
Opiniões no Hacker News

  • Me fez lembrar de antigamente. Quando eu trabalhava com física de partículas, usei muito o ROOT, e tinha uma relação de amor e ódio com ele.
    Por um lado, havia muita dívida técnica e algumas inércias peculiares; por outro, havia várias coisas que eram mais fáceis no ROOT do que em opções mais “modernas” como matplotlib. Por exemplo, histogramas, dados altamente estruturados colocando objetos com campos em “colunas”, desenhar funções diretamente sem alocar arrays x/y separados etc.
    Eu também gostava da API orientada a objetos intuitiva. Ela parecia mais próxima de C++ ou Java à moda antiga do que do encadeamento de métodos do pandas/matplotlib, do abuso da sintaxe [] e de vários comportamentos mágicos; não era elegante e era verbosa, mas isso podia ser uma vantagem em análise científica.
    Quando saí, uns 5 anos atrás, o ROOT estava em transformação e já tinha removido o antigo interpretador CINT e migrado para uma base de código baseada em clang. Pelo que sei, hoje dá para rodar análises em Jupyter com C++ ou Python, e ouvi dizer que a qualidade do código melhorou bastante.

    • A melhor coisa do ROOT era a forma de carregar dados. O TTree, que lê recortes em formato colunar a partir do disco, era uma ideia realmente boa, e, depois de me formar e ir para a indústria, continuei procurando algo que funcionasse da mesma forma.
    • Talvez por matplotlib não ser centrado em histogramas, ou porque hoje há RAM suficiente, vejo com frequência gráficos de dispersão inúteis, com pontos demais sobrepostos. É doloroso de ver.
    • Todo mundo tem uma relação de amor e ódio com o ROOT. Parece até um pouco síndrome de Estocolmo.
    • Fico curioso se Haskell também seria adequado para criar algo assim.
    • Hoje em dia, graças ao ChatGPT, a API horrível do matplotlib não é um problema tão grande quanto antes.

  • Não há muitos motivos para uma análise nova usar ROOT como padrão. É melhor usar algo mais amigável e sensato, como uproot.
    Pode haver workflows legados ou casos em que cada experimento colocou muitos patches customizados em cima do ROOT, mas, olhando só para análise de física, pode ser uma escolha de se autoflagelar.
    Também gostei da página 404. E não é sobre a sala 404.
    https://github.com/scikit-hep/uproot5
    https://root.cern/404/

    • Uma crítica comum ao uproot é que ele não é flexível quando cálculos linha a linha ficam complexos. Isso porque loops for em Python são lentos demais.
      Nesses casos dá para usar Numba, ou, quando funciona bem — ou, fazendo uma propaganda descarada — usar Julia: https://github.com/JuliaHEP/UnROOT.jl
      Discussão antiga no HN sobre usar Julia em física de partículas: https://news.ycombinator.com/item?id=38512793

  • É legal ver grandes projetos de software usados em descobertas científicas.
    Outro exemplo: no LIGO, usaram GStreamer para encontrar ondas gravitacionais: https://lscsoft.docs.ligo.org/gstlal/

    • Aqui é quase o contrário. O CERN precisava de um framework de análise de dados, então o CERN o desenvolveu, manteve e publicou.
      Mas não sei se é uma boa ideia pessoas de fora realmente usarem. Minha experiência pode estar um pouco desatualizada, mas ele era bem tosco e antiquado. A grande vantagem no CERN ou em trabalhos de física de partículas é que ele é praticamente um padrão, o que facilita a colaboração interna.
    • Esses dois são exemplos bem diferentes. O ROOT é um framework poderoso de análise de dados, mas, apesar dessa potência, não conseguiram torná-lo genérico e fácil de usar o suficiente, então ele quase não saiu da física de altas energias.
      Já o GStreamer é uma plataforma com um design bonito e, por ter uma boa arquitetura, pode ser facilmente abstraído e reutilizado em cenários totalmente diferentes que talvez nem tenham sido imaginados por seus criadores.
    • O que não é legal é que o ROOT foi “projetado” e criado por pessoas que não tinham a menor ideia de como tocar um grande projeto de software.
      As marcas disso aparecem por toda parte. É um monólito enorme, então, se você tenta fazer qualquer coisa um pouco fora do normal, precisa brigar com ele o tempo todo. Ainda bem que não preciso usá-lo com frequência, mas ainda tenho algum contato com ele.
    • “Encontraram ondas gravitacionais no LIGO com GStreamer”? Como assim?!

  • Pessoalmente, acho que o ROOT tenta fazer coisas demais, tem um design de API ruim e, acima de tudo, não separa o ROOT como biblioteca do ROOT como programa.
    Há muito estado global, e existe a premissa de que as pessoas devem usá-lo do jeito do programa ROOT. O ROOT 6 começou a corrigir parte disso, mas leva tempo; pessoalmente, acho que, ao se apoiar tão profundamente em llvm e clang, o tempo de build aumentou ainda mais e ficou mais difícil consertá-lo como projeto.
    Por muito tempo, a documentação do formato de entrada/saída também foi pobre, e havia apenas uma implementação.
    Hoje, graças a groot, uproot, freehep, openscientist etc., é possível ler e escrever dados ROOT sem trazer o ROOT inteiro junto. Para mim, interoperabilidade em dados é muito importante. É essencial se quisermos ter alguma esperança de reler esses dados únicos daqui a 20 ou 30 anos.
    https://go-hep.org/x/hep/groot
    Sou o principal desenvolvedor do go-hep.

    • Pelo que sei, o uproot ainda não implementou direito a leitura de TEfficiency, o que, sinceramente, é uma pena.

  • Ah, root… faz você agradecer por não precisar usar versões anteriores à 6 todos os dias.

    • Root foi um dos motivos pelos quais decidi não estudar física de partículas.
    • Ainda estou esperando a versão 7, que finalmente tornaria o root bom, mesmo quebrando a interface. Acho que ouvi falar disso pela primeira vez por volta de 2016; parece uma promessa que evaporou de verdade.

  • Lembro de ficar depurando tarde da noite código escrito por físicos brilhantes, mas sem formação em ciência da computação.

    • Por volta de 2013, trabalhei em um site de empréstimos online, e eles contrataram físicos de partículas para construir modelos de previsão de risco.
      Eles usavam ROOT para modelagem e Ruby para criar a interface, e, do ponto de vista de engenharia de software, era um monstro. Ainda assim, do ponto de vista estatístico, era bem bom.
      Isso foi muito antes de o ecossistema Python decolar, e os pacotes de machine learning em R ainda estavam só começando.
    • Imagino um main() de 2.000 linhas.

  • É verdade que o Root é a espinha dorsal de um volume enorme de trabalho em física experimental de partículas, mas também é um pesadelo para novos alunos de pós-graduação.
    Ele está tão profundamente entranhado na física de partículas que não parece que vá mudar em breve.

    • Hoje há pyroot e uproot, então novos alunos de pós-graduação têm opções mais fáceis de aprender, e não é tão ruim assim.
      O problema geralmente está no código legado que precisa ser mantido como parte dos serviços do experimento.

  • A parte do Root que eu uso é o Cling, o interpretador de C++, e o Xeus nos notebooks Jupyter.
    Certa noite, comparei o n-body mais rápido do benchmarkgames no Xeus com Python 3. Na mesma instância do Binder, o Xeus levou 15,58 segundos, e o código Python mais rápido rodando no kernel Python3 levou 5 minutos. A saída foi exatamente a mesma nas duas execuções.
    Mesmo estimando em cerca de 300% o overhead de execução dinâmica de C++ nesse programa, o Cling é muito rápido. Não usei SIMD nem vetorização, apenas o código do benchmarkgames. Uso o Cling principalmente como uma alternativa rápida a JIT para linguagens que compilam para C++.

    • Estou usando o Cling para compilação JIT do meu dialeto nativo de Clojure: https://github.com/jank-lang/jank
      É uma tentativa de trazer C++ para o mundo Clojure e de trazer Clojure e programação interativa para o mundo C++.

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

  • “Depurando scripts CERN ROOT e programas baseados em ROOT no Eclipse IDE”
    Meu Deus, isso me trouxe pesadelos. Mostra claramente que é possível criar algo extraordinário mesmo em um ambiente terrível.

    • Não tenho certeza se isso é sobre o Eclipse.