20 30 years of Computing in HEP International

20 -30 years of Computing in HEP • International Workshop on Large Scale Computing • Kolkata • 8 February 2006 • René Brun • CERN

Hardware & Software Evolution Looking several years back to understand how HEP software has been shaped

Punched cards Program size limited by the size of the box and memory (32 Kb) 1973 2000 cards per box 200000 cards in all racks geant 1 hbook 1500000 lines in ROOT !! 750 boxes René Brun, CERN Kolkata IWLSC workshop 3

Mainframes, workstations, . . High level packages Graphics Mainframes Workstations 1982 HTV 1980 geant 3 René Brun, CERN Kolkata IWLSC workshop 1986 4

, OS, Desktops & Laptops CDC SCOPE IBM/OS/Wylbur CRAY VAX/VMS Apollo Aegys Unix workstations Windows Linux Mac. OSX René Brun, CERN Kolkata IWLSC workshop 5

Farms & GRID(s) PROOF René Brun, CERN Kolkata IWLSC workshop 6

The 3 technology laws • • Moore's Law: formulated by Gordon Moore of Intel in the early 70's the processing power of a microchip doubles every 18 months; corollary, computers become faster and the price of a given level of computing power halves every 18 months. (well ! Not true anymore, see later) Gilder's Law: proposed by George Gilder, prolific author and prophet of the new technology age - the total bandwidth of communication systems triples every twelve months. New developments seem to confirm that bandwidth availability will continue to expand at a rate that supports Gilder's Law. Metcalfe's Law: attributed to Robert Metcalfe, originator of Ethernet and founder of 3 COM: the value of a network is proportional to the square of the number of nodes; so, as a network grows, the value of being connected to it grows exponentially, while the cost per user remains the same or even reduces. But no laws about Software (well ! Murphy’s law) René Brun, CERN Kolkata IWLSC workshop 7

Relative units Hardware & Compilers René Brun, CERN Kolkata IWLSC workshop 8

Multi Core CPUs http: //www. intel. com/technology/computing/archinnov/platform 2015/ René Brun, CERN Kolkata IWLSC workshop 9

Program Size (lines of code) MS Windows Public Libraries Experiment Code base One user René Brun, CERN Kolkata IWLSC workshop 10

Program Size (RAM) ? René Brun, CERN Kolkata IWLSC workshop 11

Time to compile F 77/90 ADA C++ C René Brun, CERN Kolkata IWLSC workshop 12

Files, Classes Becoming a problem. Need tools to manage dependencies The same curve can be used to show the number of people in one large experiment René Brun, CERN Kolkata IWLSC workshop 13

Languages Machine code Business Cobol AI languages Algorithmic Languages Lisp, Prolog Formula Translation Pascal ADA SQL C Modula 2 Objective C C++ Java Eiffel René Brun, CERN Kolkata IWLSC workshop 14

Fortran to C++ complexity fortran Fortran + zebra Java power René Brun, CERN Kolkata IWLSC workshop 15

From static modules to plug-ins • • app. exe = (main. o) 1955 app. exe = (main. o, x. o, y. o) 1965 app. exe = (main. o, x. o, lib 1. a, lib 2. a) 1975 app. exe = (main. o, x. o, lib 1. a, lib 2. so, lib 3. so) 1985 app. exe = (main. o, libs. so) + dyn libs. so 1995 app. exe = (main. o, libs. so) + plug-in manager 2005 BOOT + URLs + local caches (interp + comp) 2015 ? ? • See my talk at CHEP René Brun, CERN Kolkata IWLSC workshop 16

Current ROOT structure & libs René Brun, CERN Kolkata IWLSC workshop 17

h. Draw() CINT lib. X 11 ------… lib. Core ------… I/O TSystem … pm lib. Hist ------… TH 1 TH 2 … René Brun, CERN local mode drawline drawtext … (Plug-in Manager) pm pm lib. Gpad ------… TPad TFrame … pm lib. Hist. Painter ------… THist. Painter TPainter 3 DAlgorithms … Kolkata IWLSC workshop pm lib. Graf ------… TGraph TGaxis TPave … 18

Compiled + interpreted code • • 1980: zcedex, mini command interpreter 1985: kuip/paw, command macro interp 1986: Tk/Tcl includes a GUI 1984: comis, Fortran 77 interpreter 1994: cint, a C & C++ interpreter 1998: python, OO on top of C++, Java 2002: ruby, better than python? 200 x: BOOT (inter->code generation->compiler) René Brun, CERN Kolkata IWLSC workshop 19

Basic types and modules • 1950: basic operators (trig functions part of the application) • 1953: trig functions in a library • 1954: fortran types (integer, real, hollerith). Subroutines communication only via arguments. • 1965: subroutines communicate via a blank common, then labeled common blocks. • 1975: communication via a data structure management system • 1980: derived types • 1988: Object-Oriented programming: classes • 1995: parametrized types, templates, STL • 1996: Reflexion/RTTI (Java) René Brun, CERN Kolkata IWLSC workshop 20

Programing models • • • Procedural sequential Parallelism (MPI) Vectorisation Shared memory Multi-threading Client-server • Statefull • Stateless ->web • Corba • Distributed parallel computing (asynchronous) • Messages. Signal/slots René Brun, CERN Kolkata IWLSC workshop 21

Problems with Fortran • • • Abuse of common blocks. Unmanageable in large programs No data structures No generic machine independent I/O Systems like Hydra(1974), Zbook(1975), Bos(1977), Zebra(1983) designed to overcome these problems. But most people loved it René Brun, CERN Kolkata IWLSC workshop 22

The Zebra system (1983) • Zebra = Zbook + Hydra • Main data structure management system used by PAW and Geant 3 and also many collaborations. • Powerful machine independent I/O • FZ: sequential • RZ: direct access (PAW ntuples) • Nice Data structure documentation system, including an interactive browser DZDOC. René Brun, CERN Kolkata IWLSC workshop 23

Zebra bank descriptor Zebra style iq(lvx+vtype)= type I/O descriptor q(lvx+vdz) = dz ltk = lq(lvx-1) C/C++ style Vertex* vx; vx. vtype = type; vx. vdz = dz; Track* tk = vx. tk; René Brun, CERN Kolkata IWLSC workshop 24

Zebra DZDOC call fzout(lun, lhdir, . . ) lhdir Zebra I/O could support very complex data structures A Zebra bank similar to a C++ data object René Brun, CERN Kolkata IWLSC workshop 25

Atlas DZDOC René Brun, CERN Kolkata IWLSC workshop 26

Zebra pros/cons • • • Programming style archaic Easy to overwrite data structures Shared global store(s) Self-describing structures Concept of multi-heap (constants, histograms, event, . . ) Efficient garbage collection (division wipe) Built-in efficient and machine independent I/O Used by Geant 3, PAW and many experiments René Brun, CERN Kolkata IWLSC workshop 27

Geant 1, 2, 3, ……. . 4 • Geant 1 1974 • 2000 lines of Fortran 4 • No physics, no geometry, only a bare framework • Geant 2 1975 • 20000 lines of Fortran 4 • Some physics for multiple scattering, energy loss, decays, framework for geometry and tracking • Geant 3 1980, 81 1994 ------ 2006? • • • About 120000 lines of Fortran 77 + zebra + paw Electromagnetic physics 4 hadronic packages (Tatina, Gheisha, Fluka, Calor) Powerful geometry package including graphics Hits/Digits framework I/O subsystem (zebra) for all structures including geometry. • Used by many experiments. Still René Brun, CERN a reference!!! Kolkata IWLSC workshop 28

Fluka • Originally developed by safety protection group at CERN (stevenson) + aarnio + ranft) 1985 ? • Reengineered by A. Ferrari &co: Rubbia project 1990 • Probably the best for Physics processes • Simple geometry • The reference for radiation/shielding • Written in fortran 77 • Interfaced with VMC (TFluka) and G 4 (Flugg) René Brun, CERN Kolkata IWLSC workshop 29

Geant 4 • • Started in 1994 Originally a flagship project for the move to C++ A huge investment in manpower About 600000 lines of C++ Validation process in Atlas, CMS and LHCb Physics processes getting better and better But still many limitations • Poor interpreter (small subset callable from python) • No I/O interface (geometry cannot yet be made persistent) • Batch style graphics René Brun, CERN Kolkata IWLSC workshop 30

The Virtual MC (1998) User Code VMC G 3 transport G 4 transport FLUKA transport Reconstruction Geometrical Modeller Visualisation Generators René Brun, CERN Kolkata IWLSC workshop 31

Virtual Monte Carlo and ROOT Geometry • The ROOT geometry package (TGeo) can be used in detector simulation, reconstruction, graphics, etc. • TGeant 3 • • Used in production – native GEANT 3 New: TGeant 3 TGeo – interface to G 3 using TGeo geometry • • TGeant 4 • • Used for Geant 4 physics validation – G 4 native geometry built after g 3 tog 4 conversion No interface yet between G 4 and ROOT geometry • • But Andrei Gheata actively working on it (expected this spring) TFluka • • • No modification required in the user code Validated by Alice Same speed or faster than TGeant 3 Old geometry interface using G 4 geometry vis FLUGG Currently a fully validated geometry interface based on TGeo Validated by the Fluka team At least 2 times slower than TGeant 3 The VMC framework is currently used by Alice, Opera, Minos, NA 48 b, Hades, CBM and may be STAR. René Brun, CERN Kolkata IWLSC workshop 32

PAW: a long saga • First version (Jan 1985) by a committee • Must use GKS • GUI based on VT 100 functionality • No ntuples • • June 1985: developers “abolish” the committee Higz: GKS + X 11 Row wise ntuples, then Column. Wise. Ntuples (1986) Frozen in 1994, but still maintained by ROOT team René Brun, CERN Kolkata IWLSC workshop 33

Crisis: 1992 1999 Move to F 90? Attempts to use OODBMS and commercial software

Why not F 90 after F 77? • In 1989, 90, 91 assumption was F 90 • Some work invested in I/O with F 90 (to support derived types). We could not solve this problem, because no formal way to parse the F 90 module descriptors. • In 1992 many forces pushing towards OO • CHEP Annecy, web, Next • Crisis in Dec 1992 (at least in IT software group) • 1/3 in favour of f 90 • 1/3 in favour of commercial solutions • 1/3 in favour of C++ René Brun, CERN Kolkata IWLSC workshop 35

1993, 1994, 1995 • ZOO, Next. Paw, Geant 3. 5 proposals rejected X • ZOO: Zebra in the OO world • Next. Paw: Paw evolution ->C->C++ • Geant 3. 5: Implement geometry package in C++ • Geant 4 proposal (June 1994) • RD 45/Objectivity project (fall 1994) • ROOT project starts (in NA 49) (Jan 1995) Objectivity LHC++ CERNLIB PAW GEANT 3 1994 ROOT GEANT 4 Oracle COOL René Brun, CERN LCG Kolkata IWLSC workshop 2006 36

1996 • ROOT chooses the CINT interpreter • We had been attracted by Java (Object base class, many common ideas). • Work on object persistency based on the dictionary information (introspection). • Design of ROOT Trees (split mode). Comparison with Objectivity • LHC++ project starts (against ROOT) • see Jamie’s talk René Brun, CERN Kolkata IWLSC workshop 37

1997 ->2000 • • Getting experience with OO (professional developers). Most users lost in f 77 ->C++ First signs of problems with Objectivity in Babar FNAL RUN II chooses ROOT • But C++ seen as a temporary solution waiting for efficient Java at the horizon 2003. • ROOT : automatic I/O based on dictionary, automatic schema evolution. René Brun, CERN Kolkata IWLSC workshop 38

Problems with commercial systems • • • Licensing Deployment Vendor is late to follow with compilers & OS Difficult to request new functionality Difficult to get good people to do support and maintenance. Programmers want to develop code. René Brun, CERN Kolkata IWLSC workshop 39

Data Analysis Software • 1960: Do it yourself • 1968: SUMX • Histograms and data blocks described in input file. SUMX is the master. • 1973: HBOOK • Histogram library. User controls the event loop and the selection. • 1985: PAW • Interactive histograms/fitting. Ntuples • 1995: ROOT • Same as PAW + persistency for C++ objects. C++ interpreter • 2005: PROOF and GRID • Distributed analysis: client->Master->Workers (parallelism) René Brun, CERN Kolkata IWLSC workshop 40

PAW Simple adhoc interpreter KUIP paw > set col 2 paw > hi/plot 1 paw > set col 4 paw > hi/plot 2 same paw > ntuple/plot 100 px: py px*px+py*py>1 René Brun, CERN Kolkata IWLSC workshop 41

ROOT C++ interpreter CINT root > h 1. Set. Line. Color(2) root > h 2. Set. Line. Color(4) root > h 1. Draw() root > h 2. Draw(“same”) root > t. Draw(“px: py”, ”px*px+py*py>1”) root > myobject. Do. Something(…) René Brun, CERN Kolkata IWLSC workshop 42

Graphics & GUI evolution • • • Plotters (eg GD 3): Calcomp GKS times: screen is the memory PHIGS X 11, GL: the winners From graphics attributes set in sequence to Objects • With PAW: • set color red • Now all primitives are red • With ROOT: attribute values do not depend on the order they are set => easier to write a graphics editor • From Callbacks Messages->Signal&Slots • Signal&Slots require an interpreter (see Qt and Root) • Scriptable GUIs (a MUST) René Brun, CERN Kolkata IWLSC workshop 43

Graphics and GUI systems • • • • Calcomp plotters 1955 First graphics packages (CERN GD 3 1970) HPLOT 1975…… HPLOT -> HIGZ GD 3 1978 HPLOT -> HIGZ US Core system (fnal) 1981 HPLOT -> HIGZ GKS 1983 HPLOT -> HIGZ PHIGS 1985 HPLOT -> HIGZ X 11 1985 PAW ->VT 100, GKS, 1985 PAW ->MOTIF 1991 ROOT -> X 11 1995 ROOT ->Win 32 1996, 2002 ROOT ->Qt 2002, 2006 ROOT -> GL 2002 René Brun, CERN Kolkata IWLSC workshop 44

Graphics and GUI systems (cont) • Most graphics/GUI systems that we have used have been based on International standards or de facto standards. • All these systems had a limited life time • • • The CORE system : 5 years GKS : 10 years PHIGS : < 10 years X 11 : > 20 years MOTIF : < 8 years Qt : ? ? • So far, no applications built directly on top of these systems were portable to the next generation. A new generation every 8, 10 years René Brun, CERN Kolkata IWLSC workshop 45

from plotters to objects All items are clickable objects René Brun, CERN Kolkata IWLSC workshop 46

Can take advantage of graphics accelerators René Brun, CERN Kolkata IWLSC workshop 47

Extremely important The ROOT GUI Is fully scriptable René Brun, CERN Kolkata IWLSC workshop 48

ROOT GUI/graphics interoperability ROOT GUI and Graphics embedded in a Windows MFC application The ROOT GUI events can be passed to the MFC application event loop. A ROOT canvas can be embedded in a MFC canvas René Brun, CERN Kolkata IWLSC workshop 49

ROOT GUI/graphics interoperability ROOT GUI and Graphics embedded in a Qt application The ROOT GUI events can be passed to the Qt application event loop. A ROOT canvas can be embedded in a Qt canvas Qt browser Drag & Drop objects in the ROOT canvas One can use ROOT context menus René Brun, CERN Kolkata IWLSC workshop 50

Interpreters & dictionaries *. h Python interpreter *. h rootcint reflex C++ interpreter Dictionary 1 Data & Functions Dictionary 2 Data & Functions Compiled Library 1 Compiled Library 2 René Brun, CERN Kolkata IWLSC workshop SWIG Boost Dictionary 3 Functions Compiled Library 3 51

Interpreter & Compiler integration execute file script. C root >. x script. C root > Do. Something(…); execute function Do. Something root >. x script. C++ compile file script. C and execute it root >. x script. C+ compile file script. C if file has been modified. execute it g. ROOT->Process. Line(“. L script. C+”); g. ROOT->Process. Line(“Do. Something(…)”); René Brun, CERN Kolkata IWLSC workshop same from compiled or interpreted code 52

Possible Progress with Interpreters • Eliminate the stub interface to call C/C++ functions. • This is already possible in CINT with C libraries. • It will be possible with C++ when a standard ABI will be available, otherwise compiler&linker dependent. • If compiler is fast enough (eg C), use the interpreter only for organizing the top level. • If next C++ provides introspection, one could eliminate • the header files parser • 95 per cent of the dictionary structure in memory • A good argument to have the interpreted and compiled code being in the same language! • But WHEN ? ? ? ? René Brun, CERN Kolkata IWLSC workshop 53

Object Persistency with ROOT Object Persistency with Objectivity

Object Persistency • Object Persistency has been a long snake for 10 years or more. • Today general agreement to exploit HEP feature of having mainly read-only files and use RDBMS systems only where concurrent write access is required. • A lot of work spent in ROOT to understand design an efficient object streaming system (object-wise and member-wise). • I/O system and query system must know each other. René Brun, CERN Kolkata IWLSC workshop 55

OODBMS (ie Objectivity) • Hope: • Address one single object in a petabyte data base • Resolve all the object catalog issues • Reality: • • Licensing/installation/portability problems 64 bits OID did not scale above 10 terabytes Request for 128 bits OID never implemented Locking problems when many users in read mode. Central DB mismatch with GRID No automatic schema evolution (big problem) No interactivity René Brun, CERN Kolkata IWLSC workshop 56

OODBMS (ie Objectivity) (2) • The OODBMS evangelists (and later RDBMS) passed many wrong messages • Commercial data bases will save manpower • Commercial data bases can be used for all type of data • Performance is OK • Reality: • Probably more than 100 personyears invested in this exercise • To be compared to a few man years for ROOT I/O • Performance was not adequate (already spotted by ROOT/Objy comparisons early 1996) • Physics analysis requirements were totally ignored • Too much weight given to “experts in bookkeeping” René Brun, CERN Kolkata IWLSC workshop 57

ROOT I/O principles • Two main I/O solutions • Unix-like file/directory structure with keyed objects • OK for histograms, geometries, mag field • Special Event data oriented Trees • With object streaming and splitting modes • Optimized for data analysis • Design targeting performance and minimum file size • Support for network files • Exploit advantages of read-only files as much as possible • Interface with RDBMS when locking required René Brun, CERN Kolkata IWLSC workshop 58

ROOT Trees Memory 0 T. Get. Entry(6) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 T. Fill() T René Brun, CERN Kolkata IWLSC workshop 59

Data Analysis on the GRID(s) see Fons talk

Some observations

Experience with C++ • Very powerful but complex language. • Easy to make a complex system with a lot of class dependencies. Changing one class forces a recompilation of many other classes. • No garbage collector. Only one heap. • ABI(Application Binary Interface) is not yet standardized: a mess on Linux/gcc (C is OK) • No introspection: -> develop yours. • Too much coupling between data and code. • Templates defined statically at compilation time, ie difficult to use in an interactive environment. • Slow compilation if abuse of templates and STL René Brun, CERN Kolkata IWLSC workshop 62

Missing features in C++ • Introspection • Not possible to compile a class from a dictionary • Multi-heap (like Zebra divisions) • Would require a garbage collector and a Handle type like in C++/CLI from MS • Possibility to add one or more functions without recompiling the class, although this can be easily done in C. • Dynamic creation of templated types René Brun, CERN Kolkata IWLSC workshop 63

Introspection systems • Meta information describing all types and functions. • Not necessary for languages like f 77 having only basic types. I/O in f 77 implemented via simple switch statements. • Vital for languages supporting derived types for automatic I/O, inspectors, browsers and interpreters. • CINT, Java, cint/root/reflex René Brun, CERN Kolkata IWLSC workshop 64

Why not Java or Python • Java strong candidate in 1996 ->2000 • Why experiments moved to C++? • Speed, Geant 4, ROOT ? Microsoft view Computer scientist view Java is more productive than C/C++. Use C/C++ only when speed or bare metal access is called for. Python/Ruby is more productive than Java and more pleasant to code in. René Brun, CERN Kolkata IWLSC workshop 65

Main software problems seen by large experiments • • Move to C++ completed (well nearly!) Complex experiment framework Too many dependencies Difficult to install (SCRAM, CMT) Installation time far too long The wheel is reinvented many times Several unwanted features (eg Atlas Storegate) Coding conventions not followed • A code checker is essential • Non documented classes and modules René Brun, CERN Kolkata IWLSC workshop 66

LHC software Alice Atlas CMS ROOT number of lines in header files 102282 698208 104923 153775 classes total 1815 8000? ? ? ? 1500 classes in dict 1669 >4120 835 1422 lines in dict 479849 ? ? ? 103057 698000 classes c++ lines 577882 1524866 277923 857390 total lines Classes+dict 1057731 ? ? ? 380980 1553390 total f 77 lines 736751 928574 ? ? ? 3000 directories 540 19522 <500 958 comp time 25’ 750’ 90’ 30’ comp lines/s 1196 50 (70) 71 863 René Brun, CERN Kolkata IWLSC workshop 67

Observations • A considerable amount of time is spent in installing software (up to one day for an expert). • Porting to a new platform is non trivial. • Dependency problems in case many packages must be installed. • Only a small subset of the software is used. • The installation may require a huge amount of disk space. Users are scared to download a new version. • This is not fitting well with the GRID concept. • The GRID should be used to simplify this process and not to make it more complex. René Brun, CERN Kolkata IWLSC workshop 68

René Brun, CERN Kolkata IWLSC workshop 69

René Brun, CERN Kolkata IWLSC workshop 70

Fraction of code really used in one program %functions used %classes used René Brun, CERN Kolkata IWLSC workshop 71

Consequences • The fact that only a very small fraction of the total code base is used has important consequences. • We must turn this apparent problem into a great feature. • BOOT: a proposal to solve this problem. • see my talk at CHEP. René Brun, CERN Kolkata IWLSC workshop 72

Spare slides

Tree Friends 01 23 45 67 89 10 11 12 13 14 15 16 17 18 0 1 2 3 4 5 6 7 8 Entry # 8 01 23 45 67 89 10 11 12 13 14 15 16 17 18 Public User read Write René Brun, CERN Kolkata IWLSC workshop 74

File types & Access in 5. 06 user Local File X. xml http Local File X. root René Brun, CERN TFile TTree. SQL TKey/TTree TSQLServer TStreamer. Info TSQLRow TSQLResult rootd/xrootd Oracle Dcache Castor RFIO Chirp Kolkata IWLSC workshop My. SQL Pg. SQL Sap. Db 75

Typical trends with Experiments frameworks • A few gurus design the framework • In general adequate for batch processing (simulation and reconstruction). • But too complex for the majority of users. • Users find simpler individual solutions. • Many users work in several experiments and want to use common software. • Fights between groups. • New management structure put in place. Software is not a technical problem. There are many ways to implement an algorithm, a module, a complete system. Sociology is an important issue in large collaborations. René Brun, CERN Kolkata IWLSC workshop 76

Experiment Frameworks Starting point Monolithic simulation reconstruction user Simulation Analysis toolkit PAW or ROOT used like PAW René Brun, CERN Kolkata IWLSC workshop 77

Experiment Frameworks End point Simulation toolkit User Loads only what he needs Simulation & Reconstruction libraries hierarchy Core framework with plug-in manager persistency, dictionary, folders, graphics, GUI and general utilities René Brun, CERN Kolkata IWLSC workshop 78

Alice packages with > 10000 lines 398742 146414 128337 128103 105763 94548 72400 52443 51489 50932 46176 41998 39407 35916 31820 27751 27025 26667 24258 21588 20562 18344 15232 13142 12945 10966 10944 10659 PDF PYTHIA 6 HLT ITS MUON DPMJET STEER HBTAN TPC PHOS TRD ISAJET RALICE EMCAL ANALYSIS HERWIG FMD TOF EVGEN HIJING JETAN RAW STRUCT PMD RICH FASTSIM MONITOR ZDC René Brun, CERN fortran=398729, ansic=13 fortran=140748, cpp=5413, ansic=153, pascal=100 cpp=127601, ansic=605, sh=100, csh=31 cpp=128010, sh=93 cpp=105673, sh=90 1. 5 million fortran=94267, cpp=281 lines of code cpp=72400 cpp=51260, fortran=1183 cpp=51479, sh=10 cpp=50639, csh=293 cpp=46176 fortran=40483, cpp=1494, pascal=21 cpp=29764, ansic=9355, sh=288 cpp=35410, fortran=383, csh=123 cpp=31820 fortran=27246, cpp=477, ansic=28 cpp=27021, sh=4 cpp=26667 cpp=24258 fortran=21099, cpp=489 cpp=19687, fortran=875 cpp=18344 cpp=15232 cpp=13142 cpp=12945 cpp=10966 cpp=10944 cpp=10659 Kolkata IWLSC workshop 79

BOOT: Use Case 1 • Assumes BOOT already installed on your machine user@xxx. yyy. zzz • Nothing else on the machine except the compiler (no ROOT, etc) • Import a ROOT file containing histograms, Trees and other classes (usecase 1. root) • Browse contents of file • Draw an histogram René Brun, CERN Kolkata IWLSC workshop 80

Use Case 1 Usecase 1. root (2 Mbytes) Contains references (URL) to classes in namespace ROOT Local cache with the source of the classes really used + binaries for the classes or functions that are automatically generated from the interpreter (like ACLIC mechanism) user@xxx. yyy. zzz René Brun, CERN http: //root. cern. ch/coderoot This is a compressed ROOT file containing the full ROOT source tree automatically built from CVS (25 Mbytes) + ROOT classes dictionary DS generated by Reflex (5 Mbytes) + The full classes documentation Objects generated by the source parser (5 Mbytes) pcroot@cern. ch Kolkata IWLSC workshop 81

Use Case 1 pictures usecase 1. root code. root René Brun, CERN Kolkata IWLSC workshop 82