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

2. 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

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

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

5. 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

6. 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

7. 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

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

9. “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)

10. 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)

11. 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”)

12. 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