RPC timing in simulation Current Situation MC Geant4 RPCSensitiveDetector.cxx Or RPCSensitiveDetectorCosmics.cxx RPC_Digitization RPC_digit_To_RDO RPC_RDO_To_Prep: RDO to Prep Ambiguity and overlap removal RPC Clusters RPCLV1Trig In cosmic replace Geant4 time and put TOF w.r.t. IP (almost) Not much difference between beam and cosmics (maybe see next slide) Beam: TOF w.r.t. IP Cosmic: TOF from surface + strip propagation time + BCtime ns jitter = t Subtract 50 ns for MC. in sim. added due to the convention that LVL1accept has BCID=2 Where? Pick-up earliest time RPC LV1 sim: input prepared as if all time offsets were compensated: all input times are 0 RPC_BS_To_RDO RDO Data if |t| digit

RPC timing in simulation Current Situation Consequences of current situation: - digit times are the physical times = tof (from IP) + propagation on strips + jitter --- shortcoming: if propagation on strips = 0 (hit very close to FE side) due to the gaussian smearing (sigma = 1.5 ns) the time can be < GEANT4 tof (unphysical); - all digits (i.e. all hits with | t |<70 ns) are seen “as in time” at the input of LVL1 logic - rdo times are the physical times + 50 ns (BCID of LVL1accept =2) --- in pile up LVL1 triggers whenever there’s a geometrical coincidence (for input provided [by the digitizer] in a time window of 140 ns) --- high unphysical lvl1 trigger rate in the barrel in simulations with pile-up + cavern bkg Solution: - the lvl1 logic emulation can handle time coincidences, when correctly configured (the full configuration is heavy, it will be done when conf. parameters as in the online will be accessible) - short term solution: require the time coincidence in a window of 25ns (loosest hardware condition)

RPC timing in simulation Fix proposal 1 allow LVL1 logic to apply a time window for the coincidence 25ns wide (sw already in place in nigtlies) in digit to rdo: have 2 conf. flags (useTofCorr = True/False, timeOffset = X ns) –the first one toggle on/off the subtruction of tof (computed for prompt muons) to the digit time (sw already in place in nightlies) when producing the input to the LVL1 logic that produces the RDO. –the second add a timeOffset (~<10ns) to compensate for times <0 (due to the current jitter implementation) in case useTofCorr=True (to be done)... is this really needed if LVL1 accept has BCid = 2 ? –in the production of RDO one can decide to set the rdo time equal to the one seen at input of the LVL1 simulation (tof subtracted+shifted) or leave the digit time. The same conf. flags need to be defined for TrigT1RPCLogic the algorithm that emulates LVL1 logic starting from input RDO (can run on MC or data) so that it can know how to work out the digit time (in the rdo -> digit conversion); NOTICE, it will need to behave differently with RDO newly produced (as described above) and with old RDO (which has time inclusive of tof): for old RDO the times at the input of the LVL1 logic will need to be set to 0 (as currently done, or tof subtracted), while for new RDO the times will need to stay unchanged; The global shift ??? does this need to be corrected (aren’t just time differences relevant ??) Slow particle studies on old(new) RDO will (not)need to subtract the muon tof to the rdo time; Anyway need to distinguish old / new rdo.

RPC timing in simulation Fix proposal 2 allow LVL1 logic to apply a time window for the coincidence 25ns wide (sw already in place in nigtlies) in digitizer: subtract tof and add small constant shift to avoid <0 times –digits do not keep any physical absolute info in their time –input to rdo formation and lvl1 logic is already emulating a time alignment of the system TrigT1RPCLogic the algorithm that emulates LVL1 logic starting from input RDO (can run on MC or data) will need to behave differently with RDO newly produced (as described above) and with old RDO (which has time inclusive of tof): for old RDO the times at the input of the LVL1 logic will need to be set to 0 (as currently done, or tof subtracted), while for new RDO the times will need to stay unchanged; The global shift ??? does this need to be corrected (aren’t just time differences relevant ??) Slow particle studies on old(new) RDO will (not)need to subtract the muon tof to the rdo time; Anyway need to distinguish old / new rdo.

A simpler schema digits: from physics (Geant4) + detector effects + FE effects (if any) digits -> rdo: produces the rdo by emulating the readout hardware (CM, PADS); introduce here time offsets and dead times as in the hardware configuration; –this RDO will (?) be equal to the real bytestream a part from the missing CM coincidence result (ijk=6,7) –this rdo will not keep physical time info in its own (unless the time is re-converted with hardware conf. parameters) apply the majority logic (within spatial and time programmed parameters) on top of this RDO –add to the RDO the trigger hits in the CM fragments