1 / 22

Performance Challenges in CMS Trigger System During LHC Run in 2012

The CMS experiment faced challenges in handling the increased luminosity and pileup during the LHC run in 2012. Multiple trigger algorithms were disabled to maintain efficiency. Improvements were made, such as suppressing muon rates and setting jet seed thresholds. The L1 trigger system was upgraded to include optical links for faster operations. Measures were taken to mitigate issues, like prefiring in the HF detector.

toby
Télécharger la présentation

Performance Challenges in CMS Trigger System During LHC Run in 2012

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. -90 kHz rate  Level-1 Triggerin2012 CMS run 201624 LHC Fill 2998 Manfred Jeitler HEPHY Vienna - 3% deadtime 

  2. challenges and performance in 2012 • LHC very successfully increased luminosity • up to almost 8e33 • PeakLumi = 7573.567×1030cm-2sec-1 • PeakPileup = 34.117 • in run 201624 (fill 2998) • cope with this without losing good data!

  3. challenges and performance in 2012 plot by Darin Acosta

  4. challenges and performance in 2012 more and more trigger algos must be disabled  ! (mapopripped) plot by Darin Acosta

  5. muon rate strongly suppressed... ...while keeping the efficiency • mainly by better pt assignment in CSC Track Finder • also by more sophisticated merging scheme in GMT • Global Muon Trigger • rate down by 50% • over full range • 30% for |η|<2.1 shown in plot

  6. calorimeter jet seed threshold • jet an especially HT rates are strongly pileup dependent • HT is ET summed over identified jets above (low) energy threshold • 10 GeV • overall illumination of calorimeter creates fake jets • cure: introduce threshold for jet “seed” • currently 5 GeV • must be done in GCT • Global Calorimeter Trigger, upstream of GT (Global Trigger) • outside of “Level-1 trigger menu” • very effective in reducing rates

  7. calorimeter jet seed threshold

  8. L1 trigger close to its present limit ...... but not at the end of its tether! • with LHC’s impressive progress we have had to also improve the trigger • by just raising thresholds we would be losing physics already • substantial improvements achieved this year • some more still be possible • but to profit from the LHC upgrade CMS also must upgrade the L1 trigger

  9. L1 upgrade stage zero:optical links between GCT and GT • fast galvanic serial links between GCT and GT had been a worry • no spares available, no data check possible • new electronic modules with optical links installed before 2012 run • “Optical PSB” (or “oGTI”) • learning experience for mostly optical connections in upgrade project • CRC check recently implemented • must be careful when touching a running system • due to misconfiguration calo monitoring data were not correctly read for some time • now fixed, everything working fine • don’t forget certain “features” such as GCT input masking!

  10. Sorry for keeping you waiting ... • ... but we know (now) that you enjoy your L1 trigger just as much if it’s served 12 BX later! • ... and it will taste better if cooked a bit longer!

  11. Why just-in-time delivery of L1A? • the upgraded trigger will be better than the present system • but not faster : • carry out more complex operations • collect and use more information for decision making • use of serial optical links allows using more information (higher bandwidth) and is less error prone (fewer cables that can break) but requires time for SERialization / DESerialization (SerDes)

  12. latency + 12 BX test • finding the maximum admissible latency is not trivial because: • Tracker and Preshower might become gradually inefficient at too high latency • can only be checked realistically with data • +12 BX on top of present (production) latency is theoretical maximum • at higher latency inefficiency must occur at some level • the test in June showed that +12 BX is safe! • took a full fill with this latency, data are OK • rolled back for production afterwards • we will certainly use this budget for the L1 Trigger upgrade

  13. L1 and BPTX • present CMS configuration relies on BPTX beam monitor being fully available all the time • have to tell collision bunches from gaps between: • for suppressing HF prefiring (see below) • for calculating the trigger dead time • for special checks (e.g., beamgas events in unpaired bunches) • this dependence is dangerous • as shown by a few (rare) hickups • other option: just use filling scheme published by LHC • also this is not always failsafe • ATLAS relied on it and lost some data

  14. BPTX : coping with the dependence • ideal: take LHC record and cross-check with BPTX before stable beams • cannot change after ramp • implementation in progress • in the meantime: have created special configuration key for running without BPTX • not ideal for data but reduced dependence • early warning system in case of BPTX problems • DQM plots developed to warn about problems already during LHC ramp • what about long-term maintenance of BRM / BPTX ? • small group • importance tends to be understimated by funding agencies

  15. HF Prefiring • prefiring of HF from particles hitting the photomultipliers directly • instead of creating scintillation light in the detector, as a well-behaved particle should • suppress now by vetoing bunch crossings before a collision crossing • this is why we need BPTX most badly! • “PreBPTX veto” • impossible in 25-ns running • for upcoming 25-ns test: will probably not use jet triggers • HF will replace all photomultipliers during LS1 • hope that this will fix the problem • if not: remove HF from single-object triggers

  16. forward physics: collaboration with TOTEM • CMS and TOTEM are two separate experiments with separate DAQ • might change over LS1 • but their triggers cooperate • CMS receives several bits from TOTEM over LVDS signals • some “Technical Trigger” bits, some used in Algorithms • TOTEM receives from CMS the L1A and some BGOs • via an unused “APVE output” • including BC0 (“bunch crossing zero”) and OC0 (“orbit counter reset”) •  can merge CMS and TOTEM data off line • several successful low-lumi runs taken jointly • CMS will use TOTEM’s “T2” for minimum-bias trigger in upcoming p-Pb test run

  17. where is TOTEM? Roman Pots 9.5 < η < 13 140 m, 220 m

  18. CMS Talking To TOTEM

  19. BCM1F for beam-gas veto? • last year’s beam gas problems prompted studies to reduce effect at Level-1 by using the “BCM1F” detector • fight beamgas-induced high trigger rate by veto signal • such events may be worse than normal events because of high Pixel occupancy • Previously Known as PKAMs • other idea: use HF asymmetry • beam gas much less of a problem in 2012 •  hard to study the veto performance • but also less important! • no conclusion yet if this approach will (have to) be used

  20. give me more ... backup slides

  21. physics triggers L1A @ BX=a BC0 L1A @ BX=a+m L1A @ BX=a+m+n

  22. calibration trigger BC0 calib @ BX=3490+m+n TEST ENABLE @ same BX as before calib @ BX=3490+m calib @ BX=3490

More Related