Introduzione al Software di CMS

1. Introduzione al Software di CMS N. Amapane

2. Outline • CMS Software projects • The framework: overview • Finding more information

3. Challenges for LHC SW • Events are big (raw event is 2MB) • Detector digitization has to take into account multiple crossings • Pileup: @1034 cm-2s-1= 17 minimum bias events/crossing • Calorimetry needs -5 to +3 crossings • Tracker loopers can persist for many crossings • Typically need info from ~ 200 minimum bias events per signal event • Study at different luminosities  different pileup • include pileup in digitization (front end of reconstruction) • Track finding in very complex environment • High magnetic field and ~ 1 X0 of tracker material: • Lots of bremsstrahlung for the electrons, • TK-ECAL matching non-trivial

4. Computing at LHC The Problem • Unprecedented need for computing power • Long project lifetime Guidelines • New software technologies: OO • New development practices • SW engineering, quality checking, code management • New data access model • Use existing components whenever available • commercial, HEP, open source Complexity Sophistication

5. CMS Software Projects CMSIMDetectorSimulation (being phased out) FAMOSFast Simulation OSCARDetectorSimulation ORCAReconstruction and Analysis IGUANAVisualization COBRAFramework and services CMSToolBox Anaphe, G4 Root, etc

6. SimHits Stages of Reconstruction Produced by MC, stored in DB Include Pileup, some stored in DB (Tk) Digis Pre-processed digits, some stored in DB (Calo) RecHits Tracks,Clusters etc, will be stored in DB RecObj

7. The Analysis Chain Generation Simulation CMSIM CMKIN HEPEVTNtuple FZsignal MC generator Production ORCA Hitformatting Digitisation Analysis RecReader SimReader G3Reader FZminbias ROOT/IOSimHits/minbias ROOT/IO Digis Ntuple FZsignal ROOT/IOSimHits/signal User Production

8. The Analysis Chain with OSCAR Generation CMKIN Check: OSCAR/src/……/OscarApplication/……/G4SimApplication/… …/test/README HEPEVTNtuple MC generator Production OSCAR 2 ORCA 7 Simulation Digitisation Analysis RecReader OSCAR SimReader Ntupleminbias ROOT/IOSimHits/minbias ROOT/IO Digis Ntuple Ntuplesignal ROOT/IOSimHits/signal User Production

9. Structure of the software 3 components (top-down list): • Physics modules • Implemented by physicists • Plugged into the framework at run-time • Do not communicate directly with each other USER • Service and utility toolkit • Physics services (geometry, fitting, math, etc.) • Computer services (user interface, documentation, etc.) • Application framework • Base classes, abstractions • Flow control, steering, error report, timing • Persistency The framework shields the physics SW from the underlying technologies.

10. Framework Basic Dynamics Action on Demand/Implicit Invocation • Modules register themselves at creation time and are invoked when required. • They do nothing unless triggered • No central ordering of actions, no explicit control of data flow: only implicit dependencies • Example: “I can produce Tracks of type T1” • Connections between algorithms (i.e. data objects required) are handled by CARF (subsystem of COBRA) • User asks for Tracks of type T1 • CARF determines they are not already in persistent store (and valid) • CARF triggers (previously registered) T1 algorithm • T1 algorithm asks CARF for Tracker RecHits • CARF serves them from DB or triggers the Tracker RecHit algorithm

11. Event Driven Notification Dispatcher Obs1 Obs2 Obs3 Observers

12. init()} recmuon++;}

13. Making things happen • The behaviour of a job is specified supplying shared libraries that carry out atomic actions • Classes in the library are instantiated with a “PKBuilder” • Classes that have to be called for each new “event” are “observers” of that event • Objects are requested through special iterators • Reconstruction algorithms register themselves and are called when needed! • In ORCA, data-cards are specified with the “.orcarc” file

14. Recent changes • After the DAQ TDR was released, major changes in all SW (planned since long time) • Objectivity/DB replaced by ROOT/IO • Simulation: GEANT4 (OSCAR) replaces GEANT3 (CMSIM) • ZEBRA & FORTRAN code will disappear! • New Linux compiler (more strict) • Still in transition phase • Rapid evolution • Not everything is stable/fully tested • This tutorial based on latest versions • ORCA 7_2_0_pre13, OSCAR 2_2_0_pre2b

15. Online Documentation • OO software home • http://cmsdoc.cern.ch/cmsoo/cmsoo.html • Past Tutorials • http://cmsdoc.cern.ch/orca/Tutorials/2002-05-SanDiego • http://agenda.cern.ch/fullAgenda.php?ida=a03520 • MC Simulation page • http://cmsdoc.cern.ch/cms/production/www/html/general/index.html