1. John Seeman LCLS ARRseeman@slac.stanford.edu December 2, 2008 1 Conduct of LCLS Accelerator Operations John Seeman Assistant Director LCLS Directorate Head of the Accelerator Systems Division LCLS Directorate

2. John Seeman LCLS ARRseeman@slac.stanford.edu December 2, 2008 2 Accelerator System Division Maintenance management Down time planning Overall schedule Scheduling beam time Delivered beam specification Topics

3. John Seeman LCLS ARRseeman@slac.stanford.edu December 2, 2008 3 Accelerator Systems Division (ASD) ASD has operated accelerators at SLAC for well over 30 years. The accelerators are: Linac (50 GeV) PEP-I SPEAR-I and II SLC PEP-II FFTB LCLS Injection and Linac Programs, training, and documentation in place to carry out the programs carefully, safely, and with full technical rigor. The staff is trained to carry out these programs, holding all accelerators to the same standards. Formal procedures are in place to deal properly with DOE safety standards, Operations Directives, and the Citizen Committees.

4. John Seeman LCLS ARRseeman@slac.stanford.edu December 2, 2008 4 ASD Documentation Guiding documents: SLAC Guidelines of Operations (Under constant updating) ASD Operations Directives LCLS/LINAC SAD LCLS/LINAC ASE Accelerator Safety Assessment Documents ES&H documentation Un-reviewed Safety Items (USI) handled by Guidelines of Operations and LCLS SAD ASD Operational documents

5. John Seeman LCLS ARRseeman@slac.stanford.edu December 2, 2008 5 USIs LCLS SAD: Safety issues that are not covered in the above documentation, and for which a safety analysis has not been performed, could arise. Such an issue would constitute an Unreviewed Safety Issue under DOE Order 420.2B Section 4c. Activities that involve unreviewed safety issues must not be performed if significant safety consequences could result from either an accident or a malfunction of equipment that is important to safety. Such activitites would be formally reviewed and be subject to the approval of the appropriate safety officers and citizen safety committees, as required by SLAC Guidelines for Operations. Activities involving identified unreviewed safety issues must not commence before DOE has provided written approval. A Working Group has been formed as follow up to the DOE ISMS Effectiveness Review in August 2008 with the aim of improving USI definition at SLAC with inputs from other laboratories programs with the target of Spring 2009.

6. John Seeman LCLS ARRseeman@slac.stanford.edu December 2, 2008 6 Authorization of operating the Linac Related Accelerators at SLAC follow the organization of the SLAC laboratory: SLAC DOE Site Office Laboratory Director Deputy Directors for LCLS Head of the Accelerator Systems Division Head of the Operation Group Engineering Operator In Charge (EOIC) in the Control Room Operations Authorization

7. John Seeman LCLS ARRseeman@slac.stanford.edu December 2, 2008 7 ASD Staff Admin: 4 Safety office: 1 Physicists: 9 Mechanical engineers: 3 Operations and reliability: 2 Operators: 23 Area managers: 7 Technicians: 3 Total = 52

8. John Seeman LCLS ARRseeman@slac.stanford.edu December 2, 2008 8 LCLS beam: 4 to 14 GeV e- beam to 120 Hz to 1 x 10 10 Linac capabilities (if needed): e- to 49 GeV at 120 Hz at 2 x 10 10 e+ to 49 GeV at 120 Hz at 2 x 10 10 Linac Operating Modes in FY2009

9. John Seeman LCLS ARRseeman@slac.stanford.edu December 2, 2008 9 Main Control Center for LCLS Operations

10. John Seeman LCLS ARRseeman@slac.stanford.edu December 2, 2008 10 Program Deputy Duty rotates among Accelerator Division physicists. Oversees program for 3 or 4 day period. Not always present in the control room. Operations Engineer 1 EOIC per shift (from a group of 7), on rotating 7-week cycle. Responsible for safely carrying out the scheduled program. Exempt position; directs the Accelerator Systems Operators. Must be present if accelerator is capable of producing beam. All have experience as accelerator systems operators. Accelerator Systems Operators Typically 3 operators per shift on rotating 5-week cycle: Control Room Staffing

11. John Seeman LCLS ARRseeman@slac.stanford.edu December 2, 2008 11 Operators are trained to carry out certain well-defined tasks, following formally controlled procedures. Examples: Interlock Checklists Search Procedures Entry and Exit Procedures Safety Inspection Checklists Safety procedures: undergo a formal review and approval process. are updated as conditions change. are available on the AD Documentation web site, although the signed originals are preserved in paper form Completed checklists and log books are archived. Operator Safety Procedures

12. John Seeman LCLS ARRseeman@slac.stanford.edu December 2, 2008 12 8:00 Meeting every day, seven days a week, in MCC conference room. Operations report by EOIC, including run time statistics, progress in carrying out scheduled program, descriptions of problems, etc. Reports by representatives of major experimental user groups. Attended by PPA, Accel Div, and Operations management reps, Program Deputy, System Physicists, Area Managers, and representatives of user groups and major technical support departments; typical attendance: 45 persons. 8:15 Maintenance Meeting, five days each week. Run by Accelerator Operations Department maintenance managers. Attended by supervisors of all maintenance groups, Area Managers, and interested physicists and engineers. Attendance: typically 45 persons. Accelerator Plans Meeting, weekly. Review of operational progress, problems, and plans. Attended by Accel Systems Div and Dept Heads, Program Coordinators, Accelerator Section Heads and ADSO. Planning with Accelerator Users and Maintenance Staff

13. John Seeman LCLS ARRseeman@slac.stanford.edu December 2, 2008 13 Planned Maintenance Days Whenever possible, identified maintenance, repair, and installation jobs are pre-planned. Coordination Daily 8:15am meeting. Coordinated by Operations Maintenance Office. Area Managers are advocates for their areas. Standby Maintenance List (SML) Jobs that are planned and can be launched on short notice. Provides options for EOIC to take advantage of unscheduled interruptions. ARTEMIS/CATER Electronic Database records items. Accelerator Maintenance

14. John Seeman LCLS ARRseeman@slac.stanford.edu December 2, 2008 14 ARTEMIS (Accelerator Remedy Trouble Entry and Maintenance Information System) is an Oracle database with a Remedy interface, accessible over the internet by everyone involved with SLAC accelerator maintenance. Operators report problems as they occur by making entries in ARTEMIS. Repair work is launched immediately if the problem is inhibiting the scheduled accelerator program. Jobs are tracked using ARTEMIS until they are finally closed. ARTEMIS entries since Jan 1989: ~84000. ARTEMIS entries in one year (2006): 3166 new problems (8.7 per day). 3296 problems closed (9.0 per day). ARTEMIS/CATER

15. John Seeman LCLS ARRseeman@slac.stanford.edu December 2, 2008 15 Long Down Times usually occur once each year and typically last two to three months. Area Managers collect job requests from system physicists, project engineers, maintenance groups, and the ARTEMIS database. A comprehensive schedule is prepared, updated, and reviewed at weekly meetings, starting about four months before the down time. This schedule lists each job with an assigned shop, and lists the Project or Group Manager, Responsible Task Person, and Area Manager. Schedule specifies time and duration of each job (with 1 day time resolution), and number of persons required. Schedule specifies authorizations required (WAF, RSWCF, EWP, etc.). Detailed (shift by shift) schedule of pre-run testing, safety certifications, and turn-on activities is prepared by the Operations Dept and revised as needed on a real-time basis. Long Down Time Planning

16. John Seeman LCLS ARRseeman@slac.stanford.edu December 2, 2008 16 Accelerator Improvement Projects (AIP)

17. John Seeman LCLS ARRseeman@slac.stanford.edu December 2, 2008 17

18. John Seeman LCLS ARRseeman@slac.stanford.edu December 2, 2008 18 Goal for what typical LCLS operations will look like in two years.

19. John Seeman LCLS ARRseeman@slac.stanford.edu December 2, 2008 19 Re-establish e  to SL2 LTU/UndComm. First Light in FEE First Light in FEH NEH Ops & Commissioning JJFFMMAAMMJJJJAASSDDJJFFMMAAMMJJJJAASSOONNDDJJFFMMAAMMJJJJ ON A A 2008 2009 2010 2008 2009 2010 Down PPS Linac/BC2 Commissioning FEL/FEECommissioning Nov. 3, 2008 Install Undulators M M D D LCLS Installation and Commissioning Time-Line LTU/Und Install PEP-II run ends FEE/NEH Install PPS Cert. LTU/Dump CD-4 (7/31/2010) X-Rays in NEH now D D Down? FEH Hutch BO

20. John Seeman LCLS ARRseeman@slac.stanford.edu December 2, 2008 20

21. John Seeman LCLS ARRseeman@slac.stanford.edu December 2, 2008 21 X-ray User Performance Drivers for ASD Reliable operation with high uptime (>95%). Steady beam parameters when operating. Rapid but reasonable change of beam parameters when needed by the user. Maintain alternate user programs when expected user program changes.

22. John Seeman LCLS ARRseeman@slac.stanford.edu December 2, 2008 22 Proposed Initial Beam Parameters for Users Early opsMature Electron energy4.3 GeV Repetition rate30 Hz120 Hz Bunch length200 fs FWHM FEL peak power500 MW5 GW FEL bandwidth0.25%0.2% Energy per pulse0.1 mJ2 mJ Photons/0.1%BW3 10 11 1 10 13 Peak brightness3 10 30 3 10 31 Average brightness2 10 19 2 10 21 J. Galayda

23. John Seeman LCLS ARRseeman@slac.stanford.edu December 2, 2008 23 Linac operations are managed by the Accelerator Systems Division under the LCLS Directorate. Documented policies and procedures exit for all safety-related activities. Maintenance and installation work is accomplished through a matrix organization, drawing on engineers, technicians, and ES&H and shop services from the ETS Directorate. We have developed organizational structures, software tools, and documentation that enable us to manage an ambitious accelerator-based science program safely and effectively. A beam-time scheduling mechanism is being developed to resolve operational beam parameter specifications and changes. We are ready to operate the LCLS LTU, Undulator, and e- Beam Dump. Conclusions