1 / 77

Design, Development and Evolution of the ROOT system

Design, Development and Evolution of the ROOT system. Rene Brun February 21 2010 ACAT2010 Jaipur. plan. ROOT in 2010 packages users How did we reach this situation? after-PAW fights Objectivity era and big confusion about object persistency

orenda
Télécharger la présentation

Design, Development and Evolution of the ROOT system

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Design, Developmentand Evolutionof the ROOT system Rene Brun February 21 2010 ACAT2010 Jaipur ROOT: design,development, evolution

  2. plan • ROOT in 2010 • packages • users • How did we reach this situation? • after-PAW fights • Objectivity era and big confusion about object persistency • LCG project and problems with the committee approach • the ramping and consolidation years • Directions ROOT: design,development, evolution

  3. Software hierarchy End user Analysis software 0.1 MLOC Experiment Software 2 MLOC Frameworks like ROOT, Geant4 2 MLOC OS & compilers 20 MLOC Hardware Networking Hardware Hardware Hardware Hardware ROOT: design,development, evolution

  4. ROOT today a quick review ROOT: design,development, evolution

  5. 15 years of ROOT after PAW GEANT3 Objectivity era LCG projects start PI, SEAL, POOL ROOT mainstream PAW-like ROOT 1995 2000 2005 2010 ROOT: design,development, evolution

  6. Modular structure? • Nice and modular building. • But can we use only what we need? ROOT: design,development, evolution

  7. Project Structure xrootd PROOF NET I/O Trees CORE TGEO HIST g3root CINT VMC Tfluka reflex pyroot g4root GRAF3D MATH GRAF2D TMVA GUI EVE Roofit RooStats ROOT: design,development, evolution

  8. framework • Like in the Albert Hall Museum, we created base classes (the CORE), doors and windows (IO) and utility libraries on top. • Can be seen as a mess or a very functional building. ROOT: design,development, evolution

  9. Interpreters • In this talk, I have no time to discuss issues about interpreters like CINT and Pyroot, or the internals of the reflexion system (see my slide about LLVM later). • CINT and its reflexion system is the cornerstone of ROOT for the IO system and scripts. • CINT was not designed to be a full C++ interpreter. We came several years ago with ACLIC that automatizes the interface with the compiler. • We strongly recommend the use of ACLIC for medium/large size scripts. LLVM will simplify even more the problem once the system will be operational. ROOT: design,development, evolution

  10. Interpreter & Compiler integration execute file script.C root > .x script.C root > DoSomething(…); root > .x script.C++ root > .x script.C+ execute function DoSomething compile file script.C and execute it compile file script.C if file has been modified. execute it same from compiled or interpreted code gROOT->ProcessLine(“.L script.C+”); gROOT->ProcessLine(“DoSomething(…)”); ROOT: design,development, evolution

  11. ROOT Math/Stat Libraries The new CERNLIB/MATHLIB High Level Analysis Libraries RooStats TMVA RooFit Fitting and Minimization Statistical Libraries With better algorithms Quadp Minuit2 Limit classes MLP Linear Fitter TMinuit TFumili Extra Libraries Linear Algebra Physics Vectors Unuran FFTW SMatrix GenVector Spectrum Foam TMatrix TVector3/TLV MathMore MathCore Y Random Numbers Math Interfaces Fitting Classes Extra algorithms Basic algorithms TComplex Extra Math functions Math functions TRandom GSL ROOT: design,development, evolution

  12. ROOT 2-D graphics • based on 10 years experience with PAW and 15 years of operation with ROOT itself. • zillions of tiny new features always requested by users • works in batch (canvas.root, canvas.pdf, canvas.gif,..) • object editors • C++ script generated from canvas (TObject::SavePrimitive) ROOT: design,development, evolution

  13. New functions added at each new release. Always requests for new styles and new ways to display data. ps,pdf,svg,gif, jpg,png,c,root, etc 2-D Graphics Move to GL ? ROOT: design,development, evolution

  14. ROOT: design,development, evolution

  15. Image processing ROOT: design,development, evolution

  16. Portable GUI with all widgets found in modern UI toolkits. Many enhancements in the GUI classes: browser, html browser, TABs, EVE widgets, FitPanel. GUI builder with C++ code generator. Session recorder tool (class TRecorder) can store and replay a GUI session: All mouse events Keyboard input, including macro execution QT interfaces: a big pain, difficult to maintain with the successive versions of Qt. GUI ROOT: design,development, evolution

  17. GUI ROOT: design,development, evolution

  18. GUI • One of the most demanding areas • Must follow technology and not standard systems (gks -> phigs ->Motif ->Qt ->?) • GUI based on OpenGL too ! • Plug-ins must work on the web (but 2-d and 3-d graphics too!) • GUI builder extensions (code generators) • GUI must be scriptable and theme-able • HELP + language internalisation • Context menus help access to documentation ROOT: design,development, evolution

  19. ROOT 3-D graphics • OpenGL based: graphics accelerators • detector geometry visualization • event displays (EVE) • interaction between GL view and original objects (picking/editing) ROOT: design,development, evolution

  20. Highly optimized GL views in • TPad • the GL viewer 3-D Graphics Detector hits Mathematical objects ROOT: design,development, evolution

  21. Graphics (2D-3D) TH3 TGLParametric “LEGO” “SURF” TF3 ROOT: design,development, evolution

  22. The TGeo classes are now stable (thanks ALICE). Can work with different simulation engines (G3,G4,Fluka) (See Virtual Monte Carlo) G3->TGeo, G4->TGeo, TGeo>GDML Used in online systems and reconstruction programs Built-in facilities for alignment Impressive gallery of experiments (35 detectors in $ROOTSYS/test/stressGeometry) The Geometry Package TGEO ROOT: design,development, evolution

  23. OpenGL see $ROOTSYS/tutorials/geom ROOT: design,development, evolution

  24. a GL-based package for event displays. Developed in collaboration with ALICE (AliEve) and CMS (FireWorks). Provides all the GUI widgets, browsers, GL infrastructure (far better than the old OpenInventor). Used now by many experiments (see eg FAIRROOT, ILCROOT) to display raw data, MC events or detector oriented visualization. Event Display: EVE ROOT: design,development, evolution

  25. PROOF • Massive data analysis with parallel systems. Now in production in many places . Growing success. • A lot of developments for a better integration with dataset management systems and to support priority and accounting management. • PROOF-LITE is a mini version to run on a multi-core. with PROOF-LITE ROOT: one core only with PROOF ROOT: design,development, evolution

  26. IO and Trees • They are the most important components of the system because they have a deep impact on the experiment frameworks and their data handling strategy. • Shaping these 2 systems has been a long process. ROOT: design,development, evolution

  27. Memory <--> TreeEach Node is a branch in the Tree Memory T.GetEntry(6) 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 T.Fill() 18 T ROOT: design,development, evolution tr

  28. Automatic branch creation from object model branch buffers float a; int b; double c[5]; int N; float* x; //[N] float* y; //[N] Class1 c1; Class2 c2; //! Class3 *c3; std::vector<T>; std::vector<T*>; TClonesArray *tc; ROOT: design,development, evolution

  29. branches created from a dynamic list Each named member of a TList Is a top level branch a a a a a a b c d e ROOT: design,development, evolution

  30. Top level branches created by user Top level branches Are created manually a b c d e ROOT: design,development, evolution

  31. Branches created from STL collections Use split=199 to reduce The number of branches In case of polymorphic collections split = 0 std::vector<T> split >0 std::vector<T> split <100 std::vector<T*> split =199 std::vector<T*> split >0 TClonesArray ROOT: design,development, evolution

  32. Trends in Tree structure Maximum split level, ie more branches is better eg, Atlas 9785, CMS 1436, LHCb 1167, Alice >1000 Many branches is good for the future because branch reading can be executed in parallel. many branches is better because the access granularity is better for fast selections. ROOT: design,development, evolution

  33. ObjectWise/MemberWise Streaming 3 modes to stream an object a b c d a1b1c1d1a2b2c2d2…anbncndn object-wise to a buffer a1a2..anb1b2..bnc1c2..cnd1d2..dn member-wise to a buffer a1a2…an each member to a buffer member-wise gives better compression b1b2…bn c1c2…cn d1d2…dn ROOT: design,development, evolution

  34. Linux (RH, SLC4, SLC5, Suse, Debian, Ubuntu) gcc3.4,…, gcc4.4 (32 and 64 bits) icc10.1, icc11.1 MacOS X (Intel/PPC, 10.4, 10.5, 10.6) gcc4.0.1, gcc4.2.1,gcc4.4.1, llvm-g++ icc10.1, icc11.1 Windows (XP, Vista) VC++7.1, VC++9 Cygwin gcc3.4, 4.3 Solaris + OpenSolaris CC5.2 gcc3.4, gcc4.4 SupportedPlatforms Support for many compilers adds robustness at a minor development cost. It facilitates the migration to new compiler versions. ROOT: design,development, evolution

  35. Distribution Stats More than 20000 users 35000 FTP-only distributions of binaries per month. Many more from SVN source or AFS access ROOT: design,development, evolution

  36. How did we reach the current situation Rien ne sert de courir, il faut partir a point Jean de la Fontaine ROOT: design,development, evolution

  37. one cannot forget the past • Systems like ROOT and G4 have been strongly influenced par their predecessors, by politics, by sociology. • Like Jumbo jets, large systems that required a lot of manpower evolve with time with the pros and cons of their inertia. • Once a system is massively used, people expect backward and forward compatibility. • However ROOT in 2010 is very much different of ROOT in 1995 or 2000 or 2005 ROOT: design,development, evolution

  38. Software in HEP most systems used over 2,3 or 4 decades ROOT---=================== JAS--===----…. . . geant4----=================== piaf==== paw---====================-----------------… . . . . zebra---=================------------------------…… . . geant3 ======================------------------……… . . . geant1,2 ==-- hbook===============================------------------------………….. . cernlib ===============-------------------------……………….. . . . . . 1970 1980 1990 2010 ROOT: design,development, evolution

  39. Main parameters who shaped ROOT • Long experience with GEANT and PAW • Reuse of components • Concept of packages within a framework • Optimal for batch, optimal for interactivity • User support quasi online ROOT: design,development, evolution

  40. CERNLIB • 1970: main.f links with cernlib.a where cernlib is a collection of independent subroutines. • 1975: subroutines are grouped into packages identified by the letters of the alphabet, eg Y250 • 1980: cernlib accepts large packages, eg hbook, minuit,gd3 • 1985: cernlib is a collection of large packages, mathlib, kernlib,packlib,graflib,pawlib,geant3 ROOT: design,development, evolution

  41. hbook : 1973  20xy • first large package in cernlib • histogram-oriented system including visualization (from line-printer to graphics) and persistency. • interface with Minuit and Fumili • interface with zbook in 1975, then zebra in 1983 • extended in 1985 to support row-wise ntuples and column-wise ntuples in 1990. • the heart of PAW ROOT: design,development, evolution

  42. geant3 : 1980-20xy • successor of geant1 (1975), geant2(1978) • includes a powerful geometry package used to model all existing HEP detectors. • interfaces with external hadronic shower packages like tatina,gheisha,fluka. • includes visualisation: detector cross-sections, event displays. • includes IO for geometry and events (zebra) ROOT: design,development, evolution

  43. PAW : 198420xy • started by a committee (design for the past) • quickly reshaped in 1985 with KUIP, HIGZ, ntuples • query processor: ntuple/plot 10.px • analysis patterns indicates row-wisecolumn-wise storage and access. • developments using zebra RZ IO system • more and more graphics options ROOT: design,development, evolution

  44. PIAF : 1992-1994 • PAW Parallel Interactive Analysis Facility • very important step to understand the issues with parallelism with the IO sub system and the implications on the users analysis code. • very important to understand the balance between CPU, disk IO, network IO. ROOT: design,development, evolution

  45. software crisis1992-1994 • It was clear in 1992 that our Fortran-based systems will be impacted by new languages and new techniques. • Many people thought that Fortran was the future. • MOOSE project investigating languages (C++, Eiffel) and techniques (UML, Rose, OO-design) • commercial software or home-grown dilemma • OODBMS at the horizon ROOT: design,development, evolution

  46. software crisis1992-1994 -more • many computer scientists in the discussion • most of them with no experience • existing experience with large software neglected as well as feedback coming from experienced physicists • west coast syndrome • Babar as guinea pig (C++ and OODBMS) • Revolution, not Evolution ROOT: design,development, evolution

  47. Towards Objectivity1994-2000 • Gurus predict that OODBMS will replace RDBMS systems in 2000. • Post-mortem influence of defunct SSC • dream of a central data base accessed world-wide at the bit level for writing and reading. • Don’t worry about containers structure, CPU and network performance; the technology will solve your problems. • Most physicists trust gurus for reaching Nirvana ROOT: design,development, evolution

  48. 1994-2000Lost in the clouds before the grid and the clouds • Experienced physicists busy with LHC exp design. • It took many years (of frustration) to move them from good old Fortran to the magic of OO and C++ • catastrophic LCB (LHC Computing Board) committee with always the same referees with no experience in the new technology. As a consequence the LCB has no choice but trusting the gurus. • Despite early signs of problems, gurus and referees persist in their recommendations. ROOT: design,development, evolution

  49. 1995-1998ROOT is born in the meadows • While many people were actively working in committees and expecting magic from Objectivity, a small group of anarchists is exiled in the CERN 2 meadows. • free of committees and not spending time only with UML diagrams , but concentrating their work on key issues and delivering frequent releases of prototypes tested in real life experiments (eg NA49). • While the first ROOT prototype was a C++ version of PAW, it was rapidly realized that the key problem was with a general object persistency solution much different than the Objectivity solution. ROOT: design,development, evolution

  50. Original Objectives in 95 • Continue the tradition started with CERNLIB to develop packages targeted to the needs of our experiments and with a long life time. • Eg hbook (36 years), geant3 (28), paw(25): still in use! • Focus on data analysis (PAW in the oo world) • Open Source model to get contributions and feedback as soon as possible. • First ROOT prototype for NA49 in 1995, rapidly followed by many more adopters. Bottom-up (user-driven) instead of top-down (committee) approach. Users workshops. ROOT: design,development, evolution

More Related