- 110 Views
- Uploaded on
- Presentation posted in: General

ORBIT

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

FNAL: September 11, 2001

ORBIT

J. A. HolmesORNL

- 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

- 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.

- 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).

- 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 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

- 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.

- 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.

- 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.

- 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.

- 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.

- 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.

- 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

- 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)

- 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.

- 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

- 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).

- 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

- This involves binning the beam longitudinally.
- Each bin will contain a complete 2D space charge solution.

- This will increase time for transports.

- This will increase time for transports.

- 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).

- 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.

- 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.