1. Scheduling of Experiments Christine Clarke, 10 th October 2012 FACET User Meeting

2. 2012 Schedule -- FACET User Run 1

3. 3 Shift Schedules https://slacportal.slac.stanford.edu/sites/ard_public/facet/user/Pages/Schedule.aspx Weekly pattern: Wednesday was an Access Day (PAMM) - When LCLS access (every other Wednesday), FACET beam needs to turn off Thursday was Machine Development - MD is a great buffer between PAMM and User shifts 5 remaining days for experiments Later in run, Friday morning became MD time too - MD time was extremely beneficial to delivering good beam

4. 4 Part 1A Schedule Starting Date [Wed] Run Wee k WednesdayThursdayFridaySaturdaySundayMondayTuesdayEnd Date [Tues] 4/11/2012O1CommissioningMD 4/17/2012 D PAMM Recovery S PAMM Recovery E-203 (4 hr) 4/18/2012O2E-203T-501 (2hr)T-501 4/24/2012 D MD S 4/25/2012O3 MDE-2005/1/2012 D PAMM E-202 S PAMM Recovery 5/2/2012O4 MD E-202 5/8/2012 D PAMM E-201/E-205 S PAMM Recovery 5/9/2012O5 MD E-202 5/15/2012 D PAMM E-200 S PAMM Recovery 5/16/2012 O6 MD E-202 5/22/2012 S PAMM E-201/E-205 D PAMM Recovery https://slacportal.slac.stanford.edu/sites/ard_public/facet/user/Pages/Schedule.aspx Experiment “groups” Experiments were grouped together so they could cover 24 hours a day for five days straight - Group A - Group A: E-203 (Smith-Purcell), E-206 (THz), T-501 (CERN BBA) - Group B - Group B: E-201 (DWF), E-205 (Euclid/energy chirp), E-207 (2-channel dielectric), E-204 (Metallic Structures) - Group C - Group C: E-200 (PWFA) - Group D - Group D: E-202 (Ultrafast EM Switching) – one shift/week due to sample change- over constraints

5. 5 Issues… Group A: Grouping allowed 24 hour coverage but incurred many config changes This group lost a week due to power outage With single shifts, some experiments in this group were unfairly penalised by lack of owl shift accelerator physicist Group B: Smaller groups dependent on larger group (E-201) for commissioning hardware E-205 and E-207 didn’t get beam time - How do we transfer knowledge between Group B groups? A real strain on a few key players in E-201 Group C: No unique issues? Group D: Frequent rescheduling of the single shift based on condition of machine and plans of other groups.

6. 6 Most common complaint: No time to think! Access day too rushed Too little time between weeks on shift - Can’t engineer good solutions - Can’t solve what is going wrong

7. 7 Beam time allocation 2012 Aim was to give PWFA ~50% of beam-time, group B ~30% and group C+D ~20% Similar to beam request (time requested PWFA > time requested group B > time requested group C+D) Perceived to be in line with FACET’s goals Given relative sizes of the groups, this was what the personnel could support

8. Future Schedule -- FACET User Run 2 and beyond

9. 9 Proposal 1.1 – Moving PAMM As proposed in User Brown Bag in June… PAMM one day a week (User’s suggested Tuesday) But there aren’t enough Operators on a Tuesday to regularly support the search and subsequent recovery Large experiments given a block 3 or 5 days Preceded by ~2 days PAMM recovery, POMM and MD time Note set-up time can be longer if next experiment requires it Starting Date [Wed] WednesdayThursdayFridaySaturdaySundayMondayTuesdayEnd Date [Tues] 6/20/201200:00-04:00SOPs + BCS Recovery Set-up SOPs + BCS 6/26/2012 04:00-08:00 PAMMRecovery Set-up PAMM 08:00-12:00 PAMM POMMSet-up User Group PAMM 12:00-16:00 PAMM MD PAMM 16:00-20:00 Recovery MD Recovery 20:00-24:00 Recovery MD Recovery 6/27/201200:00-04:00 Recovery Set-up 7/3/2012 04:00-08:00 Recovery Set-up 08:00-12:00POMMSet-up 12:00-16:00MD User Group 16:00-20:00MD 20:00-24:00MD

10. 10 Proposal 1.2 – Moving PAMM take 2 Starting Date [Wed] WednesdayThursdayFridaySaturdaySundayMondayTuesdayEnd Date [Tues] 6/20/201200:00-04:00SOPs + BCS Recovery Set-up 6/26/2012 04:00-08:00 PAMMRecovery Set-up 08:00-12:00 PAMM POMMSet-up User Group 12:00-16:00 PAMM MD 16:00-20:00 Recovery MD 20:00-24:00 Recovery MD 6/27/201200:00-04:00 SOPs + BCS Recovery 7/3/2012 04:00-08:00 PAMMRecovery 08:00-12:00 PAMM POMM 12:00-16:00 PAMM MD User Group 16:00-20:00 Recovery MD 20:00-24:00 Recovery MD There are enough Operators to support a Thursday PAMM Friday has enough Operators but a PAMM just before a weekend brings risk if there is a bad recovery

11. 11 Proposal 2 – Double-up PAMM once a fortnight (at the same time as LCLS) Longer PAMM More MD time and more set-up time likely to lead to better delivery Set-up time could be longer still if next experiment requires it Starting Date [Wed] WednesdayThursdayFridaySaturdaySundayMondayTuesdayEnd Date [Tues] 6/20/201200:00-04:00SOPs + BCS PAMMRecovery MDSet-up 6/26/2012 04:00-08:00 PAMM Recovery MDSet-up 08:00-12:00 PAMM POMMMDSet-up 12:00-16:00 PAMMRecovery MD Set-up 16:00-20:00 PAMMRecovery MD Set-up 20:00-24:00 PAMMRecovery MD Set-up 6/27/201200:00-04:00 7/3/2012 04:00-08:00 08:00-12:00 12:00-16:00 User Group 16:00-20:00 20:00-24:00

12. 12 Combinations, Variations and Further Ideas Two-day PAMMs with a one week schedule - Is less beam time what we want? One-day PAMM once a fortnight - Beam quality will improve and there will be more beam time for Users Interleave MD and set-up with User Time - Scheduling configuration changes during the User Run 1 proved difficult but it is necessary Schedule beam tuning - Problems arise over time and it may be beneficial to hand over to the Sector0-20 team on a regular and scheduled basis for improved delivery

13. 13 What’s up with those 8 hour shifts anyway? 8 hour shifts: Owl: midnight-8am Day: 8am-4pm Swing: 4pm-midnight Some experiments want less beam time in a single block (E-202) ~4 hour shift. And some operated on 12 hour shift rota (E-201). SSRL has 11pm-7am, 7am-3pm, 3pm-11pm shifts. We should not be hung-up on the 8 hour rota if this doesn’t work for us

14. 14 20 minute discussion Talking Points: Group A, B, C and D: how did that work? How long should PAMMs be? Can we have fewer PAMMs or do we need to have more PAMMs? How long should blocks of experiments be? How much time should we have for MD? How do we schedule the set-up time? Should experiments be interleaved more or less? Should we schedule beam tuning or leave it to User request? How do we best schedule the configuration changes? Can we get away without any over owl shifts? Length and pattern of “shifts” - Better to avoid operator shift change-over? - Can we stagger User shifts with accelerator physicist shifts so we don’t have a User shift that never sees an accelerator physicist?