Use Of GAUDI framework in Online Environment DAQ Data Formats LHCb POW meeting June 2000 Beat Jost / Cern

Normal GAUDI Application Converter Application Manager Converter Converter TrEvent Store Data Files Data Files Message Service Persistency Service Event Data Service JobOptions Service Algorithm Data Files Data Files Detec. Data Service TrDetector Store Persistency Service Particle Prop. Service Data Files Other Services Data Files Histogram Service TrHistogram Store Persistency Service

Structure of Normal Gaudi Application Perm.Storage Persistency Services Transient Stores Services Algorithms

Online (L2/L3/Rec) Gaudi Application ECS “Persistency” Services “Data” Transient Stores Services Algorithms ?!?! DAQ

DAQ Architecture Switch (Functions as Readout Network) Storage ~100 RU SFC CPU ~10 CPC Controls Network Storage Controller(s) Controls System Storage/CDR Readout Network Technology ( GbE ?) Sub-Farm Network Technology (Ethernet) Controls Network SFC Sub-Farm Controller CPC Control PC CPU Work CPU Legend

Online GAUDI Application Converter DAQ ECS Application Manager Converter Converter Transient Event Store Message Service Persistency Service Event Data Service JobOptions Service Algorithm ECS ECS TDetector Store Detec. Data Service Persistency Service Particle Prop. Service Other Services THistogram Store Histogram Service Persistency Service ECS ECS

Problem No access to permanent storage from L2/3 Farm CPUs No “sophisticated” software available (Objectivity, ROOT, Oracle, etc.) -> very simple infrastructure Event Data will be generated by FE Electronics (simple data format) Data format might be different from the one stored permanently on disks after Level-3 Algorithms should not need to be modified whether they run ‘offline’ or ‘online’ -> put burden on persistency services (converters) ->re-implementation Work is needed for services which directly access permanent storage… These services have to be re-implemented

Raw Event Data Format (proposal) Bank1 Bank 2 Bank 3 Bank n

“Bank” Data Format (proposal) 4 Bytes 2x2 Bytes 8 Bytes overall size - 20 Bytes Size in Bytes (overall) Class Id (minor) Class Id (major) 20 Bytes Bank ID (ASCII?) Source ID Opaque Data (Physics Data)

Usage Size in Bytes (overall) Class Id (minor) Class Id (major) Used to hop through event Used to dispatch to the appropriate converter Bank Identifier (User defined) Source of the data (Det. Element) Size in Bytes (overall) Class Id (minor) Class Id (major) Bank ID (ASCII?) Source ID Opaque Data (Physics Data)

Sequence of Actions on Input On arrival of data block a Gaudi formatting algorithm is activated This algorithm hops through the raw event and calls the appropriate converters for each bank (guided by the major Class Id), passing a pointer to the beginning of the bank Each converter has to interpret the contents of the opaque data and generate in the event data store the objects expected by the algorithms. These object must have the same behavior as the corresponding objects from e.g. MC files, but might have different internal structure (e.g. Pointers to raw data instead of aggregating the data inside the object) Once all objects are created the trigger algorithms are activated This is the “All-at-Once” Scenario, where all raw banks are converted into transient store in one go (to be compared with “Conversion-on Demand”)

Program of Work Compare filling transient store at-once vs. on-demand Performance issues: data copying vs. using pointers preserving interface/behavior of objects Interaction of algorithms with condition services impact of condition changes on reconstruction results expected rate of significant changes periodic updates of conditions? Prototype implementations of some services, e.g. interfacing particle properties to ECS, interfacing Job-Options to ECS, interfacing Message service to ECS Study mechanism for output of raw and reconstructed data