Proceedings of the 2003 Particle Accelerator Conference

A MODULAR ON-LINE SIMULATOR FOR MODEL REFERENCECONTROL OF CHARGED PARTICLE BEAMS*C.K. Allen#, C.A. McChesney, LANL, Los Alamos, NM, USA
N.D. Pattengale, Sandia National Laboratory, Albuquerque, NM, USA
C.P. Chu, J.D. Galambos, W.-D. Klotz, T.A. Pelaia, A. Shishlo, ORNL, Oak Ridge, TN, USA
Abstract
We have implemented a particle beam simulationengine based on modern software engineering principles
with intent that it be a convenient model reference forhigh-level control applications. The simulator is anautonomous subsystem of the high-level application
framework XAL currently under development for theSpallation Neutron Source (SNS). It supports multiple
simulation techniques (i.e., single particle, multi-particle,envelope, etc.), automatically synchronizes with operating
accelerator hardware, and also supports off-line design
studies. Moreover, since it is implemented using modern
techniques in the Java language, it is portable acrossoperating platforms, is maintainable, and upgradeable.

INTRODUCTION
To support the operation of the SNS accelerator wehave built a development framework for high-levelcontrol applications called XAL (for a description of XALsee [2]). The framework includes a simulation engine that
we call the XAL model subsystem. This subsystem
works in conjunction with the application framework, or
as a stand-alone particle beam simulator. XAL contains autility for automatically generating modeling lattices andsynchronizing them with the operating machine. Here weoutline the architecture of the model subsystem and themathematical models upon which it is based.

DYNAMICSIn all simulations we parameterize phase space using
homogeneous coordinates in ℜ6×{1}. Letting z denote apoint in phase space it has the representationz ≡ (x x ′ y y ′ z z ′ 1)T(1)where the prime indicates differentiation with respect tothe design path length parameter s. Note that we use (z,z’)
as the longitudinal phase coordinates rather than (z,∆p/p).
Mathematicians typically use homogeneous coordinates toparameterize the real projective spaces ℜPn; they are also
widely used in computer graphics for three-dimensional
rendering because translation, rotation, and scaling can all
be performed by matrix multiplication.

Single Particle Simulation
In single-particle simulations we propagate the phasespace coordinates z of the particle. Each beamline___________________________________________* Work supported by the US Department of Energy# ckallen@lanl.gov

0-7803-7739-9 ©2003 IEEE3527

element n is obligated to provide a transfer map Mn(embodied by the PhaseMap class) that represents theaction of the element. Note that the characteristics of thismap typically depend upon the parameters of the beam
being propagated. In any case, the particle coordinates
are propagated according to the transfer equation
zn+1= Mn(zn).
(2)
Although provisions for high-order dynamics are includedin the PhaseMap class, currently most of the beamline
elements simply provide a transfer matrix to represent itsdynamics. This transfer matrix Mn∈ℜ7×7 is just the linear
part of Mn, or Mn=∂Mn/∂z and we havez n +1 = M n z n .
(3)Note that because we employ homogeneous coordinates it
is still possible to perform translations, such as those
produced by steering magnets, using a transfer matrix.
Such matrices have the form m xx m xx′ L ∆x ∆x ′ 
 m x′x m x′x′
Mn = ,(4)MO M  00L 1 
where ∆x, ∆x’, ∆y, … are the translations along therespective coordinate axes. This fact is especially usefulwhen performing rms envelope simulations where only
the linear part of the transfer map is used.

RMS Envelope Simulation
For rms envelope simulations we propagate the(homogeneous) correlation matrix σ∈ℜ7×7 defined by x2xx ′ L x  ′x′2x ′ σ ≡ zz T =  xx(5) MO M x′L 1 
 x
where 〈⋅〉 is the phase space moment operator with respect
to the beam distribution. Substituting Eq. (3) into theabove then unwinding the definitions forms the statetransfer equation for rms envelopes

σ n +1 = (M n z n )(M n z n ) T = M n σ n M n T . (6)Note that these operations do not commute for the fulltransfer map Mn. Thus, to account for space charge wemust linearize the self electric fields of the beam. To thisend we employ a weighted linear regression of the true
fields. Considering the x-plane, we proceed by assuming
a self electric field Ex of the formE x ≈ a 0 + a1 x .
(7)

Proceedings of the 2003 Particle Accelerator Conference
Weighting the regression with the beam distribution itself
yields the following approximation:xE x(x − x ) ,Ex ≈(8)x2(the moment 〈Ex〉 is zero by Newton’s third law). Forbeams with ellipsoidal symmetry, that is, having
distributions f(z) of the formf (z ) = f z T σ −1 z ,(9)the moment 〈xEx〉 can be computed analytically in termsof elliptic integrals whose arguments are elements of thematrix σ. These expressions can be found in the literature[1]. Note that Eq. (8) will yield a transfer matrix form forspace charge effects that may be applied in the same
fashion as Eq. (6).

(Malitsky and Talman [3], we separate the machine
representation from the beam representation and thedynamics calculations. In this scheme, systems forrepresenting the accelerator, the beam, and the beam
dynamics are decomposed into separate software
components that communicate through the well-defined)

Ensemble Simulations
The state E of a particle ensemble is represented as acollection of phase space coordinates
E = z α ∈ ℜ 6 × {1} | α ∈ I E ,(10)where IE is an index set. The transfer equation for thisstate object is
En+1= Mn(En )≡{Mn(zα)|α∈IEn}.
(11)
Although this state can be represented as a point in theCartesian product of phase spaces (ℜ6×{1})N where
N=|E|, it is more constructive to think of it as a set withcollective properties. This process is most easily captured
as a software object, which we have done with a class
Ensemble.
Ensemble objects are responsible forcalculating self-fields and other collective properties.
There are many ways to compute these fields, including
grids, finite elements, and direct summation. These
computation techniques are currently under development.
We point out that the software is so designed such thatspecific self-field calculations may be swapped at runtime. Once the self electric fields are computed, theensemble state can be advanced according to theequations of motions. Considering the x phase plane, wehave the approximation
q(12)∆p x ≈ 2 E x ∆t ,{}γ

where the relativistic factor γ accounts for the collective
magnetic fields and ∆t is the time step. From the above
we infer∆p xq
11(13)∆x ′ =≈
Ex∆s ,pβγmc γ 2βcwhere m is the particle mass and β is the synchronous
velocity normalized to the speed of light c, and ∆s is thedistance traveled along the design trajectory during ∆t.

SOFTWARE ARCHITECTURE
We are able to support the various particle beamsimulation techniques due to a novel approach in softwarearchitecture.
By employing a variant of theElement/Algorithm/Probe design pattern introduced by3528

Figure 1: machine representation component
software interfaces IElement, IProbe, and IAlgorithm,respectively.

Machine Representation
A major effort in accelerator simulation is simply
representing the machine. By decoupling the machine
representation from the machine’s action on the beam, therepresentation then can be used to support any number ofsimulation techniques. Figure 1 is a UML structure
diagram outlining the machine representation componentof the simulator. At the heart of this component is theIElement interface, which is exposed by any object
representing a modeling element of the machine. Notethat we provide the (abstract) implementation class,Element, which provides a variety of common functions
that modeling element must accommodate in support of
the IElement interface.
Most objects representing
beamline elements are derived from this convenience baseclass. In the figure we see derived classes must provide
energy gains and transfer maps specific to the modelingelement, done by implementing the abstract methods
energyGain() and transferMap().
Shown in Figure 1 is the aggregation ElementSeq,
which is an ordered sequence of IElement objects. It, too,
exposes the IElement interface, since it may beconsidered a composite modeling element. The values
obtained here, however, would be the aggregate results ofall members in the sequence. We also see that theLattice object is just a specialized sequence. Much ofthe Lattice class function is conceptual, however, it also
provides access to the important mechanisms of probe
propagation and online synchronization. Through themethod propagate() the Lattice object coordinates theoperation of the machine representation, beam
representation, and beam dynamics.
The online
synchronization mechanism, which automaticallysynchronizes the Lattice object to the parameters of theoperating hardware, is accessed via the method resync().

Proceedings of the 2003 Particle Accelerator Conference

Beam Representation
Figure 2 depicts the basic architecture of the beam
representation component.
The interface to thiscomponent is called IProbe, as seen in the figure. Notethat the interface for the dynamics subsystem,
IAlgorithm, is associated with IProbe. Thus, each probe
object, representing some aspect of a charged particle
beam, also specifies its own dynamics. There may be
several types of dynamics calculations available for any
particular probe (e.g., linear, third-order, etc.).

Shown in Figure 3, these synchronization objects
understand the vernacular of both XAL subsystems. The
children of the AcceleratorNode class, belonging to
SMF, represent actual accelerator components andsupports communication with these devices.
The
interfaces derived from IElement represent modelingelements. Note that is a one/none-to-many association
between accelerator devices and their modelingcounterparts. This condition is necessary because, forexample, “drifts” are not controllable devices of theaccelerator and actual devices may require several
modeling elements to represent (e.g., quadrupoles withtrim windings for steering, etc.). Referring to the figure
we see that each type of accelerator device requires theimplementation of a particular synchronization class thatunderstands how to communicate with both the device
and the modeling element. Once implemented, any
synchronization request is carried out by invoking theabstract method resync() in the base class. Thus, toremain synchronized with the operating machine theLattice object maintains a set of synchronization objects,invoking resync() on each whenever required.
7.5
Trace3DXAL5β (m/rad)Figure 2: architecture of beam representation component
In Figure 2 we see that the (abstract) implementation
class Probe is provided to assist in the implementation ofparticular probes. It provides necessary bookkeeping aswell as access to trajectory objects (not shown), which
store probe histories along the lattice. The maintenanceof actual probe states is left to the particular probe
implementation. In the figure we see that the state of aParticleProbe is the vector of particle phase spacecoordinates, the state of an EnvelopeProbe is thecorrelation matrix of moments up to second order, and thestate of an EnsembleProbe is an ensemble object.

2.5

00

0.5

1

1.5

2

2.5

3

3.5

4s (m)

Figure 4: transverse beta simulations of the SNS MEBTVERIFICATION
To verify the operation of the XAL modelingsubsystem we have compared the results for single
particle and envelope simulations against those ofTrace3D. Figure 4 shows such a comparison for asimulation of the SNS Medium Energy Transport(MEBT) system. The figure plots the Twiss parameterbeta in the (horizontal) transverse plane computed by eachcode. There we can see that the results are essentiallyequivalent.

REFERENCES

Figure 3: synchronization mechanism

Machine Synchronization
Synchronization with the operating hardware isaccomplished through a subsystem based on the (abstract)
association class Synchronization.
It supports
communication between the XAL model system and theXAL SMF (Standard Machine Format) system, which
otherwise have no knowledge of one another.

3529[1] C.K. Allen and N.D. Pattengale, LANL Internal
Report LA-UR-02-4979.
[2] C.M. Chu, et. al., “Applications Programming
Structure and Physics Applications”, theseproceedings.
[3] N. Malitsky and R. Talman, “The Framework ofUnified Accelerator Libraries”, ICAP 1998.