1. Sundry LHC Machine Development starts 19 June –Original plan to have 90m comm. next week was torpedoed by private discussions between spokesperson and CMS D.G… –This means that proton data up to 18 June may be able to be used for ICHEP conference Turbine serving 2 CSC peripheral crates broke last night –“Although there was no beam in LHC it was not possible to organize an access during the night to change the turbine, indicating once more that our manpower with permission to intervene on electrical installations is not sufficient.” XEB report from Tech. Coord. –Impact: today’s fill 2725 ran with 18 chambers in CSC not operational (9 in VME–2/6 and 9 in VME–3/6 (~110/pb) –Access currently underway to replace this turbine –Misha and Armando (and I) are not happy 12 June 2012G. Rakness (UCLA)1

2. Pop quiz: can you see the problem? 12 June 2012G. Rakness (UCLA)2

3. Next topic… organization of a test an increase of L1A latency Motivation: CMS L1 trigger hardware will require upgrades in order to handle the ever increasing luminosity –Updated hardware to be installed already in LS1 –(One place that has been pointed out to me as particularly needful is DTTF) Because any upgrade of trigger hardware has the potential to increase the L1A latency, need to understand the implications on CMS data taking –Do this now so that development can proceed 12 June 2012G. Rakness (UCLA)3

4. Developing the plan 26 March: +5bx test? Run Meeting dedicated to discussions of latency test identified ECAL Preshower (ES) as a possible limitation –https://indico.cern.ch/conferenceDisplay.py?confId=183428https://indico.cern.ch/conferenceDisplay.py?confId=183428 –Subsequent discussions indicated that the Tracker might be protecting the ES? So… is Tracker the limiting factor? Trigger meetings: +10bx test? –Now Wesley knows about the ES-Tracker situation. He pushes the issue… Discussions: Dave Barney realizes we can quantitatively determine the limitations of Tracker + ES using random L1As at high rate (w/o beam) –Possible limitation: the period of the pseudo-random number generator in the GT would limit the scope of this test once we hit the “wraparound point” –Idea: use CSC single-layer trigger as a source of truly random triggers 11 June Run Meeting and 12 June XEB meeting: plan converged –https://indico.cern.ch/conferenceDisplay.py?confId=195104https://indico.cern.ch/conferenceDisplay.py?confId=195104 –Details in backup slides 12 June 2012G. Rakness (UCLA)4

5. In broad brushes June Machine Development (MD): determine the latency limitations in ES + Tracker –Determine where the “ES + Tracker wall” is. Back off by a bit. This is the max. latency increase we know we can safely run with –Meeting today with ES, Tracker, & Trigger experts on what to do June Technical Stop (TS): Increase L1A latency by +N bx at GT, increase readout latency by +N bx for all subsystems –“N” determined from MD test –Confirm settings in all detectors are OK with cosmics during TS After taking some collision data: roll back to current timing At any point in the above, if we see a problem, we roll back. Subsystems will have to monitor what they see at each step… 12 June 2012G. Rakness (UCLA)5

6. Q: when to roll back? We need to run with some collisions to confirm that all subsystems can run with increased latency –Natural time to do this is just after the Technical Stop Recall: LHC slowly increases the number of bunches in the machine after a Technical Stop –Recall April plan: 1 fill of ~6 hr w/84b, 480b, 840b, 1380b… but they had a few problems and had to run w/1092 for a few fills To remove (most of the) questions about the effectiveness of this latency test, I claim we should run with the highest possible luminosity and trigger rates –This means we should keep the increased latency until after the first 1380x1380 (good fill) during the ramp-up after the TS –After a bit of discussion, the XEB was happy with this (including Wesley, Darin, Dave, Tiziano, Joao…) 12 June 2012G. Rakness (UCLA)6 See next page…

7. Luminosity during the fills after the April Technical Stop Q: How much data do we collect during the ramp-up? 12 June 2012G. Rakness (UCLA)7 Total lumi delivered before reaching a good 1380x1380 fill = 487.6/pb Total lumi delivered before reaching a good 1380x1380 fill (if all went perfect) = 280/pb

8. To do Run Coordination –Finish overhauled shift leader checklist –Make sure global runs are in LS1 schedule –Go over downtimes in recent running. Anything we can do globally to address or reduce them? CSC –Put firmware into SVN –Document ALCT/CLCT muonic timing –RAT firmware loading As well… –Make neutron skims 12 June 2012G. Rakness (UCLA)8

9. Backup slides 12 June 2012G. Rakness (UCLA)9

10. More detailed plan (MD) Meeting held between ES, Tracker, GT experts on Tuesday 12 June to sort out the details of these tests Tues 19 June: understand the functioning of ES front-end –Need: ES, DAQ, GT (random L1As from GT are OK for this test) Wed 20 June: measure ES pipeline overflow probability vs. latency –For this test, we will determine where we hit the wall… –Need: ES, GT, DAQ, CSC (to provide truly random triggers at 100kHz) Thur 21 June: Test that Tracker protects ES. Determine L1A latency limitations governed by the Tracker. –For this test, we will determine where we hit the wall… –Need: Tracker, ES, GT, DAQ, CSC Friday 22 June: Based on the above tests, experts in ES, Tracker, and Trigger determine and propose a latency shift for the rest of CMS to test –This value will be sufficiently away from the wall as to make sense 12 June 2012G. Rakness (UCLA)10

11. More detailed plan (TS) Mon-Tues 25-26 June (first night of Technical Stop): Cosmics overnight with +N bx –Our understanding is that timing can be determined to be OK to ~bx precision with an overnight cosmic run –This does not mean you cannot do other things. It just means you should be ready to prove that +N bx is OK for cosmic rays Tues 26 June: Subsystems report on latency with cosmics –Can report at 9:30 daily meeting Overnights during Technical Stop: Cosmic run overnight with +N bx –Subsystems continue to work until the latency is right At some point after some collision data: roll back all subsystems and GT to present latency –Hopefully this is “easy” 12 June 2012G. Rakness (UCLA)11