1 / 19

ORBIT

FNAL: September 11, 2001. ORBIT. J. A. Holmes ORNL. Colleagues, Collaborators, Contributers. SNS, ORNL S. Cousineau, V. Danilov, J. Galambos, J. Holmes BNL J. Beebe-Wang, M. Blaskiewicz, A. Luccio, N. Malitsky, A. Shishlo TRIUMF F. Jones FNAL J. MacLachlan. Motivation for ORBIT.

kenaz
Download Presentation

ORBIT

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. FNAL: September 11, 2001 ORBIT J. A. Holmes ORNL

  2. Colleagues, Collaborators, Contributers • SNS, ORNL • S. Cousineau, V. Danilov, J. Galambos, J. Holmes • BNL • J. Beebe-Wang, M. Blaskiewicz, A. Luccio, N. Malitsky, A. Shishlo • TRIUMF • F. Jones • FNAL • J. MacLachlan

  3. Motivation for ORBIT • High intensity proton rings such as FNAL Booster, AGS Booster, PSR, and SNS are characterized by low energy, high beam intensity, and low beam loss requirements for high availability. • These requirements of high intensity and low losses necessitate a detailed understanding of beam dynamics in this regime. • Under these conditions collective effects due to space charge and wakefields will strongly affect the beam behavior, and single particle models alone will not apply. • Because of the complexity of collective phenomena for bunched beams in high intensity rings, a computational approach is productive.

  4. ORBIT History • In response to this need, the SNS AP group at ORNL, with help from BNL colleagues, developed the ORBIT code. • We started with ACCSIM (provided by Fred Jones of TRIUMF) as the core to build a beam dynamics code around, but decided to begin again with an object-oriented approach. The basic classes are herds and nodes. Nodes operate on herds. • ORBIT began as a C++ rewrite of ACCSIM, developed under the SuperCode driver shell, but has since undergone extensive independent development. • With the completion of the 3D spacecharge routine, ORBIT has become a good candidate for massively parallel computing. • Because of the parallel computing need and the desire to inherit sophisticated mapping and general error treatment capabilities, ORBIT is now being included into the Unified Accelerator Libraries (UAL).

  5. ORBIT: General Description and Approach • ORBIT is a particle (herd)-tracking code in 6D phase space. • ORBIT is designed to simulate real machines: it has detailed (node) models for • transport through various types of lattice elements • injection foil and painting • RF and acceleration • 2.5D space charge with or without conducting wall beam pipe • longitudinal impedance and 1D longitudinal space charge • Transverse impedance • 3D space charge • apertures and collimation • ORBIT has an excellent suite of routines for beam diagnostics.

  6. ORBIT: Particle-Tracking in 6D Phase Space • ORBIT coordinates utilize the usual accelerator expansion • Transverse phase space horizontal x, x_prime • Transverse phase space vertical y, y_prime • Longitudinal phase space phi, dE • The coordinates are taken with respect to a reference particle on a reference closed orbit. • The independent variable is the machine location s. This has interesting implications in the representation of 3D space charge and transverse impedance.

  7. ORBIT: Transport Through Lattice • ORBIT lattices can be constructed by reading MAD or DIMAD output files. There are also special facilities to specify lattices directly or to create uniform focusing channels. • Linear transport through drifts, bends, or quadrupoles is carried out through symplectic matrix multiplication. • Nonlinear elements, such as higher order multipoles, are evaluated in the thin lens approximation. • Higher order single particle transport terms, such as chromaticity, are evaluated using second order transport matrices. • There is no specific facility for the treatment of errors. • Inclusion of ORBIT in UAL will alleviate these last two shortcomings.

  8. ORBIT: Injection and Foil • ORBIT can inject particles turn-by-turn or utilize a complete distribution from the start. • A variety of distributions can be generated internally. • Any externally generated distribution can be read in. • Injection painting schemes can be simulated by time-dependent closed orbit bumps. • ORBIT contains an injection foil model taken from ACCSIM. Not all of the ACCSIM model physics has been implemented. • At present, the model keeps track of foil hits and applies transverse kicks based on multiple Coulomb scattering. • Particles that miss the foil at injection are removed from the beam.

  9. ORBIT: RF and Acceleration • ORBIT contains an RF cavity model which provides longitudinal kicks based on a time-dependent waveform with multiple user-specified harmonics. • For nonaccelerating cases, the synchronous phase is assumed to be zero, and the harmonics and time-dependent voltages are all that need to be specified. • For accelerating cases, the harmonics, time-dependent voltages, and time-dependent dipole fields must be specified. • The synchronous phase and the resulting kicks are then solved by the model. • Transverse phase space is adjusted to conserve normalized emittance.

  10. ORBIT: 2.5D Transverse Space Charge • Particles are binned in 2D rectangular grid • 2nd order momentum-conserving distribution of charges to grid (see Hockney and Eastwood) • Potential is solved on transverse grid • Fast FFT solver is used • Conducting wall boundary conditions (circular, elliptical, or rectangular beam pipe) • Particle kicks are obtained by interpolating the potentials • 2nd order momentum-conserving interpolation scheme is used (see Hockney and Eastwood) • Kicks are weighted by the local longitudinal density to account for bunch factor effects • There is also a free space direct force solver without beam pipe.

  11. ORBIT: Longitudinal Impedance and Space Charge • ORBIT treats longitudinal impedances and/or space charge in a similar fashion as ESME. • The longitudinal impedance is represented by its harmonic content in terms of the fundamental ring frequency. • Particles are binned longitudinally. • The binned distribution is Fourier transformed. • The space charge contribution to the impedance is combined with the external impedance. • The Fourier transformed distribution is multiplied by the impedance and the results applied to give longitudinal kicks to the particles. • Typically (for SNS anyway), it is sufficient to evaluate the longitudinal impedance and space charge kicks once each turn, since the synchrotron period is more than a thousand turns. More evaluations may be required for applications with higher synchrotron frequencies.

  12. ORBIT: Transverse Impedance Model • Transverse impedance treated as localized node in ORBIT • Element length must be short compared to betatron oscillation wavelength • If physical impedance is not short, multiple impedance nodes are required • Impedance representation • User inputs Fourier components of impedance at betatron sidebands of the ring frequency harmonics • Velocities less than light speed included in formulation • Particle kicks • Convolution of beam current dipole moment with impedance • Current evaluation assumes dipole moment evolves from previous turn according to simple betatron oscillation

  13. ORBIT: 3D Space Charge Model • Particles are binned in 3D rectangular grid • 2nd order momentum-conserving distribution of charges to grid (see Hockney and Eastwood) • Typically, for rings, longitudinal spacing greatly exceeds transverse spacing • Potential is solved on transverse grid for each longitudinal slice • Fast FFT solver is used • Conducting wall boundary conditions (circular, elliptical, or rectangular beam pipe) “tie together” the transverse solutions • Particle kicks are obtained by interpolating the potentials in 3D • 2nd order momentum-conserving interpolation scheme is used (see Hockney and Eastwood)

  14. ORBIT: Apertures and Collimation • Apertures can be defined in ORBIT. • The apertures can be circular, elliptical, or rectangular. • The apertures can be set either to allow particles to pass through and simply tabulate the hits, or • to remove the particles from the beam and tabulate the locations. • A collimation model has been added to ORBIT. • In addition to the aperture shapes, the collimators can include single or combinations of edges at arbitrary angles. • Physics includes multiple Coulomb scattering, ionization energy loss, nuclear elastic and inelastic scattering, and Rutherford scattering. • Monte Carlo algorithms are used for particle transport inside the collimator, and step sizes are carefully adjusted near collimator boundaries.

  15. ORBIT: Diagnostics • A list of useful diagnostics in ORBIT includes the following: • Dumps of particle coordinates. • Dumps of particle tunes. • Dumps of particle emittances. • Histograms of particle distributions in x, y, phi, and emittance. • rms emittances versus turn or versus position • Beam moments versus turn or versus position • Statistical calculation of beta functions • Longitudinal harmonics of the beam centroid

  16. Where We’ve Been: Typical High Intensity Ring Tracking Simulation, SNS Injection. • Linear transports. • Nonlinear 2(+) D transverse space charge, evaluated using periodic FFT solver with 128 x 128 grid, as described by Hockney and Eastwood. • Longitudinal dynamics including RF and longitudinal space charge. • Beam accumulation ~1000 turns. • Inject ~200 macroparticles / turn -> 200K macroparticles at finish. • ~300 linear transports / turn interspersed with nonlinear space charge kicks. • Run time ~6 hours on my laptop (650 MHz Pentium III).

  17. Where We’re Going: New Physics in High Intensity Ring Tracking Code. • Impedance models - longitudinal and transverse. • Longitudinal involves straightforward combination with longitudinal space charge. • Transverse requires dipole moment of current resolved along the bunch. Proper treatment of space charge in presence of transverse impedance requires • 3D space charge model. • This involves binning the beam longitudinally. • Each bin will contain a complete 2D space charge solution. • Higher order maps (nonlinearities) in particle transport. • This will increase time for transports. • Error terms. • This will increase time for transports. • Electron cloud model - this is another subject, and work is just beginning.

  18. Where We’re Going: Typical Future Ring Tracking Simulation, SNS Injection. • Nonlinear map transports with errors. • Longitudinal and transverse impedances. • 3D space charge, evaluated using 128 longitudinal bins (this may not be enough - aspect ratio), each with periodic 2D FFT solver with 128 x 128 grid, as described by Hockney and Eastwood, and conducting wall boundary correction as described by Jones. • Longitudinal dynamics including RF and longitudinal impedance. • Beam accumulation ~1000 turns. • Inject ~200 macroparticles / turn / bin -> 25.6M macroparticles at finish. • ~300 transports / turn interspersed with space charge and impedance kicks. • Run time >1000 hours on my laptop (650 MHz Pentium III).

  19. Where We’re Going: Merger With Unified Accelerator Library (UAL). • We have been working with our SNS colleagues (N. Malitsky and A. Shishlo) at BNL to incorporate the ORBIT models into their Unified Accelerator Library. • In addition to all the ORBIT capabilities described above the resulting product will support • An MPI parallelization of the time-consuming space charge routines. • TEAPOT and ZLIB for nonlinear symplectic tracking. • Other capabilities of UAL, including errors. • Status • ORBIT impedance and space charge routines have been implemented, parallelized, and tested in UAL. • Some ORBIT diagnostic routines have been implemented, but this task remains to be completed. • Collimation and aperture routines have not yet been implemented.

More Related