View
31
Download
0
Category
Tags:
Preview:
DESCRIPTION
Progress on e-cloud effects (PS and SPS). 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, - PowerPoint PPT Presentation
Citation preview
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
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
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
e-cloud in the PS
h=7b. sp. ≈ 330 ns (4 - 6 b.)
h=21b. sp.≈100 ns (18 b.)
h=42b.sp.=50 ns (36 b.)
h=84b.sp.=25 ns (72 b.)
Triplesplitting
Double splitting
Bunch shortening
Double splitting
e-cloud in the PS
h=7b. sp. ≈ 330 ns (4 - 6 b.)
h=21b. sp.≈100 ns (18 b.)
h=42b.sp.=50 ns (36 b.)
h=84b.sp.=25 ns (72 b.)
Triplesplitting
Double splitting
Bunch shortening
Double splitting
No e-cloud
e-cloud in the PS
h=7b. sp. ≈ 330 ns (4 - 6 b.)
h=21b. sp.≈100 ns (18 b.)
Triplesplitting
Double splitting
Bunch shortening
Double splitting
0 10 20 30 40 50 60
50
150
250
300
200
100
40 M
Hz R
F Vo
ltage
[kV]
Time [ms]
h=42b.sp. = 50 ns (36 b.)
h=84b.sp. = 25 ns (72 b.)
Double splitting
Adiabatic shortening
Bunch rotation
b.l.≈14 ns
11 ns
4 ns
e-cloud in the PS
h=7b. sp. ≈ 330 ns (4 - 6 b.)
h=21b. sp.≈100 ns (18 b.)
Triplesplitting
Double splitting
Bunch shortening
Double splitting
0 10 20 30 40 50 60
50
150
250
300
200
100
40 M
Hz R
F Vo
ltage
[kV]
Time [ms]
h=42b.sp. = 50 ns (36 b.)
h=84b.sp. = 25 ns (72 b.)
Double splitting
Adiabatic shortening
Bunch rotation
b.l.≈14 ns
11 ns
4 ns
E-cloud expected and observed
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
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 M
Hz R
F Vo
ltage
[kV]
Time [ms]
b.l.≈14 ns
11 ns
0 10 20 30 40 50 60
4 ns
70 80 90 100
Transverse instability with “stored” beam
50
150
250
300
200
100
40 M
Hz R
F Vo
ltage
[kV]
Time [ms]
b.l.≈14 ns
b.l.≈ 11 ns
0 10 20 30 40 50 60 70 80 90 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.
0 5000 10000 15000-0.4
-0.3
-0.2
-0.1
0
0.1
0.2
0.3
0.4
Turn #
Hor
. pos
ition
. [a.
u.]
Bunch 70
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.
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.
0 5000 10000 15000-0.4
-0.3
-0.2
-0.1
0
0.1
0.2
0.3
0.4
Turn #
Hor
. pos
ition
. [a.
u.]
Bunch 1
• The risetime is decreasing along the train
0 5000 10000 15000-0.4
-0.3
-0.2
-0.1
0
0.1
0.2
0.3
0.4
Turn #
Hor
. pos
ition
. [a.
u.]
Bunch 10
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
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.
0 5000 10000 15000-0.4
-0.3
-0.2
-0.1
0
0.1
0.2
0.3
0.4
Turn #
Hor
. pos
ition
. [a.
u.]
Bunch 16
• The risetime is decreasing along the train
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.
0 5000 10000 15000-0.4
-0.3
-0.2
-0.1
0
0.1
0.2
0.3
0.4
Turn #
Hor
. pos
ition
. [a.
u.]
Bunch 22
• The risetime is decreasing along the train
0 5000 10000 15000-0.4
-0.3
-0.2
-0.1
0
0.1
0.2
0.3
0.4
Turn #
Hor
. pos
ition
. [a.
u.]
Bunch 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
0 5000 10000 15000-0.4
-0.3
-0.2
-0.1
0
0.1
0.2
0.3
0.4
Turn #
Hor
. pos
ition
. [a.
u.]
Bunch 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
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.
0 5000 10000 15000-0.4
-0.3
-0.2
-0.1
0
0.1
0.2
0.3
0.4
Turn #
Hor
. pos
ition
. [a.
u.]
Bunch 40
• The risetime is decreasing along the train
0 5000 10000 15000-0.4
-0.3
-0.2
-0.1
0
0.1
0.2
0.3
0.4
Turn #
Hor
. pos
ition
. [a.
u.]
Bunch 46
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
0 5000 10000 15000-0.4
-0.3
-0.2
-0.1
0
0.1
0.2
0.3
0.4
Turn #
Hor
. pos
ition
. [a.
u.]
Bunch 52
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
0 5000 10000 15000-0.4
-0.3
-0.2
-0.1
0
0.1
0.2
0.3
0.4
Turn #
Hor
. pos
ition
. [a.
u.]
Bunch 58
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
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.
0 5000 10000 15000-0.4
-0.3
-0.2
-0.1
0
0.1
0.2
0.3
0.4
Turn #
Hor
. pos
ition
. [a.
u.]
Bunch 61
• The risetime is decreasing along the train
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.
0 5000 10000 15000-0.4
-0.3
-0.2
-0.1
0
0.1
0.2
0.3
0.4
Turn #
Hor
. pos
ition
. [a.
u.]
Bunch 67
• The risetime is decreasing along the train
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
0 10 20 30 40 50 60 70 80-0.4
-0.3
-0.2
-0.1
0
0.1
0.2
0.3
0.4
Bunch #
Hor
. pos
ition
[a.u
.]
Turn 6000
0 10 20 30 40 50 60 70 80-0.4
-0.3
-0.2
-0.1
0
0.1
0.2
0.3
0.4
Bunch #
Hor
. pos
ition
[a.u
.]
Turn 6001
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
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
0 10 20 30 40 50 60 70 80-0.4
-0.3
-0.2
-0.1
0
0.1
0.2
0.3
0.4
Bunch #
Hor
. pos
ition
[a.u
.]
Turn 6002
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
0 10 20 30 40 50 60 70 80-0.4
-0.3
-0.2
-0.1
0
0.1
0.2
0.3
0.4
Bunch #
Hor
. pos
ition
[a.u
.]
Turn 6003
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
0 10 20 30 40 50 60 70 80-0.4
-0.3
-0.2
-0.1
0
0.1
0.2
0.3
0.4
Bunch #
Hor
. pos
ition
[a.u
.]
Turn 6004
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
0 10 20 30 40 50 60 70 80-0.4
-0.3
-0.2
-0.1
0
0.1
0.2
0.3
0.4
Bunch #
Hor
. pos
ition
[a.u
.]
Turn 6005
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
0 10 20 30 40 50 60 70 80-0.4
-0.3
-0.2
-0.1
0
0.1
0.2
0.3
0.4
Bunch #
Hor
. pos
ition
[a.u
.]
Turn 6006
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
0 10 20 30 40 50 60 70 80-0.4
-0.3
-0.2
-0.1
0
0.1
0.2
0.3
0.4
Bunch #
Hor
. pos
ition
[a.u
.]
Turn 6007
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
0 10 20 30 40 50 60 70 80-0.4
-0.3
-0.2
-0.1
0
0.1
0.2
0.3
0.4
Bunch #
Hor
. pos
ition
[a.u
.]
Turn 6008
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
0 10 20 30 40 50 60 70 80-0.4
-0.3
-0.2
-0.1
0
0.1
0.2
0.3
0.4
Bunch #
Hor
. pos
ition
[a.u
.]
Turn 6009
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
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
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
0 10 20 30 40 50 60
50
150
250
300
200
100
40 M
Hz R
F Vo
ltage
[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).
0 10 20 30 40 50 60
50
150
250
300
200
100
40 M
Hz R
F Vo
ltage
[kV]
Time [ms]
Double splitting4 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).
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
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.
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.
x [mm]
y [m
m]
E log(normalizad magnitude)
-100 -80 -60 -40 -20 0 20 40 60 80 100
-30
-20
-10
0
10
20
30
-7
-6
-5
-4
-3
-2
-1
0
E field - beam
Electron distribution
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)
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
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.8x1011ppb)
400%
G. Arduini, K. Cornelis et al.
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.15x1011ppb)
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 opticso Emittance blow up observed on trailing bunches of the last
batches
• But:o Machine never scrubbed for these intensitieso Possible other sources still to be investigated
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 opticso Emittance blow up observed on trailing bunches of the last
batches
• But:o Machine never scrubbed for these intensitieso 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?
“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
10 20 30 40 50 60 70
0.51
1.52
x 1011
Bea
m p
rof.
[p/m
]
10 20 30 40 50 60 701
1.05
1.1
1.15
1.2
1.25
1.3
1.35
1.4
Time [ns]
Ne /
Ne(0
)
PyECLOUD simulation
Accumulation between subsequent turns
“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
10 20 30 40 50 60 70
0.51
1.52
x 1011
Bea
m p
rof.
[p/m
]
10 20 30 40 50 60 701
1.05
1.1
1.15
1.2
1.25
1.3
1.35
1.4
Time [ns]
Ne /
Ne(0
)
10 20 30 40 50 60 70
0.51
1.52
x 1011
Bea
m p
rof.
[p/m
]
10 20 30 40 50 60 701
1.05
1.1
1.15
1.2
1.25
1.3
1.35
1.4
Time [ns]
Ne /
Ne(0
)
• Relatively simple production :o Inject long bunches from the PS (b. len.≈10 ns)o Capture in two SPS buckets (5 ns long)
“Doublet” scrubbing beam
Time [s]
Turn
0.15 0.16 0.17 0.18 0.19 0.2
50
100
150
200
250
300
350
400
450
500
0.92 0.93 0.94 0.95 0.96-0.01
0
0.01
0.02
0.03
0.04
0.05
0.06
0.07
Time [s]
Bea
m p
rofil
e [a
.u.]
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.
“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”
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 sufficiento Tests showed that the dynamic pressure rise in a-C coated
section is not due e-cloud in the coated parts
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
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
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
Thank you for your attention!
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
0 10 20 30 40 50 60
50
150
250
300
200
100
40 M
Hz R
F Vo
ltage
[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
Recommended