RPC bytestream converter: Brainstorming

1
RPC bytestream converterBrainstorming

• a summary of discussions involving
• M.Bianco, G.Cataldi, G.Chiodini,
• E.Gorini, A.Guida, M.Primavera, S.Spagnolo,
• INFN Lecce Universita del Salento
• M.Biglietti INFN Universita di Napoli
• useful hints/guidance from A. DiMattia,
  S.Rosati
• Muon Week Nov-07

2
Why, where, how to go

• Our guide lines
• Understand what we have
• Optimize what we have
• Understand what we want
• Increase the functionality of what we have
• Reach the best performance
• If leave we must leave for good!!!

Important ATLASs note RAw Data Objects
Definition for the RPC chambers of the ATLASMuon
Spectrometer. Assamagan, Ketevi A Di Mattia,
A Elsing, M Grothe, M Nisati,A Rosati, S
Schörner-Sadenius, T Wengler, T
ATL-DAQ-2003-018 Geneva CERN, 27 Jun 2003 . -
mult. p
3
Summary

• Muon ByteStream Converters
• Why, where, and why to go
• Decoding robustness and Error detection
• RPC raw data and RPC prep raw data
• On-line hit (raw data) and offline (prep-raw
  data)
• Requirements
• Some considerations a proposal for RPC

4
Understand what we have

• for PRD (used by EF and offline)
  MuonByteStream/RpcPRDCollByteStreamCnv
• RpcPRDCollByteStreamTool (AlgTool)
• RpcPRDColROD_Decoder (AlgTool)
• for RDO (used at LVL2)
• RpcPadContByteStreamCnv RpcROD_Decoder.h
• MC path to PRD
• MuonCnv/MuonRDOToPrepData/RpcRdoToRpcPrepData
  (Algorithm access to full event)

5
Understand what we have

• RPC example
• running RpcPrepRawDataNtuple on
• 1 event with hits in rods with Id 650004 and
  650003
• Converter (RpcPRDColROD_Decoder
• fillcollection) called 360 times one time for
  each data collection potentially in the
  configured rods6 rods for sector 5 and 6
  650003, 650004, 65005, 660003, 660004, 660005.

• Algorithm driven ask the region selector for a
• eta-phi region of interest
• Region selector give the list of data
  collections identifiers
• Transients store hold already read data
  collections (due to other Algs)
• Data access
• Bytestream get the list of data collections
• Data source organized in ROBs (minimal data
  fragment provided by the data flow system) scan
  the RODs that might contain those data collections

6
in practice Current implementation
bytestream?PRD converter
void RpcPRDColROD_DecoderfillCollection_v301(con
st stdvectorltuint32_tgt p32, COLLECTION v,
const uint32_t sourceId ) const scan the
input ROD (p32) looking for the pad fragment
corresponding to a single requested data
collection (v) to be filled
RPC byte-stream in ATL-COM-MUON-2003-018
(revised in 2006)
up to 8 PADs in a ROD
up to 8 CMs in a PAD
7
in practice Current implementation

• ROD decoder scans sequentially the input ROD
• to record a PRD for each hit in the CM / PAD
  corresponding to the requested data collection
• to skip, otherwise
• every CM hit decoded into an interesting datum
  is recorded as soon as read-out
• no size of fragments is recorded in fragment
  headers, to allow skipping a block of data
• looking for a single requested data collection
  (v) to be filled
• suppose two data collections v1, v2 are actually
  needed (selected by the region selector)
• scan the ROD for V1
• meet fragments interesting for v2 gt skip !
• meet fragments involving v1 gt decode and record
• scan the ROD for v2

8
online data organization vs offline
offline data collection
9
online data organization vs offline
gt 3 Data collection data in a single PAD often
strips in high pT and low pT layers are read
by more than one pad
sometimes high pT and low pT data collections
requires reading and decoding more than one PAD
offline data collections
10
Optimize what we have

• Room for improvements
• skip un-interesting data (jump to footer)
  
• involves changes in data format
• scan ROD for v1 and v2 at the same time
  
• involves better logic changes in the base
• converter architecture ??
• Go through the code and clean it-up
• 1 avoid not useful loop
• 2 simplify the schema
• 3 Remove all printout in the data access loops
• 4

feasible ???
feasible ???
easy and probably the most important point
11
Requirements

• Good performance with all ATLAS ROD configured
• make sure the current scheme is effective when
  the whole detector data is requested
• Good data access performance
• Good event filter performance
• Clean Reconstruction/Analysis input data
  collections
• (see next slide)
• remove cabling overlap
• resolve wired-or and logical-or phi ambiguity
  with eta
• tag unsolved phi-ambiguity
• tag trigger hits
• No duplicated path simplicity debugging
  maintenance

done in the MC path to PRD not in the
byte-stream to PRD converter
12
RPC Raw Data and Prep Raw Data
Offline PrepRawData
On-line RDO

• on-line hits different from off-line hits
• h.w. duplicated hits due to cabling overlap
• s.w duplicated hits due to wired-or and
  logical-or
• 3 types of trigger hits in the readout

We can not forget this at any levels.
13
Current use of converters in the muon sw

• Milestone data processing
• bytestream to prep data Cnv for MDT
• bytestream?RDO?prep data for RPC, TGC
• Trigger LVL2
• bytestream to rdo converter (OK)
• Trigger EF
• for M5 online current and past technical run
  byte-stream to prep data Cnv for MDT
• bytestream?RDO?prep data for RPC, TGC, CSC
• (converting full event even when working in a
  region of interest)
• for rpc the reason is having clean RIO
  collections no redundancies/ambiguities

14
How and why ?

• RPC bytestream?RDO?prep data i.e. running the
  offline algorithm for RDO?PRD conversion which,
  as first step, activates the converter
  bytestream?RDO
• converting full event even when working in a
  region of interest
• inefficient
• the reason is having clean RPD collections no
  redundancies /ambiguities
• missing in byte-stream to RPD converter
• current byte-stream to prd converter does not
  solve overlaps/ambiguities because it scans
  sequentially the byte-stream and output a PRD for
  each relevant CM hit
• data clean-up requires to apply some logic on top
  of raw hits (which must necessarily be organized
  and stored in some format)
• the most natural and well tested format for that
  is the RDO

15
The proposal for RPC

• _at_ the EF, the algorithm (TrigMoore) requests rpc
  prd in a eta x phi region (RoI)
• get from the region selector a list of data
  collection id(offline) in the RoI
• get from cabling service (or related
  offline?online maps to be sorted out) the
  corresponding list of pad identifiers
• retrieve from StoreGate the pad container and
  find (i.e. decode into RDO) each pad in the
  selected list ? output is the RDO for the RoI
• i.e. just use the byte-stream to RDO converter
• convert the RDO into RPD by applying the data
  cleanup logic now in the offline algorithm for
  RDO ? PRD
• in the offline (re-use not duplicate code) MC and
  DATA
• RpcRdoToRpcPrepData might delegate all the work
  to the new AlgTool used over the whole event

embed all that into an AlgTool
16
More schematically
HLT applications or offline selective mode
LIST OF data collection IDENTIFIERS
overall data request empty list
Offline event dump mode
RDO to PRD Tool new
LIST OF PADS new
TRANSIENT EVENT STORE
Bytestream RDO standard Converter
RDO
Data clean-up existing logic
PRD
17
The proposal for RPC

• The scheme seems very close to ID data access _at_
  EF we dont expects objections from the HLT side
• allows to share logic (and implementation)
  between HLT and offline
• limit use of converters to the well optimized
  case of byte-stream?RDO (copes with LVL2
  latency!)
• no more need for RPC Bytestream ? PrepRawData
  Cnv
• might be worth using the same scheme for all
  technologies
• no direct bytestream?PRD for TGC and CSC at the
  moment

18
Decoding robustness and Error detection

• ROD fragment information
• Which information can be used to improve
  decoding robustness, performance, error detection
  
• There is room to ask to ROD Firmware developers?
  
• The strategy should be common for all
  technologies
• Error detection
• What you do when there is a error in the data
  format?
• Create a data error class for each technology
• Save error events in store gate