Weekly update

1. Weekly update • First, a couple of nifty slides for LHCC • Then, update on my concerns from last week

2. Before Corrections After Corrections RMS ~7 ns CMSSW_3_8_0 Example usage: Collision Muons Incoming (beam 2) halo Beam 2 Direction CSC per-chamber times CSC: cathode strip timing improvements • TOF back to IP already subtracted (t=0) CSC per-muon times, at vertex [ns] σ ~ 3 ns CSC muon time [ns] Amanda Deisher, Piotr Traczyk

3. 1 CSC (6 hits) 3 CSC* * * Most due to triple-counting in 3:1 ganged strips in ME1/1 inner part 2 CSC * Most due to triple-counting in 3:1 ganged strips in ME1/1 inner part 4 CSC CSC muons in min bias events (data vs. Monte Carlo): Andy Kubik

4. Updates on concerns – this week • Trigger efficiency problems • L1 in CSC/DT overlap region may be on the mend “soon”: • See http://indico.cern.ch/conferenceDisplay.py?confId=88084 (work has progressed since) • eta [0.9-1.05] region: 1 bx added to ME1/3DTTF timing helped • Eta [1.05-1.2] CSCTF firmware bug found (even-quality DT stubs ignored) • Implementation of CSCTF firmware fixes is awaiting emulator fix-up and B904 testing and ICHEP data sample completion • Now HLT (L3?) efficiency is major concern, ~10% loss for CSC/DT overlap and CSC-only regions • May or may not be related to L1 CSCTF problems • Would be nice (but unlikely) to get L1 fixes put in earlier so can unambiguously address this problem…

5. Updates on concerns – this week Offline timing Amanda corrections going into CMSSW v3.8.0… Present performance: ~7 ns RMS/chamber, test beam shows 4 ns possible ~3 ns RMS/muon nonetheless a pretty good result - see the following from Piotr:

6. Updates on concerns – this week CSCs stopping CMS for up to 25% of fill DAQ modules FEDs aka DDU and DCC throwing error states via FMM / TTS system when lots of beam lost and they fill up. Monday 5 p.m. meeting to discuss solution(s) My notes:1. Immediate actions (already done): mask out CFEBs at DMB and TMB from 4 chambers that are throwing errors. Turn off beam halo trigger at the Global Trigger (does not affect CSC single station triggers, since not done internally in CSCTF).2. DDUs and DCCs have very little headroom for "almost full". Big events are 70Kb versus normal 1Kb. Headroom was only 4K or 8K, depending on the FIFO.  Firmware needs to be fixed to give more warning (warn at 50%?, buffers up to 1 Mb).3. It seems that full buffers should request a resync, not a hard reset. This needs to get sorted out carefully.4. Problem states sent to FMM do not match what is stored in the event readout (firmware bug). Fixing this will allow, at a minimum, better analysis of problematic situations.5. Firmware fixes should take a few days, then testing.6. Should repeat latency test – after firmware fixes have been done.  Somehow previous test did not work correctly. 7. When we have such problems, we need to be clearer about which of the 2 types of error conditions we are encountering: a) beam losses causing buffer overflows (FMM directly notified, usec time scale), or b) accumulation of >=9 chambers with errors (software recognizes and writes VME to set FMM error, msec time scale).8. Central DAQ shifter response currently “voodoo”, suggested hard reset doesn’t work, so some semi-random sequence of hard resets, pause, resync, resume employed…careful attention in the future could improve.9. DAQ error logs were being kept "for a few days", now will be kept "forever".10. After new firmware arrives and is working, it may make sense to unmask the 4 problem CFEBs and see whether problems recur, because it isn't clear why masking them has helped the situation recently (given point 7).

7. Updates on concerns – this week CSC Validation “broken”? Express stream okay Other streams (mu, min bias, cosmics) problem in pointing back from RECO to RAW data files, DBS “parentage” problem that datasets don’t have parents, but data blocks, runs, or files do. Should be simple to fix (Andy). Upgrade ME4/2 discussions: Details on panel procurement – need to add specs for roughness, composition of copper Procurement details: to be understood, worked out with CMS financial office

8. Improvements from others Update on CSC Track Finder: (same) Firmware: the f of singles wrong by up to 1.0 causes problems for dimuons (ghosting) and for studies (need to match to offline mu’s) Firmware: Pt of singles to lower 144  3 GeV/c (minimum) Software: emulation to be fixed for single station “singles” muons (new) Communications: CSCTF control computer loses connection – CAEN crate controller or PCI card? Multi-forking of software processes? CSCTF timing efficiency 99.3% even with very good LCT timing: will happen with singles, or 2-station muons if faulty timing is on late side (BX analyzer takes later LCTs) Look into asymmetric timing – prefer early LCTs to late ones

9. Backup slides

10. (From last week) concerns CSC improvements to be made Branch point when ICHEP conference data sample is finalized Special runs at higher luminosity Another timing scan A neutron rate measurement run Upgrade, especially ME4/2 Getting the project rolling Funding in FY11 is a particular issue Understanding timing constants Muon triggers and datasets Papers, documentation, tracking

11. Improvements to be made >ICHEP Branch point when ICHEP conference data sample is finalized (~14 July?) L becomes “low” for the following data set, and people should be more accepting of improvements and special runs Specific improvements by us: TMB firmware fixes: Priority order in assigning LCTs to L1As (6/8/2010) Bug fixes – duplicate events (6/22/2010) ALCT reduce time bins from 16 to reduce data size? CLCT muonic timing? Predictions – need to bring back up old timing constants program Per-chamber AFEB timing adjustments (when we get ‘em from timing scan runs)

12. From muon HLT meeting 25-July-2010 • Jindal “JetMET and tau triggered data samples”, Pt>15 GeV • See http://indico.cern.ch/conferenceDisplay.py?confId=88084 • Note: low-Pt samples “tag-and-probe” show no such effect.

13. Special runs at high luminosity • Another set of timing scan runs • Previously allowed corrections in ME1/1 and by Peripheral Crate • Would like high enough luminosity to do (almost) all chambers • Need to know relevant cross-section for muon(-like) segments per chamber for each chamber type • Muon trigger okay (L too high for min bias) • But must correct offline if GT sees trigger came early or late compared to expected crossing bx • Previously ~30K min bias/point in ~20 minutes, now ~1 sec at L=5x1030

14. Special runs at high luminosity • Neutron hit background info.: • A potentially serious background at high luminosity, and rate estimates are uncertain to factors of ~3 (possibly more) • Neutrons bounce around the cavern, can knock on protons • Some such hits penetrate multiple chamber layers • Simulation: hits come up to ~ms after collisions • At 1034 luminosity, several hits per chamber per bx • March: idea developed how to measure the rate: • Want 1-layer ALCT*CLCT for CSC readout, but no CSC trigger • Intrinsic radioactivity of chambers is our “background rate” • Special no-collision cosmic ray run was taken for “baseline” measurement of radioactivity • Date, run number? • … nobody looked at it yet?

15. log(n-hits) time Prompt triggers “delayed” random triggers Neutron rate scan • New conception: • Allow all non-muon triggers (avoid DT or RPC triggers that include beam halo, cosmics, weird angle muon hits) • Min bias is good for in-time part of the neutron rate • Take a high rate of random triggers too for delayed part • Measure “prompt” as well as delayed neutron hits:

16. Neutron run • Previously calculated L=4x1030 to get 0.2 CSC hits/readout, equal to radioactivity rate • 1 M events (1-3 hours?) allows 200K extra hits above 200K background • Can try to measure by chamber type, rapidity, etc. • Radioactivity rates scale with chamber area, neutron rates won’t • Might see some increase esp. in inner chambers even with current 0.5x1030 luminosity… higher L=better S/N. • Let’s try to do it ASAP after ICHEP data sample defined. • Analyze the CSC #hits data – who?

17. Upgrade, especially ME4/2 • Panel purchase by August? • Vendor qualification, buying thru CERN, cost limit  option for 2nd half?, etc. • FY11: • Follow-on machining of panels • B904 occupancy date  shipping tooling to CERN • Factory preparation, prototype construction, personnel • ME1/1 electronics • First prototype by September (not TMB compatible) • (TAMU) Issue with Xilinx PROMs – new ones no JTAG • TMB upgrade firmware for V6… (V7 just announced)

18. Understanding timing constants • …CFEB readout timing constants • …CLCT muonic timing coming up • Need to fire up my old timing program, improved by Chad & Chris? 

19. CSC muon triggers and datasets • Where do all of these go? • Single high-Pt triggers and datasets • Onia triggers and datasets • Single low-Pt (e.g. b physics) triggers and datasets • Halo muons • CSC activity triggers • Everyone sees a “piece” of the puzzle… • Would like to assemble known information… • Are we missing anything? • Need to improve DIGI information on timing, e.g. CSC anode timing?

20. Papers, documentation, tracking • Common muon detector performance paper by end of year • Might naturally break into 3 papers, but preferably not • Should start pushing on it • Tracking of firmware versions • CSC synchronization paper? Internal note? Twiki?