Electron Cloud - Status and Plans

1
Electron Cloud - Status and Plans
US LHC Accelerator Research Program
bnl - fnal- lbnl - slac

• Miguel A. Furman
• LBNL
• mafurman_at_lbl.gov
• Collaboration Mtg.
• FNAL, April 18-20, 2007

2
Summary

• Assessment of ecloud for upgraded LHC and
  injectors
• With build-up code POSINST (no effects on the
  beam)
• Effects on the beam
• With code WARP/POSINST
• Quasi-static mode QSM
• Lorentz-boosted frame method
• Progress towards full self-consistency
• RHIC measurements
• Status and future goals

3
Assessment of ecloud buildup for LHC upgradeand
injectors

• Initial results for injectors presented at
  LUMI06
• Substantial improvements since then
• Numerical convergence required in some cases up
  to 500 kicks/bunch (integration time step
  Dt3x1011 s)
• ecloud much more benign than initial estimate
• Limited investigation
• Bunch spacings tb12.5, 25, 50, 75 ns
• Dipoles only
• Eb, Nb, sz fixed according to FZs files
  psplusetcparameters and lhcupgradeparameters
• Example
• PS2 (Eb50 GeV) vs PS (Eb75 GeV)

Nb depends on tb
tb ns 25 50 75
Nb 1011 4 5.4 6.6
4
Assessment of ecloud buildup for LHC upgrade and
injectors conclusions

• Heat load depends inversely with tb both for LHC
  and injectors
• tb75 ns is best, closely followed by 50 ns
• tb50 ns much better than 25 ns
• tb12.5 ns is terrible
• Cu (or Cu-coated) chamber much better than St.St.
• But this conclusion is premised on a particular
  set of measurements of the SE energy spectrum for
  St.St.
• Need to re-measure energy spectrum in order to
  verify this conclusion
• Not much difference in heat load between gaussian
  vs. flat longitudinal bunch profile for the LHC,
  at least for tb50 ns
• Not much difference between PS2 and PS, nor
  between SPS50 and SPSa50, except at high dmax
  for tb25 ns
• See my LUMI06 proceedings paper (not my PPT file)
  
• A full, definitive report is forthcoming
• Caveats
• So far, heat load in the dipole bends only
• sz, Nb, not independently exercised

5
Ecloud effects on the LHC beamcode WARP, QSM
approx.

• Recent example of emittance growth
• Assume re1014 m3
• E450 GeV, Nb1.1x1011, single bunch
• Code WARP, parallel, 3D calc.
• Quasi-static approx. mode (QSM)
• AMR, parallel 8 processors
• Beam transfer maps from EC station to next
• Up to 6000 stations
• Actual LHC chamber shape
• Constant focusing approx.
• Conclusion need to resolve lb to reach
  convergence, as expected (ie., no. of EC stations
  gt tune)
• More studies to come
• Actual optics, vary re, vary Nb, etc
• Look at instability, not simply emitt. gr.,
  multibunch, more self-consistency
• Benchmark against CERN results!

6
RHIC studies

• Two CERN e detectors installed in RHIC
  common-pipe region gt1 yr ago
• Inside a weak adjustable dipole magnet
• Electron detectors installation was not a
  LARP-funded effort (M. Jiménez, CERN VAC)
• But LARP funds simulation benchmarking activity
• Simulations carried out thus far have been
  problematic
• Partly due to code problems (now believed fixed)
• Partly due to complexity of two coexisting beams
  in common-pipe region
• Detectors now interfaced to the RHIC control
  system (Eric Blum, BNL)
• Improved power supply for the magnets
• No useful results at present
• I look forward to results in the near future

7
Towards full self-consistency Lorentz-boosted
frame method

• Fully self-consistency (FSC)
• Beam and ecloud affect each other
• Beam-gas ionization, secondary electrons, lost
  protons striking wall, etc
• This is a formidable problem
• Well approach it step by step
• In the end, probably use FSC only as spot-checks
  on simpler, faster calculations
• But all necessary modules already in code WARP
• Essential computational problem in ecloud wide
  disparities of time scales needed to resolve e
  motion, proton motion and lattice (eg., betatron
  wavelength)
• Found that self-consistent calculation has
  similar cost than quasi-static mode if done in a
  Lorentz-boosted frame (with ?gtgt1), thanks to
  relativistic contraction/dilation bridging
  space/time scales disparities (J. L. Vay, with
  partial LARP support)
• Computational complexity is not a Lorentz
  invariant (for certain problems)

8
Boosted frame calculation sampleproton bunch
through a given e cloud

• Hose instability of a proton bunch
• gb500 in Lab
• L 5 km, continuous focusing
• Mag. field Bqkr
• No chamber
• Nb1012
• re1013 m3

electron streamlines
beam
proton bunch radius vs. z

• CPU time
• lab frame gt2 weeks
• frame with ?2512 lt30 min

Speedup x1000
J.-L. Vay, PRL 98, 130405 (2007)
9
Boosted frame calculation sampleproton bunch
through a given e cloud
Courtesy J.-L. Vay
10
Lorentz-boosted method my concerns

• Added complications
• moving boundary conditions
• non-rectilinear moving frame (in curved
  trajectories)
• sort out simultaneity of events for useful Lab
  frame diagnostics
• Need to be understood and implemented
• Real-life simulation case not yet available
• But clear indications of breakthrough in
  self-consistent simulations

11
Related developments (outside LARP scope, but
synergistic)

• ecloud at the FNAL MI upgrade (HINS effort)
• Direct e measurements with RFA at the MI (R.
  Zwaska)
• Interesting effects at transition (shortest sz)
• Also ecloud evidence at the TEVATRON (X. Zhang)
• In parallel, simulations at LBNL of
• ecloud build-up at MI code POSINST
• Extensive (but still ongoing) studies
• Qualitative agreement w/ measurements
• Quantitative theres a fly in the ointment (to
  be understood)
• Effects on the beam (emittance growth,
  single-bunch and multibunch inst.) code WARP
• Microwave transmission technique (F. Caspers T.
  Kroyer) code VORPAL
• Hopefully new experiments at PEP-II will help to
  calibrate

12
More related stuff

• ECLOUD07 (Korea, last week)
• Significant new effort reported from KEKB
  dedicated SEY equipment
• SEY of metals condition down to dmax1 (Cu, StSt,
  TiN, TiZrV)
• When bombarded with 5 keV e beam (dose 0.011
  C/cm2)
• Graphitization of the surface (XPS analysis)
• Also tested 500 eV e beam bombardment will redo
  at 100 eV
• Also measured ecloud conditioning by ecloud in
  the e beam
• Results slightly less favorable
• Synchrotron radiation spoils graphitization
  (consistent with PEP-II tests)
• Some of these new results seem at odds with
  previous from CERN SLAC
• Why do existing machines still have an ecloud
  problem?
• (they would not if dmax1)

13
Status summary and future goals

• Nominal LHC heat-load estimate and POSINST-ECLOUD
  benchmarking () done
• Upgraded LHC heat load () done
• Upgraded injector upgrade heat load () done,
  but beam parameters not independently exercised
  (only certain SEY-related parameters varied)
• Effects from ecloud on beam () recent initial
  results, after substantial code development
• 3D beam-ecloud self-consistent simulations
  continuing
• AMR, QSM, adaptive time stepping,
  parallelization implemented in code
• Development of Lorentz boosted frame method
  proof of principle exists needs more
  developments for realistic applications
• Effects of ionized gas on heat load and beam not
  started
• Analyze SPS data, esp. measured heat load and e
  spectrum () first set of results need to
  benchmark against expts.
• Help define optimal LHC conditioning scenario
  () not started delayed in favor of 2, 3 and 4.
  This is our intended next task this year in the
  area of ecloud buildup.
• Apply Iriso-Peggs maps to LHC () ongoing at low
  level should it be deleted from LARP list?
• Quick understanding of global ecloud parameter
  space, phase transitions
• Simulate e-cloud for RHIC detectors and benchmark
  against measurements () continuing
• Simulate ecloud for LHC IR4 pilot diagnostic
  bench not started

() endorsed by CERN AP group () endorsed by
CERN vacuum group
() no longer endorsed by CERN AP group
14
Additional material
15
Quasi-static mode (QSM)
2-D slab of electrons
3-D beam
s
lattice
s0

• 2-D slab of electrons (macroparticles) is stepped
  backward (with small time steps) through the
  frozen beam field
• 2-D electron fields are stacked in a 3-D array,
• push 3-D proton beam (with large time steps)
  using
• maps - WARP-QSM - as in HEADTAIL (CERN) or
• Leap-Frog - WARP-QSL - as in QUICKPIC
  (UCLA/USC).

16
Benchmarking WARP-QSM vs. HEADTAIL
CERN code benchmarking website
1 station/turn
Emittances X/Y (?-mm-mrad)
Time (ms)
2 stations/turn
Emittances X/Y (?-mm-mrad)
Time (ms)