Transcript COMMISSIONING CON COSMICI DEGLI RPC DI ATLAS

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/2007
RPC converter
1/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-2003-018; Geneva : CERN, 27 Jun 2003 . - mult. p
4/9/2007
RPC converter
2/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/2007
RPC converter
3/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/2007
RPC converter
4/18
Understand what we have
•
•
•
•
•
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.
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
4/9/2007
RPC converter
5/18
in practice:
Current implementation
bytestreamPRD converter
example
const 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
activates the decoding
Region Selector
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
ROD fragment
}
Sector Logic
RPC byte-stream in
PAD fragment
ATL-COM-MUON-2003-018
fragment
(revised in 2006)
PAD fragment
PAD fragment
up to 8 PADs in a ROD
up to 8 CMs in a PAD
4/9/2007
CM fragment
CM fragment
RPC converter
optional/redundant
for debugging
purposes
6/18
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 => skip !
• meet fragments involving v1 => decode and record
•scan the ROD for v2 …
4/9/2007
RPC converter
7/18
online data
organization
vs offline
offline
data
collection
4/9/2007
RPC converter
8/18
> 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
4/9/2007
online data
organization
vs offline
offline data collections
RPC converter
9/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 ??
•
feasible ???
feasible ???
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…
4/9/2007
…
RPC converter
easy
and
probably the most
important point
10/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:
done in the
MC path to PRD
not in the
byte-stream to
PRD converter
simplicity – debugging – maintenance
4/9/2007
RPC converter
11/18
RPC Raw Data and Prep Raw Data
Offline: PrepRawData
On-line: RDO
We can not
forget this at
any levels.
4/9/2007
• 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
RPC converter
12/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/2007
RPC converter
13/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/2007
RPC converter
14/18
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 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
embed all that into an AlgTool
• 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
4/9/2007
RPC converter
15/18
More schematically
LIST OF data collection IDENTIFIERS
HLT applications or
offline selective mode
overall data request – empty list
Offline event
dump mode
RDO to PRD Tool
new
LIST OF PAD’S
new
Bytestream  RDO
TRANSIENT
EVENT
STORE
RDO
standard Converter
Data clean-up
PRD
existing logic
4/9/2007
RPC converter
16/18
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-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/2007
RPC converter
17/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
•
•
•
4/9/2007
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
RPC converter
18/18