1. Progress on e-cloud effects (PS and SPS) G. Iadarola, H.Bartosik, G. Rumolo, M. Taborelli, C. Yin Vallgren Many thanks to: G. Arduini, T. Argyropoulos, T. Bohl, F. Caspers, S. Cettour Cave, K. Cornelis, H. Damerau, M. Driss Mensi, J. Esteban Muller, S. Federmann, F. Follin, S. Gilardoni, B. Goddard, S. Hancock, W. Hofle, M.Holz, C. Lazaridis, L. Kopylov, H. Neupert, Y. Papaphilippou, M. Pivi, S. Rioja Fuentelsaz, D. Schoerling, E. Shaposhnikova,, G. Sterbini, H. Timko and all the PS and SPS operator crews and all the PS and SPS operator crews

2. Outline Electron cloud effects in the PS Beam observation Flat top instability RF voltage optimization for e-cloud mitigation Studies for the main magnets Electron cloud effects in the SPS Status for nominal intensity Tests with higher intensity “Doublet” beam for scrubbing e-cloud measurement campaign a-C coatings

3. Outline Electron cloud effects in the PS Beam observation Flat top instability RF voltage optimization for e-cloud mitigation Studies for the main magnets Electron cloud effects in the SPS Status for nominal intensity Tests with higher intensity “Doublet” beam for scrubbing e-cloud measurement campaign a-C coatings

4. e-cloud in the PS h=7 b. sp. ≈ 330 ns (4 - 6 b.) h=21 b. sp.≈100 ns (18 b.) h=42 b.sp.=50 ns (36 b.) h=84 b.sp.=25 ns (72 b.) Triple splitting Double splitting Bunch shortening Double splitting

5. e-cloud in the PS h=7 b. sp. ≈ 330 ns (4 - 6 b.) h=21 b. sp.≈100 ns (18 b.) h=42 b.sp.=50 ns (36 b.) h=84 b.sp.=25 ns (72 b.) Triple splitting Double splitting Bunch shortening Double splitting No e-cloud

6. e-cloud in the PS h=7 b. sp. ≈ 330 ns (4 - 6 b.) h=21 b. sp.≈100 ns (18 b.) Triple splitting Double splitting Bunch shortening Double splitting 0102030405060 50 150 250 300 200 100 40 MHz RF Voltage [kV] Time [ms] h=42 b.sp. = 50 ns (36 b.) h=84 b.sp. = 25 ns (72 b.) Double splitting Adiabatic shortening Bunch rotation b.l.≈14 ns 11 ns 4 ns

7. e-cloud in the PS h=7 b. sp. ≈ 330 ns (4 - 6 b.) h=21 b. sp.≈100 ns (18 b.) Triple splitting Double splitting Bunch shortening Double splitting 0102030405060 50 150 250 300 200 100 40 MHz RF Voltage [kV] Time [ms] h=42 b.sp. = 50 ns (36 b.) h=84 b.sp. = 25 ns (72 b.) Double splitting Adiabatic shortening Bunch rotation b.l.≈14 ns 11 ns 4 ns E-cloud expected and observed

8. e-cloud in the PS: beam observations Up to now e-cloud in the PS has never been a limitation for the production of the 25 ns LHC type beams In 2012, bunch by bunch emittance measurements performed in the SPS (intensities up to 1.45e11 ppb) never revealed any e-cloud signature on the emittance pattern coming from the PS Measurements done on the SPS flat top with 1.45e11 ppb injected into the SPS Horizontal Vertical

9. A possible reason of the absence of any degradation could be that the beam does not interact with the cloud for a sufficiently long time 50 150 250 300 200 100 40 MHz RF Voltage [kV] Time [ms] b.l.≈14 ns 11 ns 0102030405060 4 ns 708090 100 Transverse instability with “stored” beam

10. 50 150 250 300 200 100 40 MHz RF Voltage [kV] Time [ms] b.l.≈14 ns b.l.≈ 11 ns 0102030405060 708090 100 Transverse instability with “stored” beam A possible reason of the absence of any degradation could be that the beam does not interact with the cloud for a sufficiently long time If we “store” the beam for ~20 ms an horizontal instability is observed. First studies in: R. Cappi, M. Giovannozzi, E. Metral, G. Métral, G. Rumolo and F. Zimmermann, "Electron cloud buildup and related instability in the CERN Proton Synchrotron." Physical Review Special Topics-Accelerators and Beams 5.9 (2002): 094401.

11. Transverse instability with “stored” beam A possible reason of the absence of any degradation could be that the beam does not interact with the cloud for a sufficiently long time If we “store” the beam for ~20 ms an horizontal instability is observed. The risetime is decreasing along the train

12. Transverse instability with “stored” beam A possible reason of the absence of any degradation could be that the beam does not interact with the cloud for a sufficiently long time If we “store” the beam for ~20 ms an horizontal instability is observed. The risetime is decreasing along the train

13. Transverse instability with “stored” beam A possible reason of the absence of any degradation could be that the beam does not interact with the cloud for a sufficiently long time If we “store” the beam for ~20 ms an horizontal instability is observed. The risetime is decreasing along the train

14. Transverse instability with “stored” beam A possible reason of the absence of any degradation could be that the beam does not interact with the cloud for a sufficiently long time If we “store” the beam for ~20 ms an horizontal instability is observed. The risetime is decreasing along the train

15. Transverse instability with “stored” beam A possible reason of the absence of any degradation could be that the beam does not interact with the cloud for a sufficiently long time If we “store” the beam for ~20 ms an horizontal instability is observed. The risetime is decreasing along the train

16. Transverse instability with “stored” beam A possible reason of the absence of any degradation could be that the beam does not interact with the cloud for a sufficiently long time If we “store” the beam for ~20 ms an horizontal instability is observed. The risetime is decreasing along the train

17. Transverse instability with “stored” beam A possible reason of the absence of any degradation could be that the beam does not interact with the cloud for a sufficiently long time If we “store” the beam for ~20 ms an horizontal instability is observed. The risetime is decreasing along the train

18. Transverse instability with “stored” beam A possible reason of the absence of any degradation could be that the beam does not interact with the cloud for a sufficiently long time If we “store” the beam for ~20 ms an horizontal instability is observed. The risetime is decreasing along the train

19. Transverse instability with “stored” beam A possible reason of the absence of any degradation could be that the beam does not interact with the cloud for a sufficiently long time If we “store” the beam for ~20 ms an horizontal instability is observed. The risetime is decreasing along the train

20. Transverse instability with “stored” beam A possible reason of the absence of any degradation could be that the beam does not interact with the cloud for a sufficiently long time If we “store” the beam for ~20 ms an horizontal instability is observed. The risetime is decreasing along the train

21. Transverse instability with “stored” beam A possible reason of the absence of any degradation could be that the beam does not interact with the cloud for a sufficiently long time If we “store” the beam for ~20 ms an horizontal instability is observed. The risetime is decreasing along the train

22. Transverse instability with “stored” beam A possible reason of the absence of any degradation could be that the beam does not interact with the cloud for a sufficiently long time If we “store” the beam for ~20 ms an horizontal instability is observed. The risetime is decreasing along the train

23. Transverse instability with “stored” beam A possible reason of the absence of any degradation could be that the beam does not interact with the cloud for a sufficiently long time If we “store” the beam for ~20 ms an horizontal instability is observed. The risetime is decreasing along the train Coupled bunch motion is clearly visible

24. Transverse instability with “stored” beam A possible reason of the absence of any degradation could be that the beam does not interact with the cloud for a sufficiently long time If we “store” the beam for ~20 ms an horizontal instability is observed. The risetime is decreasing along the train Coupled bunch motion is clearly visible

25. Transverse instability with “stored” beam A possible reason of the absence of any degradation could be that the beam does not interact with the cloud for a sufficiently long time If we “store” the beam for ~20 ms an horizontal instability is observed. The risetime is decreasing along the train Coupled bunch motion is clearly visible

26. Transverse instability with “stored” beam A possible reason of the absence of any degradation could be that the beam does not interact with the cloud for a sufficiently long time If we “store” the beam for ~20 ms an horizontal instability is observed. The risetime is decreasing along the train Coupled bunch motion is clearly visible

27. Transverse instability with “stored” beam A possible reason of the absence of any degradation could be that the beam does not interact with the cloud for a sufficiently long time If we “store” the beam for ~20 ms an horizontal instability is observed. The risetime is decreasing along the train Coupled bunch motion is clearly visible

28. Transverse instability with “stored” beam A possible reason of the absence of any degradation could be that the beam does not interact with the cloud for a sufficiently long time If we “store” the beam for ~20 ms an horizontal instability is observed. The risetime is decreasing along the train Coupled bunch motion is clearly visible

29. Transverse instability with “stored” beam A possible reason of the absence of any degradation could be that the beam does not interact with the cloud for a sufficiently long time If we “store” the beam for ~20 ms an horizontal instability is observed. The risetime is decreasing along the train Coupled bunch motion is clearly visible

30. Transverse instability with “stored” beam A possible reason of the absence of any degradation could be that the beam does not interact with the cloud for a sufficiently long time If we “store” the beam for ~20 ms an horizontal instability is observed. The risetime is decreasing along the train Coupled bunch motion is clearly visible

31. Transverse instability with “stored” beam A possible reason of the absence of any degradation could be that the beam does not interact with the cloud for a sufficiently long time If we “store” the beam for ~20 ms an horizontal instability is observed. The risetime is decreasing along the train Coupled bunch motion is clearly visible

32. Transverse instability with “stored” beam A possible reason of the absence of any degradation could be that the beam does not interact with the cloud for a sufficiently long time If we “store” the beam for ~20 ms an horizontal instability is observed. The risetime is decreasing along the train Coupled bunch motion is clearly visible

33. Transverse instability with “stored” beam A possible reason of the absence of any degradation could be that the beam does not interact with the cloud for a sufficiently long time If we “store” the beam for ~20 ms an horizontal instability is observed. The risetime is decreasing along the train Coupled bunch motion is clearly visible These features look compatible with an e-cloud driven instability

34. Transverse instability with “stored” beam A possible reason of the absence of any degradation could be that the beam does not interact with the cloud for a sufficiently long time If we “store” the beam for ~20 ms an horizontal instability is observed. The risetime is decreasing along the train Coupled bunch motion is clearly visible These features look compatible with an e-cloud driven instability Good news: the new transverse feedback can delay this instability! 10 ms See talk by G. Sterbini

35. Possible mitigation strategies: RF voltage program Together with the RF experts, we could optimize the 40MHz voltage program in order to mitigate the e-cloud without affecting the beam quality 0102030405060 50 150 250 300 200 100 40 MHz RF Voltage [kV] Time [ms] Double splitting b.l.≈14 ns 11 ns 4 ns 40kV H. Damerau, S. Hancock, T. Kroyer, E. Mahner and M. Schokker, Electron Cloud Mitigation by Fast Bunch Compression in the CERN PS (No. CERN-AB-2008-050).

36. 0102030405060 50 150 250 300 200 100 40 MHz RF Voltage [kV] Time [ms] Double splitting 4 ns 36 kV Possible mitigation strategies: RF voltage program Together with the RF experts, we could optimize the 40MHz voltage program in order to mitigate the e-cloud without affecting the beam quality H. Damerau, S. Hancock, T. Kroyer, E. Mahner and M. Schokker, Electron Cloud Mitigation by Fast Bunch Compression in the CERN PS (No. CERN-AB-2008-050).

37. Possible mitigation strategies: RF voltage program Together with the RF experts, we could optimize the 40MHz voltage program in order to mitigate the e-cloud without affecting the beam quality 1.25e11 ppb 1.45e11 ppb 60b.  schemes with shorter train (e.g. BCMS) are less critical

38. To be addressed with simulations and measurements with particular focus on main magnets: PyECLOUD modules for the simulation combined function magnets have been developed and tested One magnet unit will be equipped for e-cloud detection during LS1 (see talk by S. Gilardoni) e-cloud in the main magnets We need to assess if with LIU beam parameters the observed instability (or other e-cloud effects) can degrade the beams on the timescale of the production cycle.

39. To be addressed with simulations and measurements with particular focus on main magnets: PyECLOUD modules for the simulation combined function magnets have been developed and tested One magnet unit will be equipped for e-cloud detection during LS1 (see talk by S. Gilardoni) e-cloud in the main magnets We need to assess if with LIU beam parameters the observed instability (or other e-cloud effects) can degrade the beams on the timescale of the production cycle. E field - beam Electron distribution

40. e-cloud in the main magnets We need to assess if with LIU beam parameters the observed instability (or other e-cloud effects) can degrade the beams on the timescale of the production cycle. [By Teddy Capelli EN/MME] To be addressed with simulations and measurements with particular focus on main magnets: PyECLOUD modules for the simulation combined function magnets have been developed and tested One magnet unit will be equipped for e-cloud detection during LS1 (see talk by S. Gilardoni)

41. Outline Electron cloud effects in the PS Beam observation Flat top instability RF voltage optimization for e-cloud mitigation Studies for the main magnets Electron cloud effects in the SPS Status for nominal intensity Tests with higher intensity “Doublet” beam for scrubbing e-cloud measurement campaign a-C coatings

42. e-cloud in the SPS: nominal bunch intensity In the past e-cloud has been strongly limiting the performances with 25 ns beams with detrimental effects both on vacuum and beam quality Scrubbing runs regularly performed over the years with evident beneficial effects on dynamic pressure rise and beam quality Vertical emittance 2000 (1 batch 0.8x10 11 ppb) 400% G. Arduini, K. Cornelis et al.

43. e-cloud in the SPS: nominal bunch intensity In the past e-cloud has been strongly limiting the performances with 25 ns beams with detrimental effects both on vacuum and beam quality Scrubbing runs regularly performed over the years with evident beneficial effects on dynamic pressure rise and beam quality Full characterization of the nominal 25 ns beams in the SPS (bunch by bunch emittance, tune, liferime vs. chrmoaticity) did not show any degradation due to e-cloud Vertical 2012 (4 batches 1.15x10 11 ppb)

44. Tests with higher intensity In the last part of the 2012, MD sessions were dedicated to tests with higher intensity 25 ns beams (up to 1.45e11 inj.) with Q20 optics o Emittance blow up observed on trailing bunches of the last batches But: o Machine never scrubbed for these intensities o Possible other sources still to be investigated

45. Tests with higher intensity In the last part of the 2012, MD sessions were dedicated to tests with higher intensity 25 ns beams (up to 1.45e11 inj.) with Q20 optics o Emittance blow up observed on trailing bunches of the last batches But: o Machine never scrubbed for these intensities o Possible other sources still to be investigated Two wire breakage during this tests. Bunch by bunch emittance measurements on full bunch train are extremely important to identify/study this kind of issues. Are we ready for higher intensities?

46. “Doublet” scrubbing beam An important goal of the studies was the identification of a possible dedicated scrubbing beam, showing an e-cloud threshold lower than the 25 ns beam. Simulations have shown that a possible candidate is 25 ns spaced train of doublets PyECLOUD simulation Accumulation between subsequent turns

47. “Doublet” scrubbing beam An important goal of the studies was the identification of a possible dedicated scrubbing beam, showing an e-cloud threshold lower than the 25 ns beam. Simulations have shown that a possible candidate is 25 ns spaced train of doublets Relatively simple production : o Inject long bunches from the PS (b. len.≈10 ns) o Capture in two SPS buckets (5 ns long)

48. “Doublet” scrubbing beam Thanks to T. Argyropoulos and J. Esteban Muller First 500 turns after inj. The production scheme has been successfully tested for a train of (2x)72 bunches with 1.7e11 p per doublet The possibility to inject more than one batch from the PS has been tested in Feb. 2013 2 s after inj.

49. “Doublet” scrubbing beam It seems it works!!! MBA-like Stainless Steel liner 25ns standard (1.6e11p/bunch) 25ns “doublet” (1.7e11p/doublet) Clear enhancement observed both on e-cloud detectors and pressure in the arcs 25ns std. (1.6e11p/bunch ) (1.7e11p/doublet) 25ns “doublet”

50. a-C coatings In 2012, amorphous carbon coatings have been validated as an e-cloud suppression technique, to be used if scrubbing will not be sufficient o Tests showed that the dynamic pressure rise in a-C coated section is not due e-cloud in the coated parts

51. e-cloud measurement campaign e-cloud direct and indirect observables have been measured under different beam conditions for the validation models and codes and as a reference for after LS1 ATS-Note in publication

52. Summary and conclusions Electron cloud effects in the PS Up to now e-cloud in the PS has never been a limitation for the production of the 25 ns LHC type beams but transverse instabilities are observed when “storing” 25 ns beams at 26 GeV (new transverse feedback helps) Double bunch rotation, 10% less voltage during the last bunch splitting, and possibly shorter bunch trains give a significant reduction on the e-cloud activity To predict the e-cloud behavior at higher intensities PyECLOUD modules have been developed for the simulation of combined function magnets A main magnet will be equipped for e-cloud detection during LS1

53. Summary and conclusions Electron cloud effects in the SPS No visible effect of electron cloud on nominal LHC 25ns (beam parameters within LHC design report specifications) Transverse emittance blow-up on the tail of the bunch train observed during tests with higher intensity “Doublet” beam has been tested as a possible scrubbing beam with very encouraging results a-C coating have been validated as e-cloud suppression technique in case scrubbing does not work e-cloud related measurements have been collected under different beam conditions, to be used for the validation of our e-cloud model and as a reference after LS1

54. Thank you for your attention!

55. Possible mitigation strategies: RF voltage program Together with the RF experts, we tried to optimize the 40MHz voltage program in order to mitigate the e-cloud without affecting the beam quality 0102030405060 50 150 250 300 200 100 40 MHz RF Voltage [kV] Time [ms] Double splitting b.l.≈14 ns 4 ns 1.25e11 ppb Double bunch rotation H. Damerau, S. Hancock, T. Kroyer, E. Mahner and M. Schokker, Electron Cloud Mitigation by Fast Bunch Compression in the CERN PS (No. CERN-AB-2008-050). Tested in 2008 with encouraging results on e-cloud signals