LHCb Software

1. LHCb Software Vanya BELYAEV

2. Preface • It is NOT a tutorial for beginners • If you need – the tutorial will follow • It is NOT a tutorial for advanced users • If you need – the tutorial could be organized • It is NOT an commercial for new or advanced software • It is just some general “introduction” • Introduction to the Terminology? • One does not need be a software expert • One does not need know well LHCb Vanya BELYAEV

3. The language • LHCb software is mainly OO: • C++ • Blueprint-1998 has stated the possibility to keep/(re)use Java and • Was very promising and attractive at the end of XX. There were even speculations to build pure Java framework • Set certain limitation for the software structure and many conventions, which are a bit cryptic now • Java is dead • Python appears to be very attractive and gets more and more fans in LHCb • Appears to be well consistent with C++ code due to easy coexistence of C++ and python • Now: C++, Python and a little bit of pure C Vanya BELYAEV

4. The concept • Different applications: • Simulation • Digitization • Reconstruction • Physics Analysis • Event Display • One common framework has many advantages: • Share the common work, define proper common conventions and rules, reuse the experience, lines and all goodies form your colleagues, avoid duplication of lines and bugs • Shorten the learning curve Vanya BELYAEV

5. Many reusable components • Detector/Material Description: • Simulation, Reconstruction, Event Display • Particle Description/Particle Properties • Simulation, Analysis, Event Display • Magnetic field description • Simulation, Reconstruction and analysis • More Basic stuff, like statistical analysis, Histograms, N-tuples, Counters, Printout,… • Many purely technical, but important stuff, like profiling, configuration, … Vanya BELYAEV

6. LHCb major applications Vanya BELYAEV

7. Simulation: Gauss • Two major phases • Event generation: • Event production • Pythia • Weak decays • EvtGen • Options: Hijing, Herwig(++), Sherpa, Alpgen, HiddenValley, BcVegPy • Detector simulation: • “GiGa” • Geant4 toolkit Vanya BELYAEV

8. Gauss (ii) • We do not have any concrete C++ lines for Gauss • except HPD Quantum efficiency • Automatic conversion of Geometry • The most painful part of Geant4 is eliminated • “The physics” is specified through configuration • Difficult but much easier than C++ • Input: none or “world wide standard format” • At least one theoretician knows it • Output: • Generator Particles + vertices • Monte Carlo Particles and Vertices and Hits • All above plus almost all secondaries from interactions • Smart algorithm for selection (need time to describe)… Vanya BELYAEV

9. Digitization: Boole • Again two phases: • Convert Monte Carlo hits into “Digits” • with few possible next steps, e.g. to “Clusters” • The concept if detector-dependent • Emulate the raw data from detector (TELL1 boards), the input to Event Filter Farm • “Raw Bank” • For some detectors (VELO) this format is VERY advanced. It is not the individual strips, it is already the clusters.. • For some detectors is it just a Digits… • zero-suppressed or not.. • The output: Raw-tapes with Raw-banks Vanya BELYAEV

10. Reconstruction: Brunel • Reconstruction: the phases are implicit and only partly ordered • There are also some “formal” phases, interesting only from pure computing point of view, thus out of discussion today • Unpacking input data from Raw Bank • Perform 0-suppression, if needed • The first pass of reconstruction, tracks-independent • Reconstruct the tracks • The second pass: track dependent actions • Output: Various kind DST tapes: DST and rDST with tracks, proto-particles and some additional PID info. Vanya BELYAEV

11. Analysis: DaVinci • Make a physics analysis • The natural phases: • Create Particles from Proto-Particles • Make the analysis itself… • Essentially the collection of various tools (e.g. vertex fit, mass-vertex fit, lifetime fit, etc) • Output: Histograms, N-Tuples, Event Tag collections, (nano,micro,mini,reduced,full)DSTs, … Vanya BELYAEV

12. Trigger: Moore • Trigger reconstruction: • Runs both online and offline • Special version of reconstruction: • Partial • Induced by the L0 information • Essentially no or greatly reduced PID • Still not clear now • HLT selections: • Simplified version with loose cuts of algorithms for “the final” event selection Vanya BELYAEV

13. Event Display: Panoramix • Event Display (and a bit more) • Visualization of • Detector Data • Event Data: • Particles, Vertices, hits, digits, clusters, links to Monte Carlo truth • Statistical Data + Statistical Analysis • Initially GUI • Many scripting abilities (command line) • … , Python, … Vanya BELYAEV

14. Python is cool! • Python converts Panoramix into almost universal interactive environment • Interactivity • Data Access & Inspection • Use of underlying C++ tools and algorithms • The great flexibility • Easy to start • Many enthusiasts • Appears to be very friendly and useful Vanya BELYAEV

15. Bender • Interactive Python-based physics analysis environments • Combines Python + LoKi: • Nice semantics and interactivity • Ideal for • Prototyping • Supervising Vanya BELYAEV

16. LoKi • Toolkitfor easy and user-friendly physics analysis • Try to hide the technicalities • Concentrate on physics needs • Make the perfect match between physics algorithm and C++ • 1 page of cuts description -> 1 page of pseudocode • 1 idiom corresponds to O(1) line of code • The actual base for new trigger implementation • Generic part “HLT alleys” • Exclusive part • Many features appear initially in LoKi and then migrate to other projects: Gaudi, Tracking, Trigger, DaVinci, … • And the process continues Vanya BELYAEV

17. Other applications • ONLINE, EULER, ORWELL, VETRA, Alignment, … • ALL of them (except Bender & Panoramix) are just preconfigured Gaudi application • The same executable for all applications • Everything is loaded dynamically (and often only on-demand) • One can combine all application in one go (if needed) Vanya BELYAEV

18. Gaudi • Framework Definition • An architectural pattern that codifies a particular domain. It provides the suitable knobs, slots and tabs that permit clients to use and adapt to specific applications within a given range of behavior. • In practice • A skeleton of an application into which developers plug in their code and provides most of the common functionality. Vanya BELYAEV

19. Framework benefits • Common vocabulary, better specifications of what needs to be done, better understanding of the system. • Low coupling between concurrent developments. Smooth integration. Organization of the development. • Robustness, resilient to change (change-tolerant). • Fostering code re-use Vanya BELYAEV

20. Gaudi • GAUDI is an architecture and framework for event-processing applications (simulation, reconstruction, etc.) • Initially developed for LHCb, it has been adopted and extended by ATLAS and adopted by several other experiments including GLAST and HARP • Main Design Choices • Separation between “data” and “algorithms” • Three basic categories of “data”: event data, detector data, statistical data • Separation between “transient” and “persistent” representations of data • Data store-centered (“blackboard”) architectural style • “User code” encapsulated in few specific places • Well defined component “interfaces” Vanya BELYAEV

21. How it works Vanya BELYAEV

22. And stop here… • Here I prefer to stop for today. • The next possible steps/options: • The basic Gaudi tutorial • with optional hands-on session • Analysis tutorials: • The basic DaVinci tutorial • The basic LoKi tutorial • The basic Bender (GaudiPython) tutorial • All of them with optional hands-on session • How to proceed? • Who needs them? Vanya BELYAEV