Electron Cloud Simulations Using ORBIT Code - Cold Proton Bunch model March 14, 2007 EP feedback workshop at Indiana University Bloomington Yoichi Sato, IUCF 1 Y. Sato IU ep workshop 2007

Outline ECloud Properties to Cold Proton Bunch in ORBIT  Proton Bunch Slope Dependence of ECloud Growth and Energy Distribution of Electrons Hitting Surface (triangular longitudinal line density profiles) Proton bunches of same head triangles and the effect of bunch slope Proton bunches of same tail triangles and the effect of primary electron amount  Prompt-Swept Electron Simulation and Discussion of Physics Parameters with Comparing PSR Data Constant proton loss rate to beam intensity Assumption of proton loss rate function of beam intensity  ECloud Recovery Simulation After Swept Proton loss rate estimation Inconsistency between the recovery estimation and prompt-swept slope fit  Conclusions 2 Y. Sato IU ep workshop 2007

PBunch Triangular Profiles 120ns PB tail 100ns PB tail 110ns PB tail 90ns PB tail Energy band 250eV-300eV corresponds to SEY peak The energy distribution of surface hitting electrons of off-peak-band reduces ECloud growth The longer tail of pBunch causes the larger eCloud and its higher growth rate. The steeper tail pBunch gives the higher energy of hitting electrons (E_0 > 250eV) and the lower SEY that may lead the lower growth rate. 3 Y. Sato IU ep workshop 2007

PBunch Triangular Profiles The carry-over and primary electrons before the peak of pBunch slightly change eCloud peak and growth rate. However, the slight differences imply that the pBunch effect to drive electrons may be mitigated by the existence of inside electrons during the beginning of pBunch tail slope. To have long head in pBunch profile is a possible way to accumulate more protons in a bunch. Effect of primary electrons stored in the head of proton bunch And effect of carry over electrons surviving beam gap 4 Y. Sato IU ep workshop 2007

Future Study for Artificial PBunch  Comparison of ep instability between Long head profile (short gap) and isosceles triangular profile (large gap) using ORBIT capability of simulating proton bunch dynamics. Even a short gap can remove the ep oscillation of carry-over eCloud in front of the next bunch.  Simulation of ECloud development to proton bunches of triangular + saw profile. We can expect to mitigate trailing edge multipaction. The saw ratio and frequency should be optimized. 5 Y. Sato IU ep workshop 2007

Prompt-Swept Electron Data from Electron Sweeper at PSR Beam Pulse HV pulse Electron Signal (prompt electron) Swept electron signal  The prompt electrons come out at the tail of the beam pulse. The Electron Sweeper (ES) functions as a large area Electron Detector (ED) until the HV pulse arrives.  The swept electron signal is narrow during HV at the end of the gap. The two experimental features: (1)swept electron slope is flatter than prompt electron slope, (2)swept electron slope has saturation in high intensity beam. 6 Y. Sato IU ep workshop 2007

Prompt-Swept Electrons constant proton loss rate to beam intensity in ORBIT In ORBIT, if both SEY_max & proton loss rate are constant to beam intensity, prompt- swept slopes are much flatter than experimental data. Prompt e in ORBIT means peak of surface current after recovery. Swept e in ORBIT means EC line density at PB head after recovery. SEY_max = 1.5 ~ 2.0 & proton loss rate = 4E-6/turn SEY_max = 2.0 & proton loss rate = 1E-8/turn ~ 4E-6/turn The ORBIT simulations are performed for field free section, where ED/ES locates in PSR. PSR features are reproduced qualitatively but not quantitatively. 7

Prompt-Swept Electrons: Assumption of Proton Loss Rate Function of Beam Intensity Now, we assume proton loss rate in drift space, where ED/ES locates, is an increase function of beam intensity (reasonable from space charge). Starting from the prompt-swept values of (7uC beam, 4e-6/turn proton loss rate), we performed simultaneous fitting on both prompt swept slopes with varying a single parameter “proton loss rate” to different beam intensity, 4uC ~ 8uC beam. The searched proton loss rate to fit simultaneously experimental prompt-swept slopes becomes an almost exponential function of beam intensity. This is another possible way to estimate proton loss rate. 8 Y. Sato IU ep workshop 2007

Recovery of ECloud: PSR and ORBIT 7.5 uC proton pulse measured in PSR shows 5 turn recovery of EC peak after clearing electrons in beam gap by HV-applied electron sweeper. In ORBIT simulation, a set of parameters [SEY_max=2.0, Proton loss rate ~1E-8/turn, e- yield per lost proton=100] provides 5 turn recovery of EC to 7.5uC proton beam in field free section. Both surface current and line density of EC show the same number of recovery turns Energy range of electrons hitting surface keeps almost same in recovery turns. The amount of carry-over electrons has little effect on the energy range. Same carry-over electrons in PB head of [2 nd turn, p_loss=2E-8/turn] and [3rd turn, p_loss=1E-8]. Difference of EC peaks comes from new primary electrons (Trailing Edge Multipaction). The carry over electrons before PB peak have weaker effect on EC than the new primary electrons after PB peak. 9

Inconsistency of proton loss rate between recovery estimation and prompt-swept slope fit  To perform the simultaneous fit on prompt-swept slopes, we start from the case of [SEY_max=1.7, 7uC beam, p_loss=4e-6/turn]. However, if we try to start from the case of [SEY_max=1.7, 7.5uC beam, p_loss=1e-7/turn], which matches the recovery estimation, we cannot reproduce prompt-swept slopes.  [SEY_max=2.0, 6.3uC beam] has minimum of eCloud (both prompt and swept) in lowering p_loss < 1e-8/turn.  The recovery process may be dominated by other eCloud sources. Now, in our simulation, only primary electrons from lost proton and secondary emitted electrons are considered as eCloud source.  If electrons traveled from quadrupole area to drift space are dominant, the number of recovery turns depends on the traveling time. 10 Y. Sato IU ep workshop 2007

Screening Net/Wire as EC Remedy +V_sc V=0 Net/Wire in longitudinal An idea to reduce the ECE in the vacuum chamber. It is a positive-voltaged screening net on vacuum chamber surface. The thin net is a set of conducting wires longitudinally aligned, close to vacuum chamber surface but apart from it. The geometry should be optimized. A lost proton passes through the net, hits and scratches the chamber surface, and produces primary electrons. The primary electrons are attracted to the net of positive voltage. The following primary electrons also stay around the net. They are going to form an electron cloud layer between the net and chamber surface. Each electron feels the screening effect from the electron cloud layer. Therefore, the effect of potential decrease in the trailing edge of proton bunch is mitigated for these electrons. The net is positively voltaged, while the chamber surface is grounded. 11 Y. Sato IU ep workshop 2007

Conclusions  Longer head beam profile is a possible way to accumulate more protons without making electron cloud larger. Proton bunch ep dynamics should be examined.  Simulated prompt-swept e of constant p_loss and SEY_max reproduces qualitative features, but not quantitative.  Introducing p_loss function to beam intensity is a possible way for quantitative discussion. A possible p_loss function that fits prompt-swept slopes simultaneously is exponential.  Comparing the number of turns of recovery process between experimental data and simulations, proton loss rate of 7.5uC beam is ~ 1E-8/turn for SEY_max=2.0 and ~1E-7/turn for SEY_max= Y. Sato IU ep workshop 2007

Conclusions, cont.  Both of recovery estimation and p_loss function assumption indicates quite low proton loss rate for low beam intensity in field free straight section, and it would hard to cause ep-instability. ECloud kick on proton beam could be mostly non-straight section.  There is inconsistency between the recovery estimation of proton loss rate and the assumption of proton loss rate function of beam intensity is needed. We cannot perform the simultaneous fitting of prompt- swept electron slopes including the point of the parameters estimated by recovery process. We may need additional model of ECloud source.  The actual PSR proton bunch profiles depend on beam intensity. However, this effect does not change prompt-swept electron slopes so much.  Therefore, we need to have other model of ECloud source as shoot electrons from quadrupole area. 13 Y. Sato IU ep workshop 2007

Appendices  Base Classes of Electron Cloud Module (ECM)  ECM Benchmarks  Two stream model  Cold PBunch Simulations  Electron Cloud Experiments in PSR 14

Main Concern of ORBIT Electron Cloud Module: e-p problem Proton beam bunch PSR: ~60 m in 90 m ring SNS: ~200 m in 248 m ring Vacuum Chamber Wall Captured e- before bunch released e- Secondary electrons Lost proton e- born at wall from proton loss Secondary electrons Tertiary electrons Using Electron Cloud Module in ORBIT, we can simulate Two stream instability to captured electrons inside beam bunch (serious source of ECE) Trailing edge multipactor (big source of electrons) multipaction = increase of electrons from secondary e- emission energy gain 15

Electron Cloud Module in ORBIT Code: Simulation Approach Pipe Electron Cloud Region Proton Bunch L=248 m (SNS) and about 1000 turns Simulate: a building up an electron cloud, its dynamics, and its effect on a proton bunch during the whole accumulation period (~1000 turns) or at least for several turns to detect the development of instability. PIC method for both p-Bunch and e-Cloud. Proton beam 3D SC potential grid Electron Cloud Grids with few (one) 2D slices aligned longitudinally 16

Electron Cloud Module in ORBIT Code: Structure ORBIT Code Super Code Interface Modules Original ORBITECloud.cc Original ORBIT C++ Classes EP_Node.cc EP_NodeCalculator.cc E-Cloud Module: Independent C++ Classes - ORBIT Electron Cloud Module The ORBIT E-Cloud Module is a collection of C++ classes. Only three classes connect the E-Cloud module with the original ORBIT code, so the module can be easily modified to use in other acceleration code or independently. 17

Base Classes of the Electron Cloud Module eBunchKeeps 6D – coordinates of the macro-electrons, provides method to add and to delete macro- particles. It has parallel capabilities. EP_BoundaryIt is a 2D SC solver and keeps the transverse 2D grid parameters. Grid3D 3D grid with references to the EP_Boundary class. It has parallel capabilities. The subclasses deal with SC density and potential. Surfaces ClassesCollection of the classes describing different surfaces. Field Source ClassesThe collection of classes specifying electrostatic and magnetic fields. Now it includes p-Bunch, e- Bunch, and uniform fields. TrackerTracks macro-particles by using arbitrary set of field sources. EP_Node EP_NodeCalculator These classes connect the base electron-cloud classes to the rest of ORBIT code. 18

eBunch Class Information ( macrosize, r, p, DEAD/ALIVE ) list of all indexed macroparticle addParticle( macrosize, r, p) deleteParticle( index ) Add or delete macroparticle compress() Keep just ALIVE particles newly indexed print(file2) Dump the information of every macroparticles (among all CPUs) to the ‘file2’ readParticles(file1) Read macro-particles from the ‘file1’ and register them as indexed macroparticles (distributed among all CPUs) MPI: readParticles, print 19

eBunch Class eBunch Class is a resizable container that keeps information about macro-electrons:  6D coordinates – x, y, z, px, py, pz  macro-size  dead/alive flag It provides the following methods to operate with macro-electrons:  access to each of the 6D coordinates  add macro-electron  delete macro-electron  print the all information into a file  create all macro-electrons by reading the external file Its parallel capabilities are used when it reads and writes the content of the electron bunch into or from the external file. We tried to do it as faster as possible. 20

EP_Boundary Class EP_Boundary( (x,y)-grids w/ Boundary ) impactPoint_straightMotion(index, eBunch, r, n) Find impact point on the boundary and calc its normal vector findPotential(ρ(x,y),φ(x,y)) without boundary Calc φ w/ convolution method φ F = ρ F * G F where G(x,y)| grid points = - ln(x^2+y^2) addBoudaryPotential(φ(x,y) ) Add potential from boundary to the grid w/ Capacity matrix method: [Q boundary ]=[C][DV boundary ] 2D Green’s function is adopted because of our main concern on ECloud motion in transverse. Longitudinal force comes from potential gradient. 21

EP_Boundary Class EP_Boundary class :  keeps information about 2D transverse grid and beam-pipe shape and size in the XY-plane ( the shape could be a circle, ellipse, or rectangle)  is a 2D Poisson solver (Convolution method). It has the method that accept a 3D grid with space charge density and returns another 3D grid with potential values at the grid points. Each XY-slice of the potential 3D grid is a solution of the 2D space charge problem for the XY-slice of the space-charge density grid.  uses FFTW library and keeps necessary arrays inside  Can add a boundary conditions (zero potential on the beam-pipe) to the potential 3D grid by using the Capacity Matrix Method  for an electron hitting the surface of the beam-pipe it finds an impact point on the surface and calculates its normal vector by using internal geometry information  does not have any parallel capabilities 22

EP_Boundary Class  FindPotential(ρ(x,y),φ(x,y)) without boundary Calc ρ F from ρ(x,y)| binned in grid points ; G F from G(x,y)| grid points with FFTW where G(x,y)| grid points = - ln(x^2+y^2) spaghetti green function Convolution method φ F = ρ F * G F Calc φ(x,y)| grid points, from φ F with FFTW rfftwnd_one_real_to_complex(planForward_, in_rho_xy, out_rho); Loop for [index]_2D_points //convolution method c_re(out_phi_[index]) = c_re(out_rho[index])*c_re(out_green_[index])- c_im(out_rho[index])*c_im(out_green_[index]); c_im(out_phi_[index]) = c_re(out_rho[index])*c_im(out_green_[index]) + c_im(out_rho[index])*c_re(out_green_[index]); rfftwnd_one_complex_to_real(planBackward_, out_phi_, in_phi_xy_); ρ(x,y)| binned in grid points from ρ(x,y) with interpolation weight [Grid3D class] φ(x,y) from φ(x,y)| grid points with interpolation weight [Grid3D class] 23

EP_Boundary Class  Boundary Potential w Capacity Matrix Method Prepare capacity matrix first, which relates charge and potential on boundary (includes electrode) points, for induced charge. The solution is obtained by solving Poisson’s eq twice. First, solve Poisson’s eq without boundary (by convolution method), and record the difference between the potential without boundary and desired potential on boundary points. The multiplication of the prepared capacity matrix and the difference of boundary potential in array gives the induced charge on boundary points. Then, solve Poisson’s eq again with the induced charge. The way to find capacity matrix is to place unit charge on each boundary point in turn with no charge on other points and solve for the potential. The potential values on boundary points form one column of the inversed capacity matrix. Repeating this process for each of l-th boundary points fills in the l columns of the inversed capacity matrix. Then, the capacity matrix is its inversion. 24

Grid3D Classes Grid3D RhoGrid3DPhiGrid3D The Grid3D class is the parent class for a Grid3D class hierarchy : keeps the 3D array of double values inside itself provides direct access to the 3D array and to the 2D slices calculates a value and gradient at an arbitrary point inside the 3D grid and bins macro-particles by using 3x3 points scheme The parallel capabilities: the Grid3D class has methods that transform it into a distributed 3D grid The RhoGrid3D and PhiGrid3D classes are the subclasses of the Grid3D class and provide methods specific for space charge density and potential grids.... Grid3D 1 Grid3D 2 Grid3D N CPU #1CPU #2 CPU #N Distributed Grid3D 25

Grid3D  3*3*3 point interpolation method binning, weight function 26

Field Source Classes baseFieldSource void getElectricField(double x, double y, double z, double& f_x, double& f_y, double& f_z); void getMagneticField(double x, double y, double z, double& f_x, double& f_y, double& f_z); eCloudFieldSource The source of electric fields from e-cloud pBunchFieldSource The source of electric and magnetic fields from p-bunch UniformField The source of uniform electric and magnetic fields We can create additional sources. For instance, It can be a magnetic field of dipoles, quads etc. 27

EP_Node and EP_NodeCalculator EP_Node – the subclass of the Node class of the ORBIT code: it represents a accelerator lattice element through which the proton bunch should be propagated. there could be an arbitrary number of this nodes in the lattice. Each node has its own set of macro-electrons in the e-bunch. it uses EP_NodeCalculator to propagate the proton bunch through the e-cloud region EP_NodeCalcularor – the class that actually combines all classes together and implements our algorithm 1. preparation for calculation: checking the sizes of the arrays and resizing if necessary proton bunch analysis, fields calculation 2. simulation of the electron cloud build up and the electron cloud field having an effect on the proton bunch 3. applying accumulated kicks from electrons to the protons 28

Algorithm (1) Stage 1. Preparations Proton beam 3D grids (Grid3D) CPU 1 CPU n ….. get information about distribution of the slices between CPUs. This data are provided by a special class – ParticleDistributor resize if necessary 3D arrays: space charge density, space charge potential, x, y, z kicks – 5 distributed 3D grids bin macro-particles of the proton bunch into the 3D space charge density grid. Provide necessary communication between CPUs to produce distributed 3D grid find the proton bunch potential calculates proton line density At this stage we dealing with the proton bunch only. The macro-particles of this bunch are distributed between CPUs. The space charge density grid and proton line density are used in the future calculation if electrons are produced by residual gas ionization or by proton losses on the chamber wall Memory M=N x *N y *N z *5 2000x64x64 x 5 -> 200 Mb – 1 Gb 29

Algorithm (2) Stage 2. Propagation p-bunch through e-cloud During the turn, as time progresses the proton grid is moved through the electron cloud region at the beam velocity. It is done by three nested loops. 1-st nested loop (upper level) T1 step = T rev /N1 step N1 step = 2000 – for PSR or SNS case The number of steps is defined by the requirement adiabatic changes in the electron cloud potential. In the beginning of this iteration, primary electrons are generated by routines simulating protons grazing the vacuum chamber or residual gas ionization. The generated macro-electrons are distributed randomly between CPUs. During the calculations they reside at the same CPU where they have been generated. No macro-electrons distributor is needed. the space charge potential of the electrons is calculated. This potential is sum of all potentials trough all CPUs, so communications between CPUs are needed. This potential is using as one of the field sources for the Tracker. execute the 2-nd nested loop (intermediate level) accumulate kicks on the proton bunch into the grids for x,y,z directions 30

Algorithm (3) 2-st nested loop (intermediate level) CPU 1 CPU n ….. T2 step = T1 step /N2 step N2 step = 1 – 5 The potential of proton beam at the specific position is used to update the proton beam field source for the Tracker. The adiabatic changes in the proton beam potential could be more important, so there is a possibility to update the proton beam field source more frequently comparing to e-cloud field source. Usually it is enough to update fields simultaneously (N2 = 1). This step require communications between CPUs, because the p-beam potential grid is distributed. Stage 2. Propagation p-bunch through e-cloud 31

Algorithm (4) 3-rd nested loop (lower level) Stage 2. Propagation p-bunch through e-cloud (Continue) Inside this loop we integrate the equation of motion of the electrons and consider hitting the surface of the beam pipe. Each electron must be tested to determine whether it remains in the electron cloud region If an electron crosses the beam pipe boundary, the Pivi- Furman electron-wall interaction routines must be run for that electron. If an electron leaves the longitudinal node end, its longitudinal velocity is reflected, i.e. it bounces off the end. Stage 3. Propagation p-bunch through e-cloud We are applying accumulated kicks from electrons to the protons. Electron Cloud Grids T3 step = T2 step /N3 step N3 step = 5 – 20 N total = N1xN2xN3 – tens of thousands 32

Tracker Class baseParticleTracker – the parent class of all trackers The subclasses should implement three methods: two to add magnetic and electric fields sources and the method that will move macro-electrons. We can add as many sources as we want: addMagneticFieldSource(BaseFieldSource* fs) addElectricFieldSource(BaseFieldSource* fs) The main method: moveParticles(double time, eBunch* eb, Grid3D* rhoGrid3D, baseSurface* surface) Where “time” - time of tracking, “eb” – macro-electrons bunch At this moment there are two methods implemented to calculate the nonrelativistic electron’s motion: can be integrated symplectically using a leapfrog method can be integrated analytically, using a constant local field approximation 33

Surface Classes baseSurface void impact(index, eBunch, r, n) A surface class should implement impact method of the abstract baseSurface class. It removes the macro-electron with a particular index from the eBunch and adds the emitted new macro-electrons to the eBunch at the specific point on the beam-pipe surface. We can create easily new surface classes if we need new models. absrbSurface No secondary emission perfectRflctSurface Perfect reflection CntrlSecEmSurface implementation of Furman-Pivi algorithm PRST-AB (2002) Rationale of our implementation of Furman-Pivi algorithm: Furman-Pivi algorithm of secondary emission assumes that all primary and secondary macro-electrons have the same macro-size. As result the number of macro-electrons increases exponentially during the electron cloud build up for single bunched proton beam passage. Calculation time grows significantly, so we wanted to avoid this effect and gained control over the macro-electrons population in the electron cloud. 34

Secondary Emission Surface in ORBIT (x,y)(x,y) (nx,ny)(nx,ny) 35 Removes electron-macroparticle hitting the surface from the electron bunch data Applies a Flexible Monte Carlo scheme to control the number of macroparticles and their macrosize (weight of macroparticle) without changing physics. Adds N newborn (E 0 ) electron-macroparticles using simplified Furman and Pivi’s model each macrosize is multiplied by the secondary emission yield. each energy is determined by 3 type model spectrum with transformation method. The type is determined in the probability of G = random number between 0-1 f death (E 0 ) = user defined function, usually 0 if E 0 > 1 eV N newborn (E 0 ) = user defined function N newborn (E 0 ) times 35

Attachment “different Monte Carlo scheme” (x,y)(x,y) (nx,ny)(nx,ny) 36 We are having different Monte Carlo scheme to control the number of macroparticles and their macrosize (weight of macroparticle) without changing physics feature 36

ORBIT EC Module Benchmarks: Outline 37Y. SatoIndiana University; SNS, ORNL Pipe Electron Cloud Region with few (maybe only one) longitudinal slices Proton Bunch with 3D SC pot. grid Benchmark of electron motion in EM field Benchmark of secondary emission surface model Implementation of Furman and Pivi’s Model with simplifications and flexible Monte Carlo scheme to save calculation time Secondary energy spectrum Electron cloud development in a cold proton bunch Benchmark of two stream model Analytically solvable model of electron-proton instability (effect of eCloud on pBunch) Setup in ORBIT Instability and growth rate 37

Tracker Benchmark Test for 2D solver and the tracker. x y z H E 38

No kick on the proton bunch to compare the results with Pivi and Furman’s PRST-AB (2003) EC peak height is sensitive to SEY The same parameterization with Furman and Pivi’s but the different Monte Carlo scheme from theirs. Thus, this EC development shows sufficient match. E-Cloud Development in ORBIT 39

Field inside coasting proton beam uniform p-bunch radius a Force on a proton 40

Analytically Solvable Electron Cloud Model Ref: D. Neuffer et. al. NIM A321 p1 (1992) uniform p-bunch a p, b p uniform e-cloud a e ~ a p, b e ~ b p 41

Analytically Solvable Electron Cloud Model, cont The relation is valid under linear force inside the streams Assuming harmonic oscillation in both centroid motion the equation of motion become and lead the amplitude ratio and the dispersion relation (no momentum spread): The dispersion relation has complex solutions (instability: growth and damping) for the ep frequency and, slow wave, and satisfies the threshold condition: The larger beam current, the fewer electrons cause instability 42

Two Stream Model in ORBIT To study the two stream model in ORBIT, we use SNS parameters which are most unstable at the longitudinal harmonic number n = 178. For sufficient electron cloud, exceeding the threshold, the dispersion relation for n = 178 has a growth mode as one of 4 roots of : So, if we initialize the electron cloud and proton beam as slow waves with n =178 modulation and proper phase relationship, we can expect EC centroid oscillation to grow. 43

Two Stream Model in ORBIT: Initial EP-streams for Growth Mode The change in the transverse momentum of protons is in perfect agreement with analytic calculations except for the round shoulder To reduce the calculation time, we adopt the periodic structure of L=248m/178=1.393m having 20 longitudinal nodes. Initial proton bunch KV distribution ( R p =30mm ) –needs very (32 points) symmetric structure 0.01mm centroid modulation (slow wave) in vertical direction more than 400,000 macroprotons to satisfy at least 10 particles/grid-cell Initial electron cloud KV distribution ( R e =26mm ) –needs to receive linear force inside p-bunch 400,000 macroelectrons with centroid modulation in vertical direction p-bunch e-cloud 44

Two Stream Model in ORBIT: Centroid Motion in Growth Mode The growth of both electron and proton centroids matches for first several turns. They also shows good match with theoretical amplitude ratio. 10 turns in the periodic structure requires about 10 min in SNS 16 CPUs 45

Two Stream Model in ORBIT: Growth Rate Larger neutralization factor makes e-cloud exceeds p-bunch radius rapidly. Thus, We can apply the analytic two stream model just for the first several turns. Turn by turn, the 1st FFT Harmonic amplitude of the proton bunch centroid oscillation increases. The ORBIT growth rate is ~20% lager than the theory. However, we need to remind that initial centroid modulations are set for analytical model of [Re=Rp=30mm], but we adopt Re=26mm to ensure linear force. Each proton spends outside of the e- cloud in some part of its trajectory. Good match under the regulations. 46

Attachment for “32 points” symmetry x pxpx pypy y 47

Electron Cloud Properties to Cold Proton Bunch Outline ECloud growth to Proton pulse profile (cold proton) The same head p-pulse (tail slope dep.) The same tail p-pulse (trapped electron dep.) Effect of carry-over electrons before peak of ECloud Reproduce PSR results using cold proton pulse in ORBIT: Recovery after “Clearing Gaps” Estimation of proton loss late in ED area Prompt and Swept Electrons Parameter shifting (SEY, proton loss late) Another estimation of proton loss late in EC area as a function of beam intensity 48

PBunch Triangular Profiles: Same Head 120ns PB tail 100ns PB tail 110ns PB tail 90ns PB tail Energy band 250eV-300eV corresponds to SEY peak The energy distribution of surface hitting electrons of off-peak-band reduces ECloud growth 49

PBunch Triangular Profile: Same Tail Effect of primary electrons stored in the head of proton bunch Effect of carry over electrons surviving beam gap 50

PBunch Triangular Profile: ORBIT Results The longer tail of pBunch causes the larger eCloud and its higher growth rate. The steeper tail pBunch gives the higher energy of hitting electrons (E_0 > 250eV) and the lower SEY that may lead the lower growth rate. The carry-over and primary electrons before the peak of pBunch have the (weak) effect of lowering eCloud growth rate. The pBunch effect to drive electrons may be mitigated by the existence of inside electrons during the beginning of pBunch tail slope. To have long head in pBunch profile is a possible way to accumulate more protons in a bunch. 51

Recovery of ECloud: PSR and ORBIT 7.5 uC proton pulse Measured in PSR 4~5 turn recovery of EC peak after swept In ORBIT simulation, 4~5 turn recovery to 7.5uC SEY_max=2.0 Proton loss rate ~1E-8 Both surface current and line density of EC show the same number of recovery turns 52

Recovery of ECloud: Carry-over Electrons and New Primary Electrons Same carry-over electrons in PB head of [2 nd turn, 2E-8] and [3rd turn, 1E-8] Difference of EC peaks comes from new primary electrons (Trailing Edge Multipaction) Energy range of electrons hitting surface keeps almost same in recovery turns. The amount of carry-over electrons has little effect on the energy range. 53

Recovery of EClouds: ORBIT Results To the number of turns of recovery after electron sweeper, we compare our ORBIT simulation with the PSR result. From the comparison, we estimate the proton loss rate in the area of electron cloud detector is around 1E-8 per turn for maximum SEY 2.0. The energy band of electrons hitting vacuum chamber keeps almost same in recovery turns. In eCloud development, the effect of carry over electrons before pBunch peak (electrons inside pBunch) is much weaker than the effect of primary electrons after pBunch peak. 54

Prompt-Swept Electrons: Profile Dependence ~6uC/pulse, prompt e and swept e slopes are flipped in different pulse profiles. ORBIT suggests that a desirable proton profile depends on beam intensity. Actual proton pulse profiles measured in PSR. Now, they seek to have square one. All my simulations for prompt-swept and recovery adopt nonotched profile except for below one. 55

Prompt-Swept Electrons: ORBIT Results The two experimental features: (1) swept electron slope is flatter than prompt electron slope, (2) swept electron slope has saturation in high intensity beam. In ORBIT simulations for constant proton loss rate and constant maximum SEY to beam intensity, the features (1) and (2) are reproduced qualitatively, but not quantitatively. The feature (2) is reproduced only for proton loss rate ~ 4E-6 per turn. To fit experimental slopes of prompt-swept electrons, we assume that proton loss rate is an increase function of beam intensity. The fitting proton loss rate function is exponential. 56

PSR Instability Characteristics BPM  V signal CM42 (4.2  C) (Circulating Beam Current) Bk86, p  s 230  s 345  s ~1000 turns Rapid beam loss follows after high frequency centroid motion on BPM. Vertical difference signals (blue) from a short stripline BPM and beam pulses from a wall current monitor (red) in turn-by-turn.  V oscillation shift from after-peak to center of peak of pBunch in 1000 turns 57

Frequency of unstable motion in PSR Bk85, p140-4 Frequency spectra of the BPM vertical difference signal in unstable motion agrees with two-stream electron-proton model as function of beam intensity. This is a good evidence of e-p instability. Factor 2 difference of beam intensity gives frequency shift by a factor of ~Sqrt[2] as model expects. 58

PSR Layout with EC & e-p Diagnostics Circumference = 90m Beam energy = 798 MeV Revolution frequency =2.8 MHz Bunch length ~ 250 ns (~63 m) Accumulation time ~ 750 ms ~2000 turns ROED/ES1 ED22 ED42 ED51 ED02 ED92 rf buncher ES41 WM41 and WC41 Pinger plates For single turn, just use ES1 For multiple turns, use ES – SNS 59

2002 PSR Parameter List PSR kinetic energy (800 MeV; cp = MeV; γ = 1.853; β=0.842) 60

Frequency spectra of unstable motion agrees with model Bk85, p140-4 Np~2E13 proton/pulse Np~4E13 proton/pulse 61

Well Established PSR Instability Characteristics  Growth time ~ 75  s or ~200 turns  High frequency ~ 70 – 200 MHz  Controlled primarily by rf buncher voltage BPM  V signal CM42 (4.2  C) (Circulating Beam Current) Bk86, p98 Instability Signals 5E13 protons/pulse See Next 62

 Threshold condition when frequency spreads overlap (Landau damping applicable)  R.H.S and L.H.S. for  Q e /Q e constant  Finally, the threshold condition becomes “Explanation” of the linear threshold vs rf voltage curves or Also 63

Turn-by-turn vertical oscillations compared with beam profile during evolution of unstable motion  Vertical difference signals (blue) from a short stripline BPM and beam pulses from a wall current monitor (red).  WM41VD.4B  WC41.4B  Data taken Apr. 14, 1997  Data at t, t+115  s, t+230  s, t+345  s Bk70, p  s 230  s 345  s ~1000 turns You can see the shift of oscillation from after-peak to center of peak. We might reproduce the shift and the beam profile in our ORBIT calculation ( discussion) 64

Cross-section of electron-sweeping detector and its collection region Collector Repeller Grid Pulsed Electrode Slots & Screen 65

Sample Electron Data from Electron Sweeper  Signals have been timed correctly to the beam pulse (wall current monitor)  “Prompt” electrons strike the wall peak at the end of the beam pulse; basically acts a large area RFA until HV pulse applied  Note ~10 ns transit time delay between HV pulse and swept electron signal is expected  Swept electron signal is narrow (~10 ns) with a tail that is not completely understood  May be due to secondaries created at ground screen, walls of slots and repeller screen  Reduced by higher repeller voltage Bk 98, p  C/pulse, bunch length = 280 ns, 30 ns injection notch, signals averaged for 32 macropulses, repeller = - 25V, HV pulse = 500V Beam Pulse HV pulse Electron Signal (prompt electron) Bk 98, p 51 Swept electron signal The same ES (see HV) Check slope between no centroid oscillation and exit c. oscill. Maybe, the overlap of swept time and next pB gives the longer slope 10ns 66

Recovery after “Clearing Gap” of electrons Bk xx, p yy E-sweeper signal Beam Pulse HV pulse 7.5 micro C 67