Introduction
- The beam splash dump to P5 was foreseen to start the Friday 6th November 2009 in the afternoon and last until Monday morning 9th November 2009 with the schedule reported at https://twiki.cern.ch/twiki/bin/view/CMS/Splash2009.
- The first splash events were available (and recorded!) from Saturday evening at ~20.10
- 3 are the runs with splash events:
- 120015: lasted order 3 hours. FIRST BEAM OF 2009
- 120017: lasted only few mins
- 120020: lasted order ~10 hours
CSCTF Configuration
During the entire week-end CSCTF was configured with key 21109:
- 21109 (algo bit 54). BEAM2 configuration:
- Only ME+ is triggering.
- No singles.
- No halo delay.
- Only halo trigger on: the rate for cosmics is ~0.5 Hz.
- Capability to still monitor the CSCTF rate for the minus endcap.
During the late evening of Friday, while waiting for beam 2 to arrive, there was a trip in the turbines and CSC lost two crates: VMEp1/8 and VMEp1/9 which corresponds to sector 4 and the first 6 links. During the entire beam splash exercise we had these two crates masked at the CSCTF level and no data were provided by the respective chambers. More details
here.
A snapshot of the crates status is shown here:
CSC had the HV set to STANDBY, which combined with the halo rate only trigger setting was providing 0 rate during cosmics data taking. Thus,
if we fired events, this should have come from the BEAM SPLASH
Rate Response
During the beam splash runs, CSCTF was set to be the "backup" trigger. It means that the CSCTF was not sending the L1A and algo bit 54 (beam halo) was switched off at the GT. Ecal was the trigger defining the timing and only in case Ecal would have lost the event, CMS would have switched to use the CSCTF beam halo. Ecal performed perfectly so there was no need to use the beam halo. Nevertheless, CSCTF was recording rate from both endcap, allowing us to understand its performances.
- Snapshot of the total rate monitor from Friday night 7th November 2009:
- Snapshot of the rate monitor sector-by-sector:
Show RateSectorBySector Hide RateSectorBySector
- Snapshot of the rate monitors comparison between no beam splash and beam splash event recorded:
Show RateComparison Hide RateComparison
→ → → →
Interestingly enough the CSCTF did not trigger on all sectors at the same time from the counters.
Timing Results
Two are the timing studies to be carried on:
- The chamber-by-chamber results → these are reported on Joe's timing analysis twiki page
- Since the ecal trigger is used as baseline we can monitor how the CSCTF behaves w.r.t. ecal trigger by looking at the timing distributions. It was observed that the CSCTF on the downstream endcap (ME+ for beam 2) was early 1/2 bx while on the upstream endcap (ME- for beam 2) was early 2/3 bx. So between run 120015 and run 120020 the upstream endcap was delayed 2 bx (maximum delay allowed by modifying the TTCrx coarse delay). This can be visible in the time shift for the event recorded by the CSCTF for the minus endcap
Show CSCTFTrackTiming Hide CSCTFTrackTiming .
RUN 120015
RUN 120020
→
RUN 120015
RUN 120020
→
RUN 120015
RUN 120020
→
RUN 120015
RUN 120020
→
RUN 120015
RUN 120020
→
RUN 120015
RUN 120020
→
RUN 120015
RUN 120020
→
RUN 120015
RUN 120020
→
RUN 120015
RUN 120020
→
RUN 120015
RUN 120020
→
RUN 120015
RUN 120020
→
RUN 120015
RUN 120020
→
CSCTF Occupancy
Another series of plots to look at is the chamber occupancy during the run:
- Online DQM Occupancy Plot
Show CSCTFDQMOccupancy Hide CSCTFDQMOccupancy .
- OCCUPANCY PLOTS FROM ONLINE DQM:
RUN 120015
RUN 120020
→
During run 120015 it is visible the hole due to the lack of VMEp1/8 and VMEp1/9. During the nightly run 120020 a problem with the high voltage happened and it should have been responsible for the lack of data in the minus endcap. This lack is also confirmed by the CSC Summary plots. More details on the HV error occurred are here and here.
- Local TF DQM Occupancy Plot
Show CSCTFLocalDQMOccupancy Hide CSCTFLocalDQMOccupancy .
- OCCUPANCY PLOTS FROM LOCAL TF DQM:
RUN 120020 (ME+)
RUN 120020 (ME-)
→
It seems we are getting a strange pattern for the occupancy which is sort of confirmed by the CSC Summary plots, e.g. the segment distribution:
It is not clear to me the reason why, maybe it is due to the chamber decision making when the chambers is full of LCTs.
Interesting Links:
--
GianPieroDiGiovanni - 08-Nov-2009