वैज्ञानिक तरीके से पेटाबाइट डेटा का विश्लेषण करने वाला ROOT

 (root.cern)
1 पॉइंट द्वारा GN⁺ 2024-06-02 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • हाई-एनर्जी फिजिक्स जैसे बड़े शोध में आवश्यक बड़े पैमाने के डेटा प्रोसेसिंग और वैज्ञानिक विश्लेषण को सपोर्ट करता है, और अभी ROOT फ़ाइलों में 2 एक्साबाइट से अधिक डेटा संग्रहीत है
  • Higgs की खोज में भी ROOT का उपयोग हुआ था, इसलिए यह प्रयोगात्मक डेटा विश्लेषण में प्रमाणित वास्तविक उपयोग वाला टूल है
  • ओपन सोर्स होने के कारण इसे स्वतंत्र रूप से इस्तेमाल और संशोधित किया जा सकता है, और ओपन डेवलपमेंट प्रोसेस के माध्यम से यूज़र योगदान स्वीकार किए जाते हैं
  • साथ में दिया गया C++ interpreter तेज़ प्रोटोटाइपिंग के लिए उपयुक्त है, और Python dynamic binding के ज़रिए इसके सभी components तक पहुँचा जा सकता है
  • Jupyter Notebook भी सपोर्ट करता है, जिससे C++ और Python आधारित विश्लेषण को notebook environment तक बढ़ाया जा सकता है, और releases, training व hackathon की खबरें भी लगातार साझा की जाती हैं

ROOT की डेटा विश्लेषण में भूमिका

  • ROOT बड़े पैमाने के डेटा के processing और वैज्ञानिक विश्लेषण को संभव बनाने वाला टूल है

ओपन सोर्स डेवलपमेंट और योगदान

  • ROOT open source के रूप में उपलब्ध है
    • इसे स्वतंत्र रूप से इस्तेमाल किया जा सकता है
    • source से build करके संशोधित किया जा सकता है
    • यह user contributions स्वीकार करने वाली ओपन डेवलपमेंट प्रोसेस अपनाता है

C++·Python·Notebook आधारित उपयोग का तरीका

  • डेवलपमेंट इंटरफ़ेस C++ और Python दोनों को सपोर्ट करता है
    • C++ interpreter उपलब्ध है, जो तेज़ prototyping के लिए उपयुक्त है
    • Python dynamic binding के ज़रिए ROOT के सभी components तक पहुँचा जा सकता है
    • Jupyter Notebook भी सपोर्ट करता है

ब्लॉग और रिलीज़ अपडेट

  • हाल की ब्लॉग प्रविष्टियों में C++ documentary के YouTube रिलीज़ का निमंत्रण, ROOT और C++ documentary trailer, ROOT Advanced Course 2026, और 3rd ROOT Hackathon से संबंधित पोस्ट शामिल हैं
  • नवीनतम release सूची में ये versions शामिल हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-06-02
Hacker News टिप्पणियाँ

  • पुरानी यादें ताज़ा हो गईं। जब मैं particle physics में काम करता था, तब ROOT का बहुत इस्तेमाल किया, और उससे प्यार-नफ़रत वाला रिश्ता था
    एक तरफ उसमें technical debt और अजीब तरह की जड़ता बहुत थी, लेकिन दूसरी तरफ ROOT में कुछ काम ऐसे थे जो matplotlib जैसे ज़्यादा “modern” विकल्पों की तुलना में काफ़ी आसान थे। जैसे histogram, fields वाले objects को “columns” में रखना जैसा बहुत structured data, x/y arrays अलग से allocate किए बिना सीधे functions plot करना, वगैरह
    इसका सहज object-oriented API भी अच्छा था। pandas/matplotlib की method chaining, [] syntax का अति-उपयोग, और तरह-तरह के जादुई behavior की तुलना में यह पुराने C++ या Java के ज़्यादा करीब लगता था; elegant नहीं था और verbose था, लेकिन scientific analysis में यह उल्टा फ़ायदा हो सकता है
    करीब 5 साल पहले जब मैंने इसे छोड़ा, तब ROOT बदल रहा था, पुराना CINT interpreter हटाकर clang-आधारित codebase पर जा चुका था। अब मेरी जानकारी में C++ या Python से Jupyter में analysis चलाया जा सकता है, और सुना है code quality भी काफ़ी सुधरी है

    • ROOT की सबसे अच्छी बात इसका data loading model था। डिस्क से column आधार पर काटकर पढ़ने वाला TTree वाकई शानदार idea था, और graduation के बाद industry में आने के बाद भी मैं उसी तरह काम करने वाली चीज़ ढूँढता रहा हूँ
    • शायद क्योंकि matplotlib histogram-केंद्रित नहीं है, या शायद आजकल RAM बहुत है, इसलिए अक्सर ऐसे scatter plots दिखते हैं जिनमें points इतने ज़्यादा overlap करते हैं कि वे बेकार हो जाते हैं। देखना तक मुश्किल होता है
    • ROOT के साथ सबका प्यार-नफ़रत वाला रिश्ता है। थोड़ा Stockholm syndrome जैसा भी लगता है
    • सोच रहा हूँ कि क्या Haskell भी ऐसी चीज़ बनाने के लिए उपयुक्त होगा
    • आजकल ChatGPT की वजह से matplotlib का भयानक API पहले जितनी बड़ी समस्या नहीं रहा

  • नई analysis में ROOT को default मानने की वजहें अब ज़्यादा नहीं बचीं। uproot जैसे ज़्यादा user-friendly और समझदार विकल्प का इस्तेमाल करना बेहतर है
    हाँ, legacy workflows हों या experiment-specific custom patches ROOT के ऊपर बहुत चढ़े हों, तो बात अलग है, लेकिन सिर्फ physics analysis के लिए यह ख़ुद को परेशान करने जैसा चुनाव हो सकता है
    404 page भी पसंद आया। और नहीं, यह room 404 की बात नहीं है
    https://github.com/scikit-hep/uproot5
    https://root.cern/404/

    • uproot पर आम आलोचना यह है कि जब row-wise computation जटिल हो जाती है तो यह उतना flexible नहीं रहता। वजह यह है कि Python के for loops बहुत धीमे होते हैं
      ऐसे में Numba इस्तेमाल किया जा सकता है, या जब चीज़ें ठीक बैठें तभी सही, नहीं तो बेशर्म self-promotion के तौर पर Julia भी इस्तेमाल कर सकते हैं: https://github.com/JuliaHEP/UnROOT.jl
      particle physics में Julia के इस्तेमाल पर पुरानी HN चर्चा: https://news.ycombinator.com/item?id=38512793

  • बड़े software projects को वैज्ञानिक खोज में इस्तेमाल होते देखना शानदार है
    एक और उदाहरण, LIGO ने GStreamer का इस्तेमाल करके gravitational waves खोजी थीं: https://lscsoft.docs.ligo.org/gstlal/

    • यहाँ मामला लगभग उल्टा है। CERN को data analysis framework चाहिए था, इसलिए CERN ने ही इसे विकसित, maintain और public किया
      हालाँकि यह सच में बाहरी लोगों के इस्तेमाल के लिए अच्छा विचार है या नहीं, पता नहीं। मेरा अनुभव पुराना हो सकता है, लेकिन यह काफ़ी भद्दा और पुराना-सा था। CERN या particle physics के काम में इसका बड़ा फ़ायदा यह है कि यह लगभग standard है, इसलिए अंदरूनी सहयोग आसान हो जाता है
    • ये दोनों काफ़ी अलग उदाहरण हैं। ROOT एक शक्तिशाली data analysis framework है, लेकिन अपनी ताक़त के बावजूद इसे इतना general-purpose और usable नहीं बनाया जा सका कि यह high-energy physics के बाहर जा सके
      इसके उलट GStreamer एक खूबसूरती से डिज़ाइन किया गया platform है, जिसकी architecture इतनी अच्छी है कि इसे बिल्कुल अलग तरह के scenarios में भी आसानी से abstract और reuse किया जा सकता है, जिनकी कल्पना शायद इसके मूल रचयिताओं ने भी नहीं की होगी
    • जो बात शानदार नहीं है, वह यह कि ROOT को ऐसे लोगों ने “design” और बनाया था जिन्हें बड़े software projects चलाने का बिल्कुल अनुभव नहीं था
      इसकी छाप हर जगह दिखती है। यह एक विशाल monolith है, इसलिए अगर आप थोड़ा भी असामान्य काम करना चाहें तो लगातार उससे लड़ना पड़ता है। शुक्र है कि मुझे इसे ज़्यादा इस्तेमाल नहीं करना पड़ता, लेकिन अभी भी कुछ हद तक पाला पड़ता है
    • “LIGO में GStreamer से gravitational waves खोजी गईं”? क्या?!

  • निजी तौर पर मुझे ROOT ऐसा लगता है जो बहुत ज़्यादा चीज़ें करना चाहता है, जिसका API design अच्छा नहीं है, और सबसे बड़ी बात यह कि ROOT as a library और ROOT as a program अलग नहीं किए गए हैं
    इसमें global state बहुत है, और यह मानकर चला जाता है कि लोग इसे ROOT program वाले तरीके से ही इस्तेमाल करेंगे। ROOT 6 ने इनमें से कुछ चीज़ें सुधारनी शुरू कीं, लेकिन इसमें समय लगेगा, और मुझे व्यक्तिगत रूप से लगता है कि llvm और clang पर इसकी बहुत गहरी निर्भरता ने build times और बढ़ा दिए हैं और project के रूप में इसे ठीक करना और कठिन बना दिया है
    लंबे समय तक इसके input/output format की documentation भी कमज़ोर थी और implementation भी सिर्फ एक ही थी
    अब groot, uproot, freehep, openscientist वगैरह की वजह से पूरे ROOT को साथ लाए बिना भी ROOT data पढ़ा-लिखा जा सकता है। data में interoperability बहुत महत्वपूर्ण है। 20 या 30 साल बाद भी उस एकमात्र data को फिर से पढ़ पाने की उम्मीद रखने के लिए यह ज़रूरी है
    https://go-hep.org/x/hep/groot
    मैं go-hep का मुख्य developer हूँ

    • मेरी जानकारी में uproot अभी भी TEfficiency पढ़ने का ठीक implementation नहीं कर पाया है, जो ईमानदारी से कहूँ तो अफ़सोस की बात है

  • आह, root… हर दिन version 6 से पहले के versions इस्तेमाल न करने के लिए मैं आभारी हूँ

    • Root उन कारणों में से एक था जिनकी वजह से मैंने particle physics न पढ़ने का फ़ैसला किया
    • मैं अभी भी उस version 7 का इंतज़ार कर रहा हूँ जो interface तोड़कर भी root को आखिरकार अच्छा बनाने वाला था। लगता है पहली बार इसके बारे में 2016 के आसपास सुना था, और अब यह सचमुच गायब हो चुका वादा लगता है

  • मुझे वे रातें याद आ गईं जब computer science background न रखने वाले लेकिन बेहद प्रतिभाशाली physicists के लिखे code को देर रात debug करना पड़ता था

    • 2013 के आसपास मैं एक online lending website में काम करता था, जहाँ risk prediction model बनाने के लिए particle physicists को hire किया गया था
      वे modeling के लिए ROOT इस्तेमाल करते थे और Ruby से interface बनाते थे, जो software engineering के नज़रिए से एक राक्षस था। फिर भी statistics के लिहाज़ से वह काफ़ी ठीक था
      यह Python ecosystem के उभरने से बहुत पहले की बात है, और R के machine learning packages भी तब बस शुरू ही हो रहे थे
    • 2000-line का main() आँखों के सामने आ गया

  • Root experimental particle physics में भारी मात्रा के काम का केंद्रीय आधार ज़रूर है, लेकिन नए graduate students के लिए यह एक बुरा सपना भी है
    यह particle physics में इतनी गहराई से जड़ा हुआ है कि लगता नहीं निकट भविष्य में कुछ बदलेगा

    • अब pyroot और uproot होने से नए graduate students के पास सीखने में आसान विकल्प हैं, इसलिए हालात इतने बुरे भी नहीं हैं
      असली समस्या आम तौर पर उस legacy code में होती है जिसे experiment service के हिस्से के रूप में maintain करना पड़ता है

  • Root का जो हिस्सा मैं इस्तेमाल करता हूँ, वह C++ interpreter Cling और Jupyter notebooks का Xeus है
    एक रात मैंने benchmarkgames के सबसे तेज़ n-body को Xeus और Python 3 से तुलना की। उसी Binder instance पर Xeus ने 15.58 सेकंड लिए, जबकि Python3 kernel में सबसे तेज़ Python code चलाने पर 5 मिनट लगे। दोनों runs का output बिल्कुल एक जैसा था
    अगर इस program में dynamic C++ execution overhead को लगभग 300% भी मान लें, तब भी Cling बहुत तेज़ है। मैंने SIMD या vectorization का इस्तेमाल नहीं किया था, सिर्फ benchmarkgames का code चलाया था। Cling को मैं मुख्य रूप से उन भाषाओं के लिए तेज़ JIT replacement की तरह इस्तेमाल करता हूँ जो C++ में compile होती हैं

    • मैं अपनी native Clojure dialect के JIT compilation में Cling इस्तेमाल कर रहा हूँ: https://github.com/jank-lang/jank
      यह C++ को Clojure की दुनिया में लाने, और Clojure तथा interactive programming को C++ की दुनिया में लाने की कोशिश है

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

  • “Eclipse IDE में CERN ROOT scripts और ROOT-आधारित programs की debugging”
    हे भगवान, इससे तो बुरे सपने याद आ गए। यह साफ़ दिखाता है कि भयानक environment में भी असाधारण चीज़ें बनाई जा सकती हैं

    • पता नहीं यह Eclipse की बात है या नहीं