From RPC RDO to Rpc Prep Data S

  • Slides: 8
Download presentation
From RPC RDO to Rpc. Prep. Data S. Spagnolo from discussions with G. Chiodini,

From RPC RDO to Rpc. Prep. Data S. Spagnolo from discussions with G. Chiodini, E. Gorini, S. Rosati, E. Moyse and others

Rpc RDO structure Online RPC data structure is trigger-driven quite different than offline data

Rpc RDO structure Online RPC data structure is trigger-driven quite different than offline data structure (i. e. collections of data corresponding to all rpc modules on one side [inner / outer] of a single station) Online structure is, roughly, PAD / CM (up to 8 in a PAD) / HIT (holds bcid, time, ijk, channel) – – channels corresponds to offline strip From Ijk and CMID one can derive gasgap, doublet. R, doublet. Z, doublet. Phi BUT the relation is not 1 to 1 (for hardware and readout-logic reasons) with the exception of strips in the pivot plane (doublet. R = 2) Examples: – – – phi strips of adjacent rpc modules (overlapping in z) on the same side of a station are HARD-WIRED; Phi strips of adjacent stations at same global R are in logic or in the readout electronics Signals from Phi and Eta strips are split and provide input to different trigger and readout electronics boxes

Rpc RDO structure Detailed description of raw data format in ATL-COM-MUON-2003 -018 / revised

Rpc RDO structure Detailed description of raw data format in ATL-COM-MUON-2003 -018 / revised in April 2006 Consequences in the conversion to offline format Given a CM Hit for a phi measurement, there’s a list of strips ( of offline identifiers) which might have produced that hit AMBIGUITY More than one CM contains a raw hit corresponding to a given fired strip duplicated hits (due to overlapping cabling/readout) Moreover: in an ideally calibrated detector, times read-out for different CM/channels corresponding to synchronous events would be the same Time alignment of different groups of channels in a CM, of different CMs, of different PADS, of different Sector. Logic is “the calibration” for the ATLAS RPC Finally: some CM hits do not correspond to fired strips, but rather keep trigger related information (ijk=6, 7 and ijk=0, 1 in high p. T CMs)

Conversion to Offline • Muon. Spectrometer/Muon. Cnv/Muon. Bytestream/ Rpc. PRDColl. Byte. Stream. Cnv. h

Conversion to Offline • Muon. Spectrometer/Muon. Cnv/Muon. Bytestream/ Rpc. PRDColl. Byte. Stream. Cnv. h + related tools – Converter – runs on demand on available data - intended for use on real data – It applies a pure conversion: a CM hit (also some trigger hits) is converted in as many Prep. Data as allowed (no ambiguity solution) – duplicated Prep. Data produced from the conversion of different raw hits are all kept – The result is a dump of the bytestream in offline format; – Very useful for low level detector and trigger-daq related studies • Muon. Spectrometer/Muon. Cnv/Muon. Rdo. To. Prep. Data/ Rpc. Rdo. To. Prep. Data. h – Algorithm – does not use the region selector mechanism – runs if activated from python – intended for MC data – reduces, if requested, the hit duplication – Solves, if requested, phi ambiguities selecting only the phi strips having a matching (in time) eta strip in the same rpc module

Conversion to Offline Rpc. Rdo. To. Prep. Data Job-opt-flags: – reduce. Cabling. Overlap –

Conversion to Offline Rpc. Rdo. To. Prep. Data Job-opt-flags: – reduce. Cabling. Overlap – allows to write only once a single Prep. Data (same offline ID) coming from different readout channels (matching in time: ideally Dt = 3 ns – RPC readout resolution – Dt can be set by jobopt for handling with the current un-calibrated data) – solve. Phi. Ambiguity – allows to choose the real phi strip(s) generating the hit among those (from 2 to 6) which might give rise to this raw hit (a hit in the rpc gas gap always produces both a phi and a eta hit; loss of any of them can arise only by inefficiency of the readout electronics look for a matching eta strip [in a time window : ideally Dt depends only on propagation time difference between eta and phi (15 ns max. ) – now miscalibration on top of that] • If no matching eta strip is found, all possible phi Prep. Data are produced (keep efficiency); need to keep track of this situation – Concerns about solving phi-ambiguities: if there’s eta readout inefficiency + eta noise in another rpc module, the algorithm can choose the wrong phi strip (second order effect)

Conversion to Offline Rpc. Rdo. To. Prep. Data Job-opt-flags: – processing. Data – a

Conversion to Offline Rpc. Rdo. To. Prep. Data Job-opt-flags: – processing. Data – a switch to know if processing MC or data needed for a mismatch in a coding of CMID between MC and data • decoding CMID should not be done in Rpc. Rdo. To. Prep. Data but on the Rpr. RDO_decoder via the Rpc. Cabling service – In the feature the switch will disappear – Delta T phi-eta coincidence – Delta T cabling overlap tolerance

Rpc Prep Raw Data • Hold offline identifier of the strip + time +

Rpc Prep Raw Data • Hold offline identifier of the strip + time + local/global coordinates • In addition, in the latest tag of Muon. Spectrometer/Muon. Rec. Event/Muon. Prep. Raw. Data – const int trigger. Info • 0 for all standard hits (corresponding to fired strips) • Ijk for trigger hits in low pt CMs • Ijk+100 for trigger hits and low pt pattern in high pt CMs – const int ambiguity. Flag • 0 if the algorithm/converter producing Rpc. Prep. Data does not solve phi ambiguities • N_possible_offline_strips if there's no eta strip matching any possible phi strip corresponding to this RDO hit • N, if N out of the N_possible_offline_strips have a matching eta strip

Conversion to Offline Rpc. Rdo. To. Prep. Data Has been working until now –

Conversion to Offline Rpc. Rdo. To. Prep. Data Has been working until now – for MC data by reducing overlap and solving phi ambiguities; – for cosmics data by Gabriele C. with some temporary patch A new tag in preparation with all the switches accessible by joboption in order to allow low-level detector/trigger studies with Prep. Data content similar to raw data; The proposal is to have the default Prep. Raw. Data with overlap and ambiguities removed for offline processing: pattern-recognition, fit, etc We should discuss the option of removing from the containers of Rpc. Prep. Raw the hit related to trigger info (otherwise clients have to test trigger. Info to check that it is 0) Migrating this logic to the Bytestream-Prep. Data converter ? ? ?