Outline

1. Outline • Reminders • The methods • Relative-timing • Absolute BXN analysis • What we had • New results • Re-visiting of halo data • Full processing of CRAFT (super-pointing) samples • Plans: towards collision synchronization UCLA meeting

2. Inter-chamber timing from track finder We make a measurement of relative chamber segment arrival time at the track finder, on a chamber by chamber basis. Analysis Method Input ΔBX between segments received in a single event Work out chamber offsets relative to a single reference Perform a global 2 minimization to find optimal chamber timing adjustments Feedback to CSC commissioning within a few hours Both endcap synchronized before CRUZETIII Plus endcap chambers synchronized before CRUZET II Minus endcap chambers synchronized shortly before CRUZET III Results and Notes publication page http://cms-csctf-sw.web.cern.ch/cms-csctfsw/timingresult/WelcomePage.html UCLA meeting 2

3. Synchronization with absolute BXN of halos • Methods • look at the absolute BXN of the recorded hits. • BXN recorded by the SP corrected by the relative BX in the SP readout. • BXN_LCT = BXN_SP + TIME_BIN_LCT – Const • For cosmics these histograms will be flat. For beam, there will be a spike in the BXN_LCT at the BXN corresponding to the filled bunch. • Fit these spikes, and compare to one reference chamber, this gives us the offset from the reference chamber. • Advantages: • This absolute BXN synchronization will make maximum use of every muon associated to the beam. • it complements well current approach of comparing one chamber with another. • A technique like this uses the advantages synchronous particles give us over cosmics. UCLA meeting

4. Inter- chamber synchronization:Re-visiting of halo data • What we had: • Results with based on the same methods of relative-timing • Synchronization with absolute BXN of halos • Agree quite well in the shape with relative timing, but the difference in scales was never understood • Both had cosmic bkg excluded • Translation from cosmic to collision timing • derived from both simulation/data results • But not fully verified due to the above problem • They didn’t have chance to be used and tested • See my talk on Sep. EMU meeting • turn to beam halo data can help to derive the timing for synchronous muons • Will help collision muons • What was it like(old results, with run62232, beam2): • Old Relative timing results: • http://cms-csctf-sw.web.cern.ch/cms-csctf-sw/timingresult/Run_62232.html • Old absolute BX results: • http://cms-csctf-sw.web.cern.ch/cms-csctf-sw/timingresult/AbsResults_62232.html UCLA meeting

5. Comparison of the results from the two methods(I) Relative-timing results TS#1 ME+ Results from LCT_BXN analysis UCLA meeting

6. Comparison of the results from the two methods(II) Relative-timing results TS#2 ME- Results from LCT_BXN analysis UCLA meeting

7. Revisit halo data: New results( next few slides) • Major changes: • Global data instead of local data • the absolute BXN was obtained from GMT. • Only events triggered by CSC halo trigger are used • Observation • the previous observed scale difference between absolute and relative timing method has disappeared. • the results from both methods have agreed quite well now. UCLA meeting

8. UCLA meeting

9. UCLA meeting

10. UCLA meeting

11. UCLA meeting

12. UCLA meeting

13. UCLA meeting

14. Discussion of new results of two method comparison • It verifies the method used, especially the relative-timing, which was suspected • More flexibilities for future: For data from synchronous source( halo and collision), we can still use the two methods simutanaously in most cases; we can choose only use one of them due to some contraints • Data sample is small absolute analysis only • More complex BXN patterns due to beam conditions relative analysis only UCLA meeting

15. Puzzles & questions • What is the relation between ME_BXN and BXN from GMT • BXN: local data vs gmt(gt) data • I see difference of ~100BX • BXN vs orbit behavavior mentioned in Ivan’s slides • Sliding cut: not favored for all the runs • not obvious in run62232 • For most other runs may not easy to define the selection. Difficult to distinguish, e.g. 62234 • Reason: Major statistics from capture attempts, rates of captured beam is very low, not so distinct from cosmic bkg • But feasible for two more runs. Still trying. UCLA meeting

16. RUN62232 RUN62384 After BXN selection No BXN selection UCLA meeting

17. Overview – B2 operations Response matrix measurements RF capture tests Tests with circulating beam UCLA meetingI. Mikulec I. Mikulec 17

18. BXN vs. Orbit Number: RUN62234 Not clear for sliding cut for similar cases UCLA meeting

19. Ideas and Plans • Halo synchronization to collision synchronization • This is an option no matter to implement a separate synch setting for halo or not • The procedures are similar • Analyse halo data . • Derive transformation constants from halo simulation and collision simulation • Apply the transformation • This provide additional means to cross check the predictions from cosmic results • If the predicted collision synch agree well, the probability of having well timed-in system for collisions is higher • Present cosmic to collision synchronization procedures • Old results • Next? UCLA meeting

20. Inter-chamber timing results: CRAFT • “Sin” like variations in ME2/1 and ME3/1 • More complex pattern in Ring2 • No clear pattern in ME1 rings ME+ ME+ ME- ME- UCLA meeting

21. UCLA meeting

22. Results from super-pointing samples • Purpose: • Superpointing tracks in bottom sectors resemble collision ones • Statistic is not a limiting factor any more • May provide more clues on the pattens observed with data of no selection • Status • A new sample comes, new job under running for ~10 days, hopefully to finish at the end of this week UCLA meeting

23. Revisit the translation from cosmic to halo synchronization: simulation vs data • 63371 has the same delay settings with 62232 • Previous simulation: • Beam1 • I find no beam2 sample UCLA meeting