1 / 5

RPC timing in simulation Current Situation

RPC timing in simulation Current Situation. Beam: TOF w.r.t. IP Cosmic: TOF from surface. Data. MC Geant4. In cosmic replace Geant4 time and put TOF w.r.t. IP (almost) Not much difference between beam and cosmics (maybe see next slide). RPCSensitiveDetector.cxx Or

siran
Download Presentation

RPC timing in simulation Current Situation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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)

  3. 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 15.0.0 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 15.0.0 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.

  4. 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 15.0.0 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.

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

More Related