Maps for electron clouds

The electron cloud effect has been studied by means of detailed simulation codes that typically track the particles' evolution under the influence of the corresponding electromagnetic forces and fields. In this paper we show that, for the RHIC case, the electron cloud can be treated from an abstract point of view as a bunch to bunch evolution using simple maps. Secondly, we show how this treatment yields a useful conclusion, which is otherwise difficult to obtain: for a fixed number of bunches and total beam current in RHIC, it is possible to determine the best way to distribute the bunch pattern around the ring to minimize the electron cloud formation. This application is an example of how maps become a useful tool for exploring the electron cloud evolution in parameter space.


I. MOTIVATION
Electric fields present in many vacuum systems may accelerate electrons (produced by field emission, photoemission, residual gas ionization, etc.) towards the wall chamber surface. If the bombarding electrons acquire enough energy, they produce secondary electrons, which in turn may be accelerated if the electric field normal to the surface is at the correct phase. These electrons may bombard another surface and again emit secondary electrons. This bouncing back and forth between surfaces is the electron multipacting effect. This name, derived from ''resonance of multiple electron impact,'' was first described by Farnswoth in 1934 [1]. If the number of emitted electrons per impinging electron, given by the secondary emission yield (SEY) of the wall surface, is greater than unity, the electron density inside the pipe increases (initially) exponentially, creating a so-called electron cloud (EC). A positively charged beam in an accelerator can produce an EC formation. This EC can eventually lead to the development of vacuum breakdown and other system failures. The proton storage ring of the INP Novosibirsk in 1965 [2] and the ISR at CERN in 1972 [3] are among the first machines suffering from electron clouds. A thorough review of EC effects in accelerators can be seen in Ref. [4].
In the 1990s, electron cloud driven instabilities became an issue in different machines [5]. Several computer simulation codes were (and still are being) developed and compared with experimental observations to study the effect. A comparison among the different codes can be seen in [6]. Typically, these codes work either by particlein-cell methods (like CLOUDLAND) or by tracking electrons grouped into macroparticles, where each macroparticle comprises up to a maximum of around 10 5 electrons (like ECLOUD or CSEC [7]). When a macroparticle produces more electrons, its total Coulomb charge is increased. At every time step, these detailed codes compute the necessary physical forces and fields influencing the motion of the macroparticles. If EC formation takes place, the codes track about 10 10 electrons per meter of beam pipe (depending on the parameters). Hence, these codes use a large amount of CPU time: a complete EC simulation, depending on the input code parameters, can last from around 1 h to some days. In the cases studied here (for the parameters seen in Table I), a single simulation lasts about 1 h.
In the following, we consider that, for given beam pipe characteristics (SEY, chamber dimensions, etc.), the electron density after bunch m passes by (referred to as m1 ) is a function only of the interaction between the bunch and the electron density before bunch m passed by (referred to as m ). This is expressed by means of an iterative formalism. For instance, in a parabolic map where the parameters a and b are functions of beam parameters such as bunch intensity N, bunch spacing s b , rms bunch length z , and rms bunch transverse size t . Ultimately, a and b are functions of the beam pipe characteristics as well: maximum SEY max ; electron energy at which SEY is maximum, E max ; reflectivity at zero electron energy, 0 ; beam pipe dimensions, etc. Therefore, the coefficients a and b summarize the EC dependence on the physical parameters. This parabolic map is sometimes called the ''logistic'' difference equation [8], since by introducing the dimensionless variable X b=a, and for a > 0; b < 0, Eq. (1) can be expressed as which reproduces the logistic map formalism [8] with all its richness. For small , Eq. (1) reflects the exponential growth with the bunch passage [9], where it is clear that the electron cloud takes place for * Electronic address: ubaldo@bnl.gov † Electronic address: peggs@bnl.gov a > 1, and otherwise the cloud collapses. Eventually, this unlimited growth is stopped by the space charge effects created by the electrons themselves. From Eq. (1) in a parabolic mode, the saturated electron cloud density sat is determined as a function of the bunch intensity N simply by sat 0; N < N C or a < 1; where N C marks the bunch intensity threshold for the electron cloud. Equation (1) shows a phase transition from electron cloud ''off'' to ''on.'' If a and b increase smoothly with N, the phase transition is second order. However, RHIC data show both first and second order electron cloud phase transitions [10], which is not yet well understood. The parabolic model of Eq. (1) is a mathematical tool illustrated to express our goal: to simplify the EC problem by using only a small number of mathematical parameters. In this example, these parameters are just a and b.
If the electron cloud evolution can be described using a simple map m1 f m , this frees up the detailed simulation codes and enhances physical intuition through the use of simple maths. Thus, we first need to evaluate whether or not it is possible to follow the electron density in a bunch to bunch evolution (Sec. II), and secondly we look for a suitable function to follow this evolution (Sec. III). Finally, one application of the map modeling is presented (Sec. IV).

II. BUNCH TO BUNCH EVOLUTION
A typical time evolution of the electron density is shown in Fig. 1. This evolution corresponds to a simulation where 60 bunches of 1:4 10 11 protons each, spaced 108 ns apart, are injected into the RHIC ring. In this case the code used is CSEC [11]. The red line shows CSEC output, while the gray circles mark the average electron density between the passage of two bunches. The presence of a bunch is indicated by the black bars at the bottom of the figure, the light blue bars mark an empty bunch. The electron density per beam pipe meter as a function of time grows exponentially until the space charge effects produce a saturation level [9]. Once the saturation level is reached the average electron density does not change significantly. In the bunch to bunch evolution, the time step is one bunch passage. Figure 1 shows that sampling the evolution on a bunch-to-bunch basis is sufficient for retaining information about the buildup and decay times, although the details of the behavior of the electron density oscillation between two bunches is lost. Do existing computer simulations confirm that the electron cloud evolution can be represented by maps? For this purpose, we test this hypothesis using two codes: CSEC and ECLOUD [12], focusing the studies on the RHIC case. Table I shows the physical parameters used for these simulations. Besides the beam characteristics, the SEY behavior as a function of the impinging electron energy is a key ingredient in the electron cloud development. All simulation codes strongly depend on the model used for the SEY behavior [13]. CSEC uses the model described in [14], where one can find detailed explanations of the parameters named in the second part of Table I. On the other hand, ECLOUD uses the model described in [13]. Table I compares only the most ''common'' surface physics parameters. Also, while ECLOUD uses a Gaussian distribution for the emitted secondary electrons, CSEC uses a Lorentzian one (parameter sec in Table I).
With 108 ns bunch spacing and the RHIC revolution period, one can inject up to 120 bunches (not counting the limitations given by the abort gap kickers, which decrease this number to 110). Nevertheless, for the purpose of this study we are interested in the buildup and decay evolution of the electron density, i.e., until the saturation level is reached. Therefore, we performed the simulations for bunch trains of 60 consecutive bunches (until saturation is reached) to minimize CPU time.
The bunch to bunch evolution of the electron cloud density is followed for different bunch intensities N ranging from 8 10 10 to 2 10 11 protons, in steps of N 2 10 10 protons using the parameters listed in Table I. Figure 2 shows how the electron density after bunch m passes by, m1 , behaves as a function of the previous electron density, m , for different bunch intensities N. The points in Fig. 2 show the average electron cloud density between two bunches using results from CSEC (Fig. 2, left) and ECLOUD (Fig. 2, right). The lines correspond to cubic fits with no constant term (see below). Figure 2 is explained as follows: starting with a small seed of electrons, electron density 0 0 nC=m, the density grows and reaches the saturation line ( m1 m , red trace) when the space charge effects due to the electrons of the cloud itself limit further growth. In this situation, all the points (corresponding to the passage of full bunches) are in the same spot, at the 45 line. This particular line, showing m1 m , is also called the identity map. Electron cloud decay is described as the succession of bunches with a null bunch intensity, N 0. Except for the The left plot shows the CSEC output, while the points on the right-hand side come from ECLOUD simulation. In both cases, the lines correspond to cubic fits applied to the average bunch to bunch points. point corresponding to the electron cloud density after the first empty bunch, the electron density follows a universal curve independent of the initial value of the saturated electron density. The ''first empty'' bunch points after the identity map (from different saturation values, sat ) lie off the universal curve on the ''first N 0'' or ''first empty bunch'' curve. This is arguably with the space charge effects during saturation. In other words, it takes two bunches to jump from a curve N Þ 0 to the decay (N 0 curve).

III. MAP CANDIDATES
Different forms for the parametric maps include the above mentioned ''parabolic'' map [Eq. (1)], the ''cubic'' map (with no independent term), and an ''asymptotic'' map, which is also known as the ''Hassell'' model in densitydependent population dynamics [15,16]. Figure 3 shows the results for the 2 coefficient for each fit to the data in Fig. 2, and for each bunch intensity N, for both CSEC (left plot) and ECLOUD (right). Since the smallest 2 value corresponds to the cubic map, we continue the analysis using cubic maps, stating clearly that this map is valid only for electron densities within the ranges used here.
Thus, for the parameters shown in Table I, the electron density buildup for a given bunch intensity is determined by a 3-vectorÃN a; b; c, while decay is described by two 3-vectors, one corresponding to the first empty bunch and a second vector for the rest of them. Figure 4 shows how the buildup coefficients a; b; c evolve as a function of the bunch intensity N for both CSEC (gray points) and ECLOUD (red squares). Both codes give a similar phase transition threshold N C around 7 10 10 protons, when aN C 1. The linear coefficient a becomes larger than 1 when N > N C , and increases linearly in first approximation. In all cases (different N), and using both codes, the quadratic coefficient b is negative. This gives concavity to the electron cloud density evolution in the space ( m ; m1 ) and ensures a positive saturation value [see Eq. (5)]. The b coefficient decreases (increases in absolute value) for CSEC results, but using  ECLOUD results b only decreases for bunch intensities N > 12 10 10 protons. It is surprising that b is not a monotonic function of the bunch intensity. The cubic coefficient c is positive and about 1 order of magnitude smaller than the linear term for N > 10 10 protons. However, both codes differ significantly as we approach the bunch intensity threshold (N < 10 10 protons).
The behavior of these coefficients is not well understood from first principles: the determination of their values is purely empirical. The dependence of these coefficients on the bunch intensity N is derived from electron cloud simulation codes and no analytical expressions have been found so far.

IV. MINIMIZATION OF ELECTRON DENSITY AT RHIC
After experimental observations in RHIC during Run 3 [17][18][19], it is found that the use of gaps along the bunch train can be useful against the buildup of the electron cloud. Since the growth time is longer than the decay time (see, for example, Fig. 1), the goal is to find a bunch pattern around the RHIC circumference that does not trigger the electron cloud or minimizes the detrimental effects of the phenomenon. In the following we use triplets of integers k s ; k b ; k g to describe bunch patterns. k s gives the bunch spacing in buckets (whose length is 36 ns), k b the number of bunches filled with that spacing, and k g the number of ''ghost'' bunches added (i.e., empty bunches that are not filled in and therefore create a gap). Changing patterns can then be described by adding a new triplet. For example, the configuration 2; 2; 13; 4; 0 would correspond to the pattern where 1 denotes a filled bucket and 0 denotes an empty bucket. If not otherwise noted, it is assumed that a pattern repeats until the abort gap is reached. RHIC has 360 buckets, and injection is allowed into every third bucket (minimum), with an abort gap of 30 buckets. This implies a maximum of 110 bunches.
Different distributions of 68 bunches are considered. Figure 5 shows the result of three injection attempts with three different bunch patterns: 3; 16; 4, 3; 12; 8, and 3; 14; 6. Even though pressure rises are detected for the first two cases and not for the third one (see pressure rise at the blue section in Fig. 5, bottom), we can inject up to 68 bunches using the configuration 3; 12; 8, whereas injection of bunch pattern 3; 16; 4 cannot be completed. A comparison among the three cases is complicated by the fact that bunch intensity and bunch length are not the same for all fills. Figure 5 also shows that the attempt to fill bunch pattern 3; 14; 6 was successful, but it is not taken into account for this study because the bunch length was twice that of the previously attempted fills. Bunch intensity and length are comparable for fills 3; 16; 4 and 3; 12; 8, which also show similar vacuum behavior. On the other hand, the larger bunch lengths for fill 3; 14; 6, together with the reduced bunch intensity, can account for the suppression of ECs. Table II summarizes the characteristics of the different cases and compares the relative luminosity.
Reference [17] studies the effect of the bunch pattern on the EC and pressure rise. Several computer simulation runs were launched with different bunch patterns. The two criteria to minimize the effects of the electron cloud were the average and the maximum value of the electron density created by each bunch pattern. The conclusion consistent with the experience at B factories [17] is that the most sparse distribution of bunches is the best way to optimize luminosity. However, since one CSEC  pattern (3,16,4) pattern (3,12,8) pattern (3,14,6) blue beam yellow beam FIG. 5. (Color) Attempts to fill RHIC with three different bunch patterns: 3; 16; 4, 3; 12; 8, and 3; 14; 6. The top plot shows the total intensity in the ring, while the bottom plot shows the pressure in one of the unbaked warm regions at RHIC (blue vacuum). Unlike the first attempt (3,16,4), the injection in the second case 3; 12; 8 does not prevent machine operation although the pressure rise is noticeable. The third case 3; 14; 6 is not taken into account due to an unusually large bunch length.

A. Simulations for different bunch patterns
The simulation code MEC uses a cubic interpolation map to follow the bunch to bunch evolution of the electron cloud density. Simulations of different bunch patterns carried out with CSEC and reported in [17] are compared using MEC in this section. The parameters used by CSEC are reported in Table I, but in this case we fix the bunch intensity at N N 0 8 10 10 protons.
The use of MEC is divided into four cases, depending on the intensity of the bunches m and m ÿ 1 passing by.
(i) First ''full'' bunch, which denotes a full bunch after an empty one, i.e., N m N 0 and N mÿ1 0, with cubic map coefficients represented by the vectorÃ 10 a 10 ; b 10 ; c 10 .
(ii) Full bunches, denoting the passage of a bunch with N m N 0 protons after another full bunch, N mÿ1 N 0 . The cubic map coefficients for this case are denoted bỹ A 11 a 11 ; b 11 ; c 11 .
(iii) First empty bunch, an empty bunch after a populated bunch, i.e., N m 0 and N mÿ1 N 0 . The corresponding cubic map coefficients are represented byÃ 01 a 01 ; b 01 ; c 01 .
(iv) Empty bunches, succession of bunches with intensity N m 0 and N mÿ1 0. The corresponding cubic map coefficients are denoted byÃ 00 a 00 ; b 00 ; c 00 .
The need for this subdivision requires analysis of two figures: in Fig. 2 one can see that the first N m 0 is out of the evolution of the decay curve, i.e., the curve corresponding to ghost bunches. Figure 6 justifies the case for the first N m N 0 curve. Figure 6 shows that the transition from empty to full also requires two bunches, in the same way that the transition from full bunch to empty bunch is done in two bunches.
One obtains successful results when comparing the bunch to bunch evolution using CSEC and MEC; see Fig. 7 with the different bunch patterns. Table III compares the maximum and average values for the linear electron cloud density at the last turn using CSEC and MEC. The largest difference for the maximum density is about 15% [corresponding to the case 3; 2; 06; 4; 0]; while for the average density the maximum difference is about 17%, corresponding to the case 3; 23; 17. While CSEC uses about 1 h CPU time for each case, MEC is obviously much faster and uses only 1 ms, which represents a speed up of 7 orders of magnitude.

B. Linear approximation
Four sets of polynomial coefficients,Ã 11 N,Ã 01 N, A 00 N, andÃ 10 N, are required to follow the bunch to bunch evolution of the electron cloud density in MEC. Figure 6 suggests that for small electron densities the bunch to bunch evolution can be considered as linear in the ( m ; m1 ) space. That is, if there is a total number of M bunches in a ring with a ''bunch harmonic'' number of H, the linearization of the problem gives a one turn map that is simply mH FN m ; (8) where the ''one turn factor'' is and vice versa. Since Eq. (11) is valid for RHIC parameters, the most sparse distribution of a fixed number of fixed population bunches is the most stable against electron cloud growth. Thus, from the mapping approach and using a linearized approximation we have demonstrated that the most sparse distribution of bunches in RHIC minimizes the detrimental effects of the multibunch electron cloud effects. This is not a big surprise if we consider the possibility of evenly distributed bunches, i.e., the same bunch spacing between all bunches. In this case, the most sparse distribution of bunches is equivalent to using a larger bunch spacing between them. However, Eq. (10) demonstrates that this is also valid for unevenly spaced bunches along a bunch train. This ''rule of thumb'' has been used in the RHIC operation when deciding the bunch pattern to inject [20,21].

V. SUMMARY
Multibunch electron cloud buildup at RHIC is modeled by simple maps. A third order polynomial map, written as A a; b; c, optimally reproduces the bunch to bunch evolution. For a given vacuum chamber, these coefficients are a function of the beam parameters. These parameters, a; b; c, as a function of the bunch intensity N are empirically determined from electron cloud simulations codes, like CSEC or ECLOUD, as a function of the bunch intensity N.
When jumping back and forth from full to empty bunches, a memory of two bunches is found to be necessary. Therefore a complete algorithm requires four vectors: A 11 ,Ã 10 ,Ã 00 , andÃ 01 . A simulation program, MEC, uses these vectors to reproduce (within about 15%) the evolution of the electron density in a bunch to bunch approximation. The CPU time used in this case is 7 orders of magnitude smaller than that used by the conventional electron simulation codes (CSEC or ECLOUD).
The importance of this analysis lies not only in the acceptable reproducibility of the results using MEC, but also in the ability to abstract the way to tackle electron clouds. This helps to deliver conclusions that would otherwise be difficult to obtain. For instance, using the linearized maps, actual values for the vectors analytically demonstrate that, for the straight sections of RHIC, the most sparse distribution of bunches is the most stable against electron cloud formation, even when they cannot be evenly spaced.
In the future, it is desirable to explore how the polynomial coefficients vary as a function of the physical parameters influencing the electron cloud (SEY, chamber dimensions, bunch spacing, bunch charge, etc.) in order to obtain a better understanding of the problem. Application of maps to other machines, like B factories or the LHC, is also necessary to study the universality of map formalism.