Petabayt veriyi bilimsel olarak analiz etmek için ROOT

 (root.cern)
1 puan yazan GN⁺ 2024-06-02 | 1 yorum | WhatsApp'ta paylaş
  • Yüksek enerji fiziği gibi büyük ölçekli araştırmalarda gerekli olan büyük veri işleme ve bilimsel analizi destekler; şu anda ROOT dosyalarında 2 eksabayttan fazla veri depolanmaktadır
  • Higgs’in keşfinde de ROOT kullanıldı; bu da aracın deneysel veri analizinde doğrulanmış gerçek bir kullanım örneğine sahip olduğunu gösterir
  • Açık kaynak olarak özgürce kullanılabilir ve değiştirilebilir; ayrıca açık geliştirme süreci üzerinden kullanıcı katkıları kabul edilir
  • Birlikte sunulan C++ yorumlayıcısı hızlı prototipleme için uygundur ve Python dinamik bağları sayesinde tüm bileşenlere erişilebilir
  • Jupyter Notebook desteğiyle C++ ve Python tabanlı analizler notebook ortamına taşınabilir; ayrıca sürümler ile eğitim ve hackathon duyuruları da düzenli olarak paylaşılmaktadır

ROOT'un veri analizindeki rolü

  • ROOT, büyük miktarda verinin işlenmesini ve bilimsel analizini mümkün kılan bir araçtır

Açık kaynak geliştirme ve katkı

C++, Python ve notebook tabanlı kullanım

Blog ve sürüm haberleri

  • Son blog yazıları arasında C++ belgeselinin YouTube gösterimine davet, ROOT ve C++ belgesel fragmanı, ROOT Advanced Course 2026 ve 3. ROOT Hackathon ile ilgili yazılar yer alıyor
  • En güncel sürüm listesinde şu sürümler bulunuyor

İlgili okumalar

1 yorum

 
GN⁺ 2024-06-02
Hacker News yorumları

  • Eski günleri hatırlattı. Parçacık fiziği tarafında çalışırken ROOT'u çok kullanırdım; onunla sevgi-nefret ilişkim vardı.
    Bir yandan çok fazla teknik borcu ve tuhaf ataleti vardı; öte yandan ROOT'ta, matplotlib gibi daha “modern” seçeneklere göre kolay olan epey iş vardı. Örneğin histogramlar, alanları olan nesneleri “sütunlara” koyan son derece yapılandırılmış veriler, x/y dizilerini ayrı ayrı ayırmadan fonksiyonları doğrudan çizmek gibi.
    Sezgisel nesne yönelimli API de hoşuma gidiyordu. pandas/matplotlib'teki metot zincirleme, [] sözdiziminin aşırı kullanımı ve türlü sihirli davranışlar yerine eski usul C++ ya da Java'ya daha yakındı; zarif değil, lafı uzatan bir tarzdı ama bilimsel analizde bu aslında avantaj olabilir.
    Yaklaşık 5 yıl önce ayrıldığımda ROOT değişim içindeydi; eski CINT yorumlayıcısını kaldırıp clang tabanlı bir kod tabanına geçmişti. Bildiğim kadarıyla artık C++ ya da Python ile Jupyter'da analiz çalıştırılabiliyor ve kod kalitesinin de epey iyileştiğini duydum.

    • ROOT'un en iyi yanı veri yükleme biçimiydi. Diskten sütun bazlı dilimleyerek okuyan TTree gerçekten iyi bir fikirdi; mezuniyetten sonra sektöre geçtikten sonra da aynı şekilde çalışan şeyler aramayı sürdürdüm.
    • matplotlib histogram odaklı olmadığı için mi, yoksa günümüzde RAM bol olduğu için mi bilmiyorum; üst üste binen çok fazla nokta yüzünden işe yaramayan saçılım grafiklerini sık sık görüyorum. Bakması zor.
    • Herkesin ROOT ile sevgi-nefret ilişkisi var. Biraz Stockholm sendromu gibi.
    • Haskell'in de böyle bir şey geliştirmeye uygun olup olmayacağını merak ediyorum.
    • Bugünlerde ChatGPT sayesinde matplotlib'in berbat API'si eskisi kadar büyük bir sorun değil.

  • Yeni bir analizin varsayılan olarak ROOT kullanması için pek sebep yok. Daha kullanıcı dostu ve aklı başında bir seçenek olan uproot gibi bir şey kullanmak daha iyi.
    Legacy iş akışları olabilir ya da deney bazında ROOT'un üzerine çok sayıda özel yama bindirilmiş olabilir; ama sırf fizik analizi açısından bakarsak bu, insanın kendine eziyet etmesi olabilir.
    404 sayfasını da beğendim. Üstelik room 404 hikâyesi değil.
    https://github.com/scikit-hep/uproot5
    https://root.cern/404/

    • uproot'a yönelik yaygın bir eleştiri, satır bazlı hesaplamalar karmaşıklaştığında esnek olmaması. Bunun nedeni Python'daki for döngülerinin çok yavaş olması.
      Böyle durumlarda Numba kullanabilirsiniz ya da, yalnızca iyi çalıştığı durumlarda mümkün olmakla birlikte, utanmaz bir tanıtım yapacak olursam Julia kullanabilirsiniz: https://github.com/JuliaHEP/UnROOT.jl
      Parçacık fiziğinde Julia kullanımıyla ilgili eski HN tartışması: https://news.ycombinator.com/item?id=38512793

  • Bilimsel keşiflerde kullanılan büyük ölçekli yazılım projelerini görmek harika.
    Başka bir örnek olarak, LIGO'da kütleçekim dalgaları GStreamer ile bulundu: https://lscsoft.docs.ligo.org/gstlal/

    • Burada durum daha çok bunun tersi gibi. CERN'in bir veri analizi çatısına ihtiyacı vardı; CERN de bunu geliştirdi, sürdürdü ve açık hale getirdi.
      Ancak dışarıdan birinin gerçekten kullanmasının iyi fikir olup olmadığından emin değilim. Deneyimim biraz eski kalmış olabilir ama oldukça kaba ve yaşlı hissettiriyordu. CERN ya da parçacık fiziği çalışmalarındaki büyük avantajı, fiilen standart olması ve içeride iş birliğini kolaylaştırması.
    • Bunlar oldukça farklı iki örnek. ROOT güçlü bir veri analizi çatısı; ama bu gücüne rağmen yeterince genel amaçlı ve kullanımı kolay hale getirilemediği için yüksek enerji fiziğinin dışına pek çıkamadı.
      Buna karşılık GStreamer tasarımı güzel bir platform; mimarisi iyi olduğu için, onu ilk yapanların hayal bile etmemiş olabileceği tamamen farklı senaryolara kolayca soyutlanıp yeniden kullanılabiliyor.
    • Harika olmayan tarafı, ROOT'un büyük ölçekli bir yazılım projesinin nasıl yürütüleceğini hiç bilmeyen insanlar tarafından “tasarlanıp” yapılmış olması.
      Bunun izleri her yerde görülüyor. Devasa bir monolit olduğu için biraz sıra dışı bir şey yapmaya kalksanız sürekli onunla boğuşmanız gerekiyor. Sık kullanmak zorunda olmadığım için şanslıyım ama hâlâ bir ölçüde temasım var.
    • “Kütleçekim dalgaları LIGO'da GStreamer ile bulundu” mu? Ne dedin?!

  • Kişisel olarak ROOT'un çok fazla şey yapmaya çalıştığını, API tasarımının iyi olmadığını ve her şeyden önemlisi kütüphane olarak ROOT ile program olarak ROOT arasında ayrım olmadığını düşünüyorum.
    Çok fazla global durum var ve insanların ROOT'u program gibi kullanması gerektiği varsayımı yerleşmiş. ROOT 6 bunun bir kısmını düzeltmeye başladı ama zaman alıyor; kişisel olarak llvm ve clang'e fazla derinden yaslandıkça derleme sürelerinin daha da uzadığını ve projenin düzeltilmesinin zorlaştığını düşünüyorum.
    Uzun süre giriş/çıkış biçimi belgeleri de zayıftı ve tek bir uygulaması vardı.
    Artık groot, uproot, freehep, openscientist vb. sayesinde ROOT'un tamamını çekmeden de ROOT verilerini okuyup yazabiliyorsunuz. Veride birlikte çalışabilirlik bence çok önemli. 20, 30 yıl sonra bile o benzersiz veriyi yeniden okuyabileceğinize dair umut taşımak için şart.
    https://go-hep.org/x/hep/groot
    go-hep'in baş geliştiricisiyim.

    • Bildiğim kadarıyla uproot hâlâ TEfficiency okumayı düzgün biçimde uygulamış değil; açıkçası üzücü.

  • Ah, root… Her gün 6 öncesi sürümleri kullanmak zorunda olmadığım için şükrediyorum.

    • Root, parçacık fiziği okumamaya karar vermemin nedenlerinden biriydi.
    • Arayüzü kırsa bile sonunda root'u iyi hale getireceği söylenen sürüm 7'yi hâlâ bekliyorum. Sanırım ilk kez 2016 civarında duymuştum; gerçekten buhar olup uçmuş bir vaat gibi.

  • Bilgisayar bilimi geçmişi olmayan ama çok iyi fizikçilerin yazdığı kodları gece geç saatlerde debug ettiğim günleri hatırlıyorum.

    • 2013 civarında bir çevrimiçi kredi sitesinde çalışıyordum; risk tahmin modeli geliştirmek için parçacık fizikçileri işe almışlardı.
      Modelleme için ROOT kullanıyor, arayüzü Ruby ile yapıyorlardı; yazılım mühendisliği açısından bakınca bu bir canavar gibiydi. Yine de istatistik açısından oldukça iyiydi.
      Python ekosisteminin yükselmesinden çok önceydi; R'ın makine öğrenmesi paketleri de yeni yeni ortaya çıkıyordu.
    • 2000 satırlık bir main() gözümün önüne geliyor.

  • Root deneysel parçacık fiziğinde muazzam miktarda işin omurgası olduğu doğru, ama yeni bir doktora öğrencisi için de kâbus.
    Parçacık fiziğine fiilen derinlemesine gömülü olduğu için yakın zamanda değişecek gibi görünmüyor.

    • Artık pyroot ve uproot var; yeni doktora öğrencileri için öğrenmesi daha kolay seçenekler ortaya çıktı ve o kadar da kötü değil.
      Sorun genellikle deney hizmetlerinin parçası olarak bakımı yapılması gereken legacy kodda.

  • Root'un kullandığım kısmı C++ yorumlayıcısı Cling ve Jupyter notebook'larının Xeus'u.
    Bir gece benchmarkgames'in en hızlı n-body programını Xeus ve Python 3 ile karşılaştırdım. Aynı Binder örneğinde Xeus 15,58 saniye sürdü; Python3 çekirdeğinde en hızlı Python kodunu çalıştırınca 5 dakika sürdü. İki çalıştırmada da çıktı tamamen aynıydı.
    Bu programda dinamik C++ çalıştırma ek yükünü yaklaşık %300 saysak bile Cling çok hızlı. SIMD ya da vektörleştirme kullanmadım; yalnızca benchmarkgames kodunu kullandım. Cling'i çoğunlukla C++'a derlenen diller için hızlı bir JIT alternatifi olarak kullanıyorum.

    • Kendi native Clojure lehçemin JIT derlemesinde Cling kullanıyorum: https://github.com/jank-lang/jank
      C++'ı Clojure dünyasına, Clojure'u ve etkileşimli programlamayı da C++ dünyasına getirme girişimi.

  • Kaynak kod: https://github.com/root-project

  • “CERN ROOT betiklerini ve ROOT tabanlı programları Eclipse IDE'de debug etmek” ha.
    Tanrım, kâbuslar geri geldi. Korkunç ortamlarda bile olağanüstü şeyler yapılabileceğini kesinlikle gösteriyor.

    • Bunun Eclipse'le ilgili olduğundan pek emin değilim.