1 / 25

Electron-Cloud Codes Panel Discussion: Future Software Development and Benchmarking

This panel discussion focuses on the future of electron-cloud simulation codes, including what new information they should provide, missing physics to include, extending existing tools, the need for a common web code repository, code improvements, and quantifying code reliability. The goal is to address performance limiting issues and achieve reliable predictions in accelerator design.

mcude
Download Presentation

Electron-Cloud Codes Panel Discussion: Future Software Development and Benchmarking

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Summary electron-cloud simulation codes panel discussion Frank Zimmermann

  2. overview of electron-cloud simulation codes M. Furman electron-cloud panel members • Adelmann, GSI • G. Bellodi, CCLRC/Astec/Rutherford • M. Furman, LBNL • K. Ohmi, KEK • M. Pivi, SLAC • G. Rumolo, GSI • D. Schulte, CERN • J. Wei, BNL • F. Zimmermann, CERN

  3. Panel discussion"Electron-Cloud Codes“ 1. What information should future codes provide that cannot be be obtained from today's codes? 2. Which missing physics should they include? 3. Do we need entirely new software packages or would it be sufficient to extend existing tools? 4. Would a common web code repository be helpful to the community and, if yes, what features should it include? 5. Which codes are you using and which improvements to these would you suggest? 6. How can we quantify the reliability of the code predictions? 7. Which kinds of benchmarking between codes and between simulations and experiments are needed or desirable?

  4. Goals • Codes should help address performance limiting issues: • Vacuum pressure rise (RHIC) • Instabilities (PSR) • Emittance growth • Jie Wei • Ultimate goal: reliable predictions • Miguel Furman • Predict conditions before an accelerator is built • Daniel Schulte

  5. Ohmi san’s challenge: simulate KEKB observations - sideband & relaxation oscillation (open issue) - multibunch instability (done, at KEK)

  6. Fourier power spectrum of BPM data Synchrotron Tune V. Tune Sideband Peak 100 Bunch 1 • LER single beam, 4 trains, 100 bunches per train, 4 rf bucket spacing • Solenoids off: beam size increased from 60 mm ->283 mm at 400 mA • Vertical feedback gain lowered • This brings out the vertical tune without external excitation 0.5 Tune 1.0 single-bunch effect!?

  7. Time series data BPM Data (Position) PMT Data (Size)

  8. coupled-bunch modes Vertical Simulation Experiment 4 3 x 10 x 10 5 Horizontal Vertical 3 4 Horizontal 3 2 2 1 1 1.2 0.4 0 0 0 200 400 600 800 1000 1200 1400 0 200 400 600 800 1000 1200 1400 Mode Mode Mode 0.3 0.8 0.2 0.4 0.1 0 0 200 400 600 800 1000 1200 1400 0 Mode 0 200 400 600 800 1000 1200 1400 KEKB Solenoid-Off Su Su Win et al,(EC2002)

  9. Simulation 6 Experiment Solenoid-10 G x 104 2 Horizontal 4 1.5 Horizontal 2 1 0.5 0 0 1500 0 200 400 600 800 1000 1200 1400 Mode 5 Solenoid-10 G Vertical 4 1000 Vertical 3 500 2 1 0 0 200 400 600 800 1000 1200 1400 0 Mode 200 400 600 800 1000 1200 1400 0 0 200 400 600 800 1000 1200 1400 Mode Mode KEKB Solenoid-ON Su Su Win et al., EC2002

  10. Types of codes Lawrence Berkeley National Laboratory • EC buildup codes: • beam is prescribed (not dynamical, except possibly for multibunch dipole motion) • electrons are dynamical (macroparticles) • vacuum chamber geometry, various electron sources • Instability codes: • e-cloud is prescribed, at least initially; either lens or particle cloud • beam is dynamical (macroparticles) • Self-consistent codes: • various degrees of self-consistency • both beam and e-cloud are dynamical • typically 3D ; may accept an input lattice description • may or may not describe e-wall collisions (SEY) • ultimately: model gas desorption, photoelectric effect, ionization, stray particles/wall collisions, secondary ionization • Map code (MEC) (later) M. Furman modified

  11. Code table (incomplete; possible errors) Lawrence Berkeley National Laboratory SR=synchrotron rad. photoelectrons; SE=secondary electron emission; IZ=ionization of resid. gas; BPL=beam-particle losses SC=self-consistent; modified

  12. CERN code comparisons centerhttp://wwwslap.cern.ch/collective/ecloud02/ecsim/ Lawrence Berkeley National Laboratory • Established by F. Zimmermann after ECLOUD’02 • updated in summer 2004! • Input parameters for “standard” test cases are spelled out • Everybody is invited to contribute! modified

  13. Contemporary developments Lawrence Berkeley National Laboratory • Do we need self-consistency? • Yes, in some cases: • At PSR, electron-cloud signal is 10-100 times larger for unstable beam than for stable • Do we need the 3rd dimension? • Yes, for long bunches (PSR)(see PSR quad movie) • Probably yes for long bunch trains and long/complicated machine lattices modified

  14. 3D development in CLOUDLAND (Lanfa Wang) • Improved the model of the interaction between beam/electron and beam pipe. (such as the backscattered electron from the stripped electrons). And plan to import a more realistic model. • Three-dimensional geometries have been modeled for a few of typical cases, such as electron catcher near the stripping foil. Good catch Bad catch

  15. Possible future developments 1 Lawrence Berkeley National Laboratory • More “benchmarking” • debugging (code should calculate what is supposed to calculate) • validation (results should agree with established analytic result for specific cases) • comparisons (two codes should agree if the model is the same) • verification (code should agree with measurements) • ECLOUD simulations vs. SPS measurements • POSINST simulations vs. APS and PSR measurements • Others… difficult, few analytical results– highly nonlinear problem build up codes agree within a factor 2-3, or better; often larger differences for instability codes in progress, promising results modified

  16. build-up simulations with various codes

  17. same code, different SEY models five different parameterizations of elastic electron reflection (left) and corresponding ECLOUD simulation results (right). G. Bellodi

  18. instability simulations with various codes

  19. Some recommendations for benchmarking: • MAD type files as input • Database and set of standard models for the secondary electron emission: SEY and secondary energy spectrum. Differences arise when assuming different models. • Common repository code with a frozen version • Common public version of e-cloud codes maintained underCVS instead of 100s private ‘development’ versions; continuous update of code version on the web and corresponding manual • Bank of experimental data from observations at different machines(like SPS and PSR);tune models adopted to reproduce specific measurements • Several primary e- sources at same time (easy to add) • Further comparisons of instability simulations; understanding of ‘slow emittance growth’ • In-situ surface measurement at same location; or laboratory measurements where all conditions are controlled • Model detectors or “relative measurements”

  20. various e-cloud web sites with information http://wwwslap.cern.ch/collective/electron-cloud.html LHC e-cloud http://wwwslap.cern.ch/collective/ecloud02/ecsim/index.html code comparison http://www.aps.anl.gov/asd/physics/ecloud/papers_top.html APS e-cloud studies http://at-div-vac.web.cern.ch/at-div-vac/VACPAGES/PT/Phys&Tech/Phys/ Ecloud/Ecloud.html LHC vacuum & electron cloud http://www.isi.rl.ac.uk/AcceleratorTheory/ecloud/index.html ISIS/RAL ecloud http://www-projec.slac.stanford.edu/ilc/testfac/ecloud/elec_cloud.html SLAC ILC e-cloud

  21. Possible future developments 2 • Move in 2 opposite directions: • Simplified descriptions, few parameters, qualitative results with broad applicability • Identify a few basic relevant variables and input parameters (MEC code very promising in this regard) • More complete, detailed, quantitative predictions • Ultimately requires fully self-consistent 3D calculations • New computing issues (parallel computing, modern algorithms, numerical collisionality, round-off errors,…) “asymptotic thinking” G.Bellodi

  22. A map code (“MEC”) Lawrence Berkeley National Laboratory simpler! Relate ecloud density at time t to density at t-Dt by a heuristic nonlinear map U. Iriso, ECLOUD’04 relies on more detailed codes to determine map coefficients

  23. Adelmann • simulate • LHC FODO cell • or ILC wiggler • in 3D, e.g., • using code • PARSEC

  24. Self-consistency plan Lawrence Berkeley National Laboratory more complete! roadmap for WARP+POSINST R. Cohen, ECLOUD’04 modified

  25. ion desorption, ionization regular instability code vacuum code ion code electron desorption, scrubbing, “e- pumping” beam- beam code ionization E(x,t) self-consistent code e-cloud SB/ CB instability code s.c. code e-cloud build up code re beam motion, losses E(x,t), B(x,t) beam sizes apertures, B fields, … ‘ecloud wake’, generalized impedance cloud density, local growth rates, around the ring or ‘from DR to IP’ (M. Pivi), “ECLOUD TWISS TABLE”, incl. 3D e- motion wake/impedance code, e.g., HFSS, MAFIA, GdfidL optics code e.g., MADX future ‘complete’ e-cloud simulation?

More Related