4/9/2007RPC converter1/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

4/9/2007RPC converter2/18 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 ATLAS’s note: RAw Data Objects Definition for the RPC chambers of the ATLAS Muon Spectrometer. Assamagan, Ketevi A; Di Mattia, A; Elsing, M; Grothe, M Nisati,A; Rosati, S; Schörner-Sadenius, T; Wengler, T ATL-DAQ ; Geneva : CERN, 27 Jun mult. p Assamagan, Ketevi ADi Mattia, AElsing, MGrothe, MNisati,ARosati, S Schörner-Sadenius, TWengler, T

4/9/2007RPC converter3/18 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/9/2007RPC converter4/18 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)

4/9/2007RPC converter5/18 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 collections 2.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 and 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: , , 65005, , ,

4/9/2007RPC converter6/18 example const Muon::RpcPrepDataContainer* rpcPrds = 0; StatusCode sc = p_EventStore->retrieve(rpcPrds, “RPC_Measurements”) RpcPrepDataContainer::const_iterator RPCcoll; for (std::vector ::const_iterator idit = RPCids.begin(); idit != RPCids.end(); ++idit) { RPCcoll = rpcPrds->find(*idit); … } a list of data collections from the Region Selector activates the decoding void RpcPRDColROD_Decoder::fillCollection_v301(const std::vector & 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 fragment CM fragment optional/redundant for 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 (revised in 2006) bytestream  PRD converter

4/9/2007RPC converter7/18 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

4/9/2007RPC converter8/18 offline data collection online data organization vs offline online data organization vs offline

4/9/2007RPC converter9/18 offline data collections > 3 Data collection data in a single PAD often strips in high p T and low p T layers are read by more than one pad > 3 Data collection data in a single PAD often strips in high p T and low p T layers are read by more than one pad sometimes high pT and low pT data collections requires reading and decoding 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 online data organization vs offline

4/9/2007RPC converter10/18 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 … … easy and probably the most important point easy and probably the most important point feasible ???

4/9/2007RPC converter11/18 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 done in the MC path to PRD not in the byte-stream to PRD converter

4/9/2007RPC converter12/18 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.

4/9/2007RPC converter13/18 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

4/9/2007RPC converter14/18 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

4/9/2007RPC converter15/18 The proposal for 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

4/9/2007RPC converter16/18 More schematically LIST OF data collection IDENTIFIERS RDO to PRD Tool new RDO to PRD Tool new LIST OF PAD’S new Bytestream  RDO standard Converter TRANSIENT EVENT STORE TRANSIENT EVENT STORE RDO PRD Data clean-up existing logic overall data request – empty list HLT applications or offline selective mode Offline event dump mode

4/9/2007RPC converter17/18 The proposal for RPC The scheme seems very close to ID data 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-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

4/9/2007RPC converter18/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 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