Proceedings of ICALEPCS2003, Gyeongju, Korea

A NOVEL ONLINE SIMULATOR FOR APPLICATIONS REQUIRING A
MODEL REFERENCE*C.K. Allen†, C.A. McChesney, LANL, Los Alamos, NM, 87545, USA
C.M. Chu, J. Galambos, W.-D. Klotz, T. Pelaia, A. Shislo, ORNL, Oak Ridge, TN, 37831
Abstract
In developing the control system for the Spallation
Neutron Source (SNS) we have built an online particlebeam simulator. It is an independent subsystem of thehigh-level applications programming framework calledXAL. The simulator architecture is based upon theElement-Algorithm-Probe design pattern where the same
simulation engine can support various simulation
strategies (e.g. single-particle and envelope simulations).
Moreover, the system automatically synchronizes to themachine configuration and operating conditions; thus, nosupport for external off-line modeling is necessary. As isXAL, the simulator is implemented in Java and storespersistent data (lattices, trajectories, etc.) in XML format.

INTRODUCTION
The Spallation Neutron Source (SNS) is using anapplication framework for high-level control application
development called XAL [1]. XAL is a Java-based,
device-oriented framework designed to expedite
application development and decouple the developer fromany low-level machine interaction.
Indeed, theunderlying connection mechanism, EPICS in the case ofSNS, is hidden from the developer. The XAL framework
also includes an online model for simulating various
aspects of machine behavior; this modeling subsystem ofXAL is the concern of this paper.
The design objective of the XAL online model is toprovide a clean interface for high-level physics andcontrol applications requiring a model reference. Thisaim includes automatic configuration and synchronization
to live hardware as well as presenting the same interface
to differing simulation strategies (e.g., single-particle,multi-particle, envelope, response matrix, etc.). It is alsovaluable to build a modeling system that is easily
maintained and upgraded to support the varying
requirements of commissioning and operating a particle
accelerator. We are able to achieve these various goals
due to a novel approach in software architecture called theElement-Algorithm-Probe design pattern introduced by
Malitsky and Talman[4]. This design strategy decouples
the machine model from beam representation anddynamics calculations.
The numerical simulation techniques and underlying
physics have been outlined in a previous paper [2]. The
techniques for envelope simulation are covered in detailby Allen and Pattengale [3]. Here we concentrate on thearchitecture and use of the online simulator. We also___________________________________________*Work supported by the US Department of Energy under the auspicesof SNS†Corresponding author ckallen@lanl.gov

315

present the results of validation and verification studies,which demonstrate that the simulator is, indeed, correctlymodeling the accelerator system.

SOFTWARE ARCHITECTURE
The Element-Algorithm-Probe design pattern separates
the machine representation from the beam representationand the dynamics calculations. In accordance with thisscheme, subsystems for representing the accelerator, thebeam, and the beam dynamics are decomposed into
separate software components that communicate throughthe well-defined software interfaces IElement, IProbe,and IAlgorithm, respectively. In addition we haveanother subsystem for dynamically synchronizing themodel parameters to live hardware configuration, design
parameter values, and/or user-specified values.

Figure 1: machine representation component

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 objectrepresenting 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
Most objects representing
the IElement interface.
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().

Proceedings of ICALEPCS2003, Gyeongju, Korea

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 of
the 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, beamrepresentation, and beam dynamics.
The online
synchronization mechanism may be accessed via themethod resync().

Figure 2: architecture of beam representation component

Beam Representation
Figure 2 depicts the basic architecture of the beam
representation component.
The interface to thiscomponent is called IProbe. Note that the interface forthe dynamics subsystem, IAlgorithm, is associated withIProbe. Thus, each probe object, representing some
aspect of a charged particle beam, also specifies its owndynamics. There can be several types of dynamics
calculations available for any particular probe (e.g.,linear, third-order, etc.).
In Figure 2 we see that the (abstract) class Probe isprovided to assist in the implementation of particularprobes. It provides necessary bookkeeping as well as
access to trajectory objects (not shown), which store
probe histories along the lattice. The maintenance ofactual 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.

Machine Synchronization
Synchronization with the operating hardware isaccomplished through a subsystem based on the (abstract)class Synchronization. It supports communication
between the XAL model system and arbitrary datasources, which otherwise have no awareness of one
316

SynchronizationManager«signal»NewValue«signal»-NewValue()1«send»*-synchronizations

Synchronization-sink«interface»model::IElement+resync()
1..* 0..1+getModelingElement()«implementation class»
SynchronizationType«interface»
IElementType

IDataSource:DataSource«implementation class»
DataSourceType

Figure 3: synchronization mechanism
another. One data source in particular is the XAL
standard machine format (SMF) subsystem, which
represents the actual machine hardware.
Shown in Figure 3, the synchronization mechanism isgoverned by a SynchronizationManager, which iscomposed of many Synchronization objects. Eachmodeling element, represented by the IElement interface,
may have, at most, one synchronization object associatedto it. (This condition is necessary because, for example,“drifts” are not controllable devices of the accelerator.)
Also indicated in the figure is that each type of modelingelement requires the implementation of a particularsynchronization
subclassthat
understands
thecommunication vernacular of the element. This
polymorphism is not as difficult to support as one maysuspect, since many elements are controllable through thesame interface (e.g., dipole correctors and quadrupole
lenses are both IElectromagnet’s). We also subclass thebase class DataSource for each data source we support.
Once implemented, any synchronization request is carriedout by invoking the abstract method resync() in the baseclass. Thus, to remain synchronized with the data source
the SynchronizationManager invokes resync() on eachsynchronization object whenever required.

VERIFICATION AND VALIDATIONIn these contexts, code verification asks the question,“Does the code compute what it is supposed to?”whereas code validation asks “does the code compute theanswer?” We have verified that the online model against
the simulation code Trace3D [5] for both the singleparticle and envelope simulations.
Moreover, theenvelope simulation has been verified, to a certain extent,
using actual SNS commissioning data. The response
matrix calculation has been validated by hand but remains
untested in a working control application.

Verification
Single particle simulation results for Trace3D and XAL
are essentially identical. For rms envelope simulations,comparison is more involved due to an anomaly ofTrace3D. For space charge dynamics one must evaluate
the elliptic integral

Proceedings of ICALEPCS2003, Gyeongju, Korea

32∫ (x + t)

dt
1/ 2( y + t )1 / 2 ( z + t ) 3 / 2.

The XAL online model evaluates this integral numericallyaccording to an algorithm by Carlson, which is accurate
to arbitrary precision [6]. Trace3D approximates theintegral as Z 31 (2)
RD ( Z 2 ,Y 2 , X 2 ) ≈1 − ξ 
XZ X + Y 
 XY 
where ξ(s) is the “form factor”
 s cos −1 ss < 1,
1 −1 s ∞dt
1 − s2=ξ ( s) ≡
2 0 (t + 1) t + s 2 3 / 2 1 − s 2  s cosh −1 ss > 1.
1−
s2 − 1


∫

()

(3)

Actual evaluation of ξ(s) is done through interpolation ofa lookup table. The above approximation is accurate onlyto first order, the accuracy decreasing with beameccentricity.
By employing the same approximation for RD as
Trace3D, the XAL online model duplicates thepredictions of Trace3D; this result is shown in Figure 4awhere we see the simulation results for the SNS medium
energy beam transport (MEBT) section. The values for
the Twiss parameter β(s) are shown in the figure. InFigure 4b the simulation results are shown when XAL
implements the more accurate numerical evaluation of RD.
Note that there is discrepancy here.

SNS MEBT Simulation

Horizontal (s ) (m/rad)8Trace3DXAL

765432

XAL H

6420-2 0-4-6

XAL V
Data H
Data V2468

10s (m)Figure 5: online model validation for SNS MEBTValidation
In order to verify the predictions of the XAL online
model, we compared the results of the rms envelope
simulation against wire scanner data from the SNS
accelerator. Figure 5 shows data taken from six different
beam locations along with the predictions of the XAL
online model for the SNS MEBT and first drift tube linac(DTL). Although not exact, the results are clearlycorrelated. At the time of this writing it is suspected thatthe initial conditions of the beam into the MEBT section
are not accurately characterized.

STATUS AND SUMMARY
The XAL online model currently supports singleparticle simulation, envelope simulation, and responsematrix calculation. Multi-particle simulation is still indevelopment; the architecture is in place but the spacecharge calculation has not been implemented. Also, XAL
has no current capacity for modeling storage rings,
although this should be a straightforward extension. All
the currently operational simulation capabilities havebeen verified and the envelope simulation has beenvalidated against SNS commissioning data.

REFERENCES

1000.5

11.5

22.5

3

3.5

[1] J. Galambos et. al., “XAL Application Programming
Framework”, these proceedings.
[2] C.K. Allen, et. al., “A Modular Online Simulator for
Model Reference Control of Charged ParticleBeams”, PAC03, Portland, OR, May 2003.
[3] C.K. Allen and N.D. Pattengale, LA-UR-02-4979
http://lib-www.lanl.gov/cgi-in/getfile?00796950.pdf.
[4] N. Malitsky and R. Talman, “The Framework of theUnified Accelerator Libraries”, ICAP 1998.
[5] K.R. Crandall and D.P. Rusthoi, “TRACE 3DDocumentation”, LANL Report LA-UR-97-886.
[6] B.C. Carlson, “Computing Elliptic Integrals byDuplication”, Numer. Math., Vol. 33, 1-16 (1979).

4s (m)a)

XAL using approximation of RD
SNS MEBT Simulation

8Horizontal (s ) (m/rad)SNS MEBT and DTL1(1)rms size (mm)

R D ( x, y , z ) ≡7

Trace3DXAL

6543
21000.5

1

1.5

2

2.5

33.5

4s (m)b) XAL using numerical evaluation of RD
Figure 4: online model verification for SNS MEBT317