Gaudi and Brunel

1. Gaudi and Brunel Selected features Not a user guide Not a wish list VELO software meeting, Liverpool, 5th July 2001

2. Converter Converter Application Manager Converter Event Selector Transient Event Store Data Files Message Service Persistency Service Event Data Service JobOptions Service Algorithm Algorithm Algorithm Data Files Transient Detector Store Particle Prop. Service Persistency Service Detec. Data Service Other Services Data Files Transient Histogram Store Persistency Service Histogram Service GAUDI Architecture: Object Diagram

3. GAUDI Architecture: Design Criteria • Clear separation between data and algorithms • Three basic types of data: event, detector, statistics • Clear separation between persistent and transient data • User code encapsulated in few specific places: algorithms and converters • All components with well defined interfaces and as generic as possible

4. Definition of Terms • Algorithm • Atomic data processing unit (visible & controlled by framework) • Data Object • Atomic data unit (visible and managed by transient data store) • Transient Data Store • Central service and repository for data objects (data location, life cycle, load on demand, …) • Services • Globally available software components providing framework functionality • Data Converter • Provides explicit/implicit conversion from/to persistent data format to/from transient data • Properties • Control and data parameters for Algorithms and Services

5. Algorithm Scheduling Data T1 Data T1 Transient Event Data Store Data T1 Algorithm A Data T2, T3 Data T2 Algorithm B Data T4 Data T3, T4 Algorithm C Apparent dataflow Data T5 Real dataflow Data T5

6. Data flow features • Each algorithm is a “black box” • Knows only about data it needs as input and data it produces • Does not know about any other algorithms • Except sub-algorithms that it creates and steers internally • Algorithms may not modify data already on the data store • Because they do not know who else may be using it or pointing to it • New data can reference existing data, but not vice-versa • Uni-directional links: tracks can point to clusters, clusters can point to MC hits, MC hits can point to MC Particles • Algorithms may create new data objects • And modify them at will • But only until they declare them to the store • At that point they have “published” the data and relinquished ownership • Delete of published data is done by the data store at the end of the event • Only put on the data store what you wish to publish to other algorithms • The sequencing of algorithms is done when configuring an application (e.g. Brunel) • To ensure availability of input data • Implies well designed data model with minimal dependencies

7. Gaudi transient event store ZEBRA common (SICB banks) Sicb back Converter Sicb back Converter SICB DST SICB rawh OO DST XML geom. BRUNEL structure CDF files Digitisation A Reconstruct B Trigger C Zebra Input Zebra Output Sicb Converters Sicb Converters Digitisation B Trigger D Reconstruct A OO Output

8. Program structure • Brunel phases ApplicationMgr.TopAlg = { "BrunelInitialisation/BrunelInit", "BrunelPhase/BrunelDigi", "BrunelPhase/BrunelTrigger", "BrunelPhase/BrunelReco", "BrunelPhase/BrunelFinalFit", "BrunelFinalisation/BrunelFinish" }; • Phases executed in sequence • Could be executed independently if intermediate data saved • Declare sub-systems participating to a phase BrunelDigi.DetectorList = { "VELO" , "OT" , "IT" , "RICH" , "CALO", "MUON" }; • Creates a Gaudi “sequence” per sub-system • Populate each sequence with algorithms: BrunelDigiVELOSeq.Members = { "BrunelDigiVELO" }; • Sequences and algorithms executed in declaration order • Data exchanged via Event Data Store VDDIGI()

9. Transient Event Data ModelStructure and Glossary • Reflects current understanding of processing phases • Not cast in stone! • /EventEvent header • /Event/MC • MC Event: Output of the event generator step. • e.g. MCParticles and MCVertices • MC Hits: Output of the GEANT tracking step. • e.g. detector entrance and exit point, energy loss etc. • /Event/FESimulated output of the detector front end, • as seen by the hardware triggers, when different from Raw data. • /Event/RawOutput of the digitisation step of the detector simulation, Output of the data acquisition system for real data. • e.g. ADC and TDC counts (VELO clusters?). • /Event/Rec • Coordinates: Output of reconstruction program when applied to detector hits. • Including alignment and calibration corrections • e.g. hit coordinates, calorimeter clusters etc. (is there a better name?) • Reconstructed data: Final output of the reconstruction program. • e.g. tracks, particle ID, energy flow objects etc. • /Event/PhysPhysics data: output of analysis steps • Some of which could be done in same job as reconstruction • e.g. particle candidates

10. Pileup and Spillover events • Pileup: • several events from same beam crossing • Implemented at generator level • Spillover: • events from previous or subsequent beam crossing • Combination must preserve 25ns timing offset • Digitisation must know what to do with hits that are 25nd early/late • Sub-detector specific • Implemented in Brunel • Sub-detector digitisation uses it if it wishes Transient Event Data EventSelector /Event /MC /Next/MC SpilloverSelector /NextNext/MC xxDigi /Prev/MC /PrevPrev/MC /Raw /Rec

11. Brunel Processing Phases • Digitisation • Takes GEANT hits (SICB RAWH), converts to Digits (ADC counts, TDC counts) • Includes detector and electronics response • Output equivalent to DAQ output • Could eventually be moved to simulation program • Each sub-detector processed independently in any order • Trigger • Applies trigger decision • Input is implementation dependent • Simulated trigger electronics output (L0) • Digitisation output (L2,L3, super-L1?) • Output of previous trigger levels • Output is yes/no decision • And optionally ‘reconstructed objects’ to be saved with DST

12. Reconstruction • Takes ‘Raw’ data as input and produces ‘Rec’ (or ESD) output • Done in two (or more) steps • Standalone reconstruction • Does not require any input from other detectors • e.g. VELO standalone tracking • Combined reconstruction • Uses input from other detectors • e.g. Downstream tracking • Several iterations possible (more phases) • Final fit • Assemble all detector info for final best fit • E.g. refit of positively identified electrons • E.g. refit of best particle ID

13. Brunel+Gaudi Conventionshttp://cern.ch/lhcb-comp/Support/Conventions/ • Conventions needed for: • Uniformity • Maintainability • Conventions on: • Coding rules • See http://weblib.cern.ch/abstract?LHCb-2001-054@LHBLHB • Program structure (packaging, job options) • /options sub-directory in each package • One file per algorithm (filetype .opts), with sensible default options • One file Brunel.opts per package • Declares DLL to ApplicationMgr • Adds algorithms to Brunel sequence • Includes algorithm options files • Physical Units • Event Data Model • Access to MonteCarlo truth

14. Physical Units • All quantities in Gaudi data stores conform to the CLHEP system of units. • All dimensioned quantities are defined by multiplying by the units in CLHEP/Units/SystemOfUnits.h: • Output of dimensioned quantities is converted to the required units by dividing by the units in CLHEP/Units/SystemOfUnits.h • Physical constants should not be defined in LHCb code. They should be taken directly from CLHEP/Units/PhysicalConstants.h const double my_height = 170*cm; // = 1700 const double my_weight = 75*kg; // = 4.68e+26 my_hist = histoSvc()->book( "diet/1", "corpulence (kg/m**2)",30,10.,40.);double my_corpulence = my_weight / (my_height*my_height);my_hist->fill( my_corpulence/(kg/m2), 1. ); float my_rest_energy = my_weight * c_squared;

15. MCCalo SummedDeposit MCCalo Deposit MCParticle CaloDigit Attributes Attributes Attributes Attributes Operations Operations Operations Operations MCCaloDigit 1 1 1..N Event Data ModelRelationship between Raw data and MC Hits • Implemented by inheritance: • N.B. MC class has same name as real data class, prefixed by ‘MC’

16. TrMeasurement MCParticle TrTrack 2..N MCTrackingHit OTDigi TrTrackMCParticleAssociator 1 Attributes Attributes Attributes Attributes Attributes Operations Operations Operations Operations Operations MCHitBase MCOTDigi OTHit 1 1 Event Data ModelGeneric relationship between reconstructed data and MC Hits • No other explicit links between reconstructed data and MC truth • Navigation always by associator tool in dedicated monitor algorithms

17. Brunel Plans • By the end of this year: • OO MiniDST • Content being defined by physics analysis requirements • May contain information not available on SICBDST • L0 trigger, Calorimeter, Tracking fully C++ • “Quick and dirty implementation” • RICH and MUON designs ready • VELO also? • What is scope of VELO reconstruction? • Feasible to have a complete C++ reconstruction by mid-2002 • Starting from SICBMC RAWH tapes • Independent of SICB geometry • With increased functionality relative to SICBDST

18. VELO Design issues • Identify functionality • Trigger, Vertexing, downstream tracking, upstream tracking… • Alignment • Test beam? • Treat algorithms as black boxes • “Easy” to (re-)implement • Quick and dirty implementation better than no implementation • Iterative development • Concentrate design effort on the data models • Cannot expect to get it right first time • But should be relatively stable • Event data • First attempt by Bruce Hay, based on SICB model • Does it satisfy functional requirements? • Detector description • What questions should it answer? • Alignment strategies • Critical item for VELO • Not at all defined

19. Conclusions • Iterative software development • Concentrate on the basic infrastructure • Worry about details later • Modular approach • Well defined job for each algorithm • With well defined inputs and outputs • Allows sequencing, and gradual replacement of components • Leave the past behind • Do not let SICB data model and structure influence new design • Collaboration • What exists in Gaudi/Brunel now is • Best guess at requirements • Defined by existing users • VELO requirements may be (probably are) different • Nothing is cast in stone • Involve other groups in design effort • Gaudi team, Tracking, Trigger, Physics ...