GAUDI Architecture

1
GAUDI Architecture

• SW Architecture SG meeting
• 22 July 1999
• P. Mato, CERN

2
GAUDI Scope

• We want to develop a Framework to be used in ALL
  the LHCb event data processing applications in
  all stages high level trigger, simulation,
  reconstruction, analysis.
• Control applications are not included (slow
  control, run control)
• The bulk of the LHCb data processing software
  will be developed by physicists.
• Components will be developed using other
  frameworks (GUI, object persistency, simulation,
  )

3
GAUDI Goals

• To develop a framework
• The framework should be customizable to provide
  solutions to the event data processing needs.
• It should
• Allow physicists to focus on solving the physics
  problem.
• Easy to use
• Non physics-related functionality implemented by
  the framework
• Ensure low coupling between concurrent
  developments.
• Guarantee a later smooth integration of
  developments.
• Facilitate software re-use

4
Software Structure
A series of data processing applications built on
top of the frameworks and implementing the
required physics algorithms.
Reconstruction
Simulation
High level triggers
Analysis
A series of Frameworks and Toolkits. One main
framework GAUDI, various specialized frameworks
visualization, persistency, interactivity,
simulation (Geant4), etc.
Frameworks Toolkits
A series of basic libraries widely used STL,
CLHEP, etc.
Foundation Libraries
5
Major design criteria

• Clear separation between data and algorithms
• Three basic types of data
• event data (data obtained from the particle
  collisions)
• detector data (structure, geometry, calibration,
  alignment, environmental parameters,..)
• statistical data (histograms, )
• Clear separation between persistent data and
  transient data.
• Isolation of users code.
• Different/incompatible optimization criteria.
• Transient as a bridge between various
  representations.

6
Major design criteria (2)

• Data store centered architectural style.
• Algorithms as data producers and consumers.
• User code encapsulated in few specific places
• Algorithms Physics code
• Converters Converting data objects into other
  representations
• All components with well defined interfaces and
  as generic as possible.
• Design principles
• Coupling, inheritance, static storage, ...

7
Building blocks
8
Interfaces
IDataProviderSvc
EventDataService
IAlgorithm
IProperty
IDataProviderSvc
DetectorDataService
IHistogramSvc
ConcreteAlgorithm
HistogramService
IMessageSvc
ObjectA
ObjectB
MessageService
Gaudi Application Framework
9
Algorithms

• Each Algorithm only knows what data (type and
  name) is expecting as input and creating as
  output.
• The only coupling is through the data.
• Scheduling of sub-algorithms is responsibility of
  the parent algorithm.

Data T1
Data T1
Real dataflow
Apparent dataflow
Transient Event Data Store
Algorithm A
Data T1
Data T2, T3
Algorithm B
Data T2
Data T4
A
Algorithm C
Data T3, T4
Parent
B
Data T5
C
Data T5
10
Services

• Services are provided to Algorithms
• Examples
• Job Options service (card files)
• Message reporting service
• Event/Detector/Histogram data service
• Event Selector
• Persistency and Conversion services
• User Interface (GUI)
• Particle property service
• ...

IService
IProperty
PP File
Particle Prop. Service
IParticlePropertySvc
Algorithm
Algorithm
11
Event Data Store
retrieveObject( EcalDigits,...)
Fetch() Store()
Event Data Service
registerObject( key,...)
Persistency Service
Algorithm
creates
Direct reference
Transient Event Store
12
Event Persistency
SicbCnvSvc
Transient Event Store
Sicb data Files
Sicb/Zebra
Converter
Event Data Service
Converter
Converter
Persistency Service
RootCnvSvc
Algorithm
Algorithm
Root data Files
Root I/O
Converter
Converter
Converter
OutputStream
AppManager
OutputStream
13
Detector Description
Editors
Editors
Data Processing Application
Algorithms
Algorithms
Projection view version event time
Persistent Detector Description (DDDB)
Transient detector store
Geom
Geom
DetElem
Geom
DetElem
DetElem
DetElem
Geom
Calib
Calib
DetElem
DetElem
Geom
Slow
DetElem
DetElem
Slow
DetElem
DetElem
DetElem
DetElem
Detector Data Producers
Conversion services
Conversion services
? Update persistency
Other representations
14
Data Visualization
Representations Store (graphical, textual)
Conversion Service
Converter
Converter
Converter
Converter
Transient Event/ Detector Store
Selector
User Interface

• Selects objects in store

15
Application Configuration

• What are the knobs at our disposal?
• JobOptions. Simple usage. It allows the end-user
  to overwrite any property of any algorithm or
  service.
• Algorithm/Service properties database. A more
  sophisticated way to modify the properties of the
  algorithms and services.
• Detector database edition to create new versions
  or releases.
• Write specific code. Configure your application
  by setting it at runtime.
• User interface component. Graphical (a la Visual
  Basic), command line (scripting language), etc.

16
Packages
GAUDI Framework
GaudiExam. (applications)
SicbCnv (converters)
RootCnv (converters)
LHCbAlg (algorithms)
DetCnv (converters)
RIO
Futio (SICB)
LHCbEvent (event model)
HbookCnv (converters)
DetDesc (detect. model)
CernLib
CLHEP
Gaudi (foundations)
STL
Package group
Package dependency
optional