4/9/2007RPC converter1/18 RPC bytestream converter: Brainstorming a summary of discussions involving M.Bianco, G.Cataldi, G.Chiodini, E.Gorini, A.Guida,

4/9/2007 RPC converter 1/18

RPC bytestream converter:Brainstorming

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


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 performanceIf leave we must leave for good!!!

Important ATLAS’s 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

http://cdsweb.cern.ch/search?f=author&p=Assamagan%2C+Ketevi+A





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


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)


Understand what we have

• 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:

1. Bytestream: get the list of data collections2. Data source organized in ROB’s (minimal data fragment provided by the data flow

system): scan the RODs that might contain those data collections

RPC example:running RpcPrepRawDataNtuple on • 1 event with hits in rod’s with Id 650004 and 650003• Converter (RpcPRDColROD_Decoder::

fillcollection) called 360 times: one time for each data collection potentially in the configured rods:6 rod’s for sector 5 and 6: 650003, 650004, 65005, 660003, 660004, 660005.


exampleconst Muon::RpcPrepDataContainer* rpcPrds = 0; StatusCode sc = p_EventStore->retrieve(rpcPrds, “RPC_Measurements”) RpcPrepDataContainer::const_iterator RPCcoll; for (std::vector<Identifier>::const_iterator idit = RPCids.begin(); idit != RPCids.end(); ++idit) { RPCcoll = rpcPrds->find(*idit); … } a list of data collections

from the Region Selectoractivates the decoding

void RpcPRDColROD_Decoder::fillCollection_v301(const std::vector<uint32_t>& 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}

in practice: Current implementation

ROD fragment

PAD fragmentPAD fragment

PAD fragment

CM fragment

CM fragment

optional/redundantfor debugging

purposes

Sector Logic fragment

up to 8 PADs in a ROD

up to 8 CMs in a PAD

RPC byte-stream in ATL-COM-MUON-2003-018

(revised in 2006)

bytestreamPRD converter


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 => skip !• meet fragments involving v1 => decode and record

•scan the ROD for v2 …

in practice: Current implementation


offline data collection

online data organization vs offline


offline data collections

> 3 Data collection data in a single PADoften 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

online data organization vs offline


Optimize what we haveRoom 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 schema3 Remove all printout in the data access loops4 …

…

easy and

probably the most important point

feasible ???

feasible ???


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 PRDnot in the byte-stream to PRD converter


RPC Raw Data and Prep Raw Data

On-line: RDO

Offline: PrepRawData

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


Current use of converters in the muon sw

• Milestone data processing: – bytestream to prep data Cnv for MDT

bytestreamRDOprep 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 MDTbytestreamRDOprep 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


How and why ?• RPC bytestreamRDOprep data i.e. running the offline

algorithm for RDOPRD conversion which, as first step, activates the converter bytestreamRDO– 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


The proposal for RPC• @ 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 offlineonline 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


More schematicallyLIST OF data collection IDENTIFIERS

RDO to PRD Tool new

LIST OF PAD’S new

Bytestream RDOstandard Converter

TRANSIENT EVENT STORE

RDO

PRDData clean-up existing logic

overall data request – empty list

HLT applications or offline selective mode

Offline event dump mode


The proposal for RPC• The scheme seems very close to ID data access

@ EF we don’t 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-streamRDO (copes with LVL2 latency!)– no more need for RPC Bytestream PrepRawData Cnv

• might be worth using the same scheme for all technologies – no direct bytestreamPRD for TGC and CSC at the moment


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 developer’s? • 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

Documents

4/9/2007RPC converter1/18 RPC bytestream converter: Brainstorming a summary of discussions involving M.Bianco, G.Cataldi, G.Chiodini, E.Gorini, A.Guida,