CMS Software Architecture Software framework services and persistency

CMS Software Architecture Software framework, services and persistency in high level trigger, reconstruction and analysis Vincenzo Innocente CERN/EP 9/16/2020 1 CHEP 2000 7 -11 February, Padova, Italis

CMS (offline) Software Environmental data Request part of event Slow Control Quasi-online Reconstruction Online Monitoring store Event Filter Objectivity Formatter Request part of event Store rec-Obj Request part of event store Persistent Object Store Manager Object Database Management System store Simulation G 3 and or G 4 Software Architecture Vincenzo Innocente, CERN/EP Store rec-Obj and calibrations Data Quality Calibrations Group Analysis Request part of event User Analysis on demand CHEP 2000 7 -11 February, Padova, Italia

Requirements (from the CTP, dec. `96) u. Multiple Environments: u Various software modules must be able to run in a variety of environments from level 3 triggering, to individual analysis u. Migration between environments: u Physics modules should move easily from one environment to another (from individual analysis to level 3 triggering) u. Migration u Should to new technologies: not affect physics software module Software Architecture Vincenzo Innocente, CERN/EP CHEP 2000 7 -11 February, Padova, Italia

Requirements (from the CTP) u. Dispersed code development: u The software will be developed by organizationally and geographically dispersed groups of part-time non-professional programmers u. Flexibility: u Not all software requirements will be fully known in advance Not only performance Also modularity, flexibility, maintainability, quality assurance and documentation. Software Architecture Vincenzo Innocente, CERN/EP CHEP 2000 7 -11 February, Padova, Italia

Use Cases Simulated Hits Formatting Digitization of Piled-up Events Test-Beam DAQ & Analysis L 1 Trigger Simulation Track Reconstruction Calorimeter Reconstruction Global Reconstruction Physics Analysis Software Architecture Vincenzo Innocente, CERN/EP CHEP 2000 7 -11 February, Padova, Italia

Track Reconstruction Local measurements belongs to detector element and are affected by the detector element state (calibrations, alignments) Pattern recognition navigates in the detector to associate local measurements into a track Subject of T. Todorov & A. Vitelli talks Software Architecture Vincenzo Innocente, CERN/EP CHEP 2000 7 -11 February, Padova, Italia

Global Reconstruction Global reconstruction is performed in an absolute reference frame 4 -vector-like objects are built out of trajectories and localized energy deposits A wide range of particle identification, jet, vertex, etc algorithms can be applied to produce others 4 -vector -like objects Access to the original detector data maybe required Software Architecture Vincenzo Innocente, CERN/EP CHEP 2000 7 -11 February, Padova, Italia

Reconstruction Scenario Reproduce Detector Status at the moment of the interaction: ufront-end electronics signals (digis) ucalibrations ualignments Perform local reconstruction as a continuation of the front-end data reduction until objects detachable from the detectors are obtained Use these objects to perform global reconstruction and physics analysis of the Event Store & Retrieve results of computing intensive processes Software Architecture Vincenzo Innocente, CERN/EP CHEP 2000 7 -11 February, Padova, Italia

Components Reconstruction Algorithms Event Objects Physics Analysis modules Other services (detector objects, environmental data, parameters, etc) Legacy not-OO data (GEANT 3) The instances of these components require to be properly orchestrated to produce the results as specified by the user Software Architecture Vincenzo Innocente, CERN/EP CHEP 2000 7 -11 February, Padova, Italia

CARF CMS Analysis & Reconstruction Framework Physics modules Application Framework Reconstruction Algorithms Event Filter Physics Analysis Calibration Objects Data Monitoring Visualization Objects Event Objects Utility Toolkit LHC++ ODBMS Software Architecture Vincenzo Innocente, CERN/EP Geant 4 CLHEP PAW Successor C++ standard library Extension toolkit CHEP 2000 7 -11 February, Padova, Italia

Architecture structure An application framework CARF (CMS Analysis & Reconstruction Framework), customisable for each of the computing environments Physics software modules with clearly defined interfaces that can be plugged into the framework A service and utility Toolkit that can be used by any of the physics modules Nothing terribly new, but. . . Traditional architecture can not cope with LHC-collaboration complexity Software Architecture Vincenzo Innocente, CERN/EP CHEP 2000 7 -11 February, Padova, Italia

Problems with traditional architectures Traditional Framework schedules a-priori the sequence of operations required to bring a given task to completion Major management problems are produced by changes in the dependencies among the various operations u. Example 1: Reconstruction of track type T 1 requires only tracker hits Reconstruction of track type T 2 use calorimetric clusters as seeds If a user switches from T 1 to T 2 the framework should determine that calorimeter reconstruction should run first now u. Example 2: The global initialization sequence should be changed because, for one detector, some condition changes often than foreseen Software Architecture Vincenzo Innocente, CERN/EP CHEP 2000 7 -11 February, Padova, Italia

Framework Basic Dynamics Avoid monolithic structure Collection of loosely coupled mechanisms which implements in abstract the tasks of a HEP reconstruction and analysis software. Implicit Invocation Architecture No central ordering of actions, no explicit control of data flow: only implicit dependencies External dependencies managed through an Event Driven Notification to subscribers Internal dependencies through an Action on Demand mechanism Software Architecture Vincenzo Innocente, CERN/EP CHEP 2000 7 -11 February, Padova, Italia

Event Driven Notification Observers are instantiated by static factories residing in shared libraries. These are loaded on demand during Dispatcher application configuration Detector elements observe physics events Factories observe user requests Obs 1 Software Architecture Vincenzo Innocente, CERN/EP Obs 2 Obs 3 Obs 4 Observers clients or providers CHEP 2000 7 -11 February, Padova, Italia

Action on Demand Compare the results of two different track reconstruction algorithms Rec Hits Detector Element Hits Event Rec T 1 Calo. Cl T 2 Software Architecture Vincenzo Innocente, CERN/EP Rec Calo. Cl Rec T 2 Analysis CHEP 2000 7 -11 February, Padova, Italia

Reconstruction Object Model All persistent objects are managed by CARF. Physics Modules access them through standard C++ pointers Software Architecture Vincenzo Innocente, CERN/EP CHEP 2000 7 -11 February, Padova, Italia

Framework Main Services Define the events to be dispatched and link them to their actual source Allow the selection among available resources (user plug-in’s) Integration with the DBMS Transparent use of persistent objects in physics modules Manage the “not yet removed” sequential components (coming from legacy code & data) The combination of Implicit Invocation and Run-Time Dynamic Loading allows a CARF application to configure and build by itself Software Architecture Vincenzo Innocente, CERN/EP CHEP 2000 7 -11 February, Padova, Italia

Framework middle layer A given application specializes a certain set of generic CARF mechanism to provide specific services udispatch given events, loads specific libraries A middle layer implements generic clients to such specific services usimplified API uuniform detailed design uuniform use of ancillary services ushield developers and users from CARF technical implementations Requires synergy with detectors’ sub-systems Software Architecture Vincenzo Innocente, CERN/EP CHEP 2000 7 -11 February, Padova, Italia

CARF layered Structure Core mechanisms and “data structures” Simulation G 3 Raw Data Test. Beam H 2 Raw Data Generic Application T 9/X 5 Raw Data Generic Clients Software Architecture Vincenzo Innocente, CERN/EP CHEP 2000 7 -11 February, Padova, Italia

CARF in Production CMS Analysis&Reconstruction Framework is used in the present ORCA “functional prototype” usupports both detector and event reconstruction uprovides a fully integrated persistency services based on a commercial ODBMS (Objectivity/DB) uis being validated by several applications ranging from test-beam (Daq and analysis) to high level trigger studies (digitization, reconstruction, event selection) Software Architecture Vincenzo Innocente, CERN/EP CHEP 2000 7 -11 February, Padova, Italia

Conclusions Traditional software architectures (main&subroutines, pipes&filters) have been found not to be adequate to CMS (multiple environments, evolving requirements, a long time-scale) An “implicit invocation” architecture is a flexible software solution which can scale with the complexity of the CMS project. ODBMS, integrated into the framework, uprovides a coherent management of persistent objects ucoupled with run-time dynamic-loading, allows to automatically configure an application The framework can effectively shield physics modules from the underlying technology without penalizing performances Software Architecture Vincenzo Innocente, CERN/EP CHEP 2000 7 -11 February, Padova, Italia