Introduzione al Software di CMS N. Amapane

Nicola AmapaneTorino, Aprile Outline CMS Software projects The framework: overview Finding more information

Nicola AmapaneTorino, Aprile Events are big (raw event is 2MB) Detector digitization has to take into account multiple crossings 34 cm -2 s -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 X 0 of tracker material: –Lots of bremsstrahlung for the electrons, –TK-ECAL matching non-trivial Challenges for LHC SW

Nicola AmapaneTorino, Aprile Computing at LHC The Problem Unprecedented need for computing power Long project lifetimeGuidelines 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 Sophistication Complexity

Nicola AmapaneTorino, Aprile CMS Software Projects OSCAR Detector Simulation ORCA Reconstruction and Analysis FAMOS Fast Simulation IGUANA Visualization COBRA Framework and services CMSToolBox Anaphe, G4 Root, etc CMSIM Detector Simulation (being phased out)

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

Nicola AmapaneTorino, Aprile CMSIM FZ signal HEPEVT Ntuple ORCA FZ signal FZ minbias ROOT/IO SimHits/minbias ROOT/IO SimHits/signal ROOT/IO Digis Ntuple G3Reader SimReader RecReader MC generator CMKIN Production User The Analysis Chain Simulation Generation HitformattingDigitisationAnalysis

Nicola AmapaneTorino, Aprile HEPEVT Ntuple ORCA 7 Ntuple signal Ntuple minbias ROOT/IO SimHits/minbias ROOT/IO SimHits/signal ROOT/IO Digis Ntuple OSCARSimReader RecReader MC generator CMKIN Production User OSCAR 2 Check: OSCAR/src/… …/OscarApplication/… …/G4SimApplication/… …/test/README The Analysis Chain with OSCAR Simulation Generation DigitisationAnalysis

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

Nicola AmapaneTorino, Aprile 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

Nicola AmapaneTorino, Aprile Reconstruction on Demand RecUnit ClusterA RecUnit Crystal ClusterAlgo A Analysis program ClusterAlgo B Cl1Cl2Cl3Cl4 K1K1 K2K2 K3K3 K4K4 K5K5 K6K6 K7K7 K8K8 K9K9 K 10 K1 1 K 12 K 13 K 14 K 15 K 16 RecUnit ClusterB Cl1Cl2Cl3

Nicola AmapaneTorino, Aprile Event Driven Notification Obs1Obs2Obs3 Dispatcher Observers

Nicola AmapaneTorino, Aprile init() } recmuon++;}

Nicola AmapaneTorino, Aprile 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 Making things happen

Nicola AmapaneTorino, Aprile 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

Nicola AmapaneTorino, Aprile Online Documentation OO software home – Past Tutorials – – MC Simulation page –