PAC++:ObjectOriented Platform for Accelerator Codes

INTRODUCTION Software packages in accelerator physics have relatively long life cycles. They had been developed and used for a wide range of accelerators in the past as well as for the current projects. For example, the basic algorithms written in the first accelerator program TRANSPORT 1 are actual for design of most magnet systems. Most of these packages had been implemented on Fortran. But this language is rather inconvenient as a basic language for large integrated projects that possibly could include real-time data acquisition, data base access, graphic user interface modules (GUI), and other features. Some later accelerator programs had been based on object-oriented tools (primarily, C++ language). These range from systems for advanced theoretical studies 10 ,12 to control system software. In this report the basic principles of an object-oriented platform for accelerator research software (PAC++) are suggested and analyzed. Primary objectives of this work are to enable efficient self-explaining realization of the accelerator concepts and to provide an integrated environment for the updating and the developing of the code. C++ language increases portability and clarity of Fortran-based programs and also provides some new features in comparison with the traditional approaches: • All accelerator formalisms are considered from a common position. Transition from one paradigm to another is performed with one assignment operator =(Pac& P). PAC++ itself could be considered as a shell for some old accelerator algorithms as well as a tool for developing new ones. • Overloaded aritlunetic and assignment operators provide the user with a powerful method of accelerator description that is an integral part of C++ source code. Each operation has an intuitive physical sense. Addition enables one to construct an element from some simple bricks while multiplication is a concatenation of elements and lines. • PAC++ is implemented as an open hierarchy of classes that enables one to derive new paradigms while preserving compatibility with the old ones. This makes possible to link PAC++ applications with the lattice databases and uses them in the control systems. Users could also create their own libraries including in them specific accelerator lattices and algorithms. • "Time function" concept enables one to simulate changing accelerator features and to receive a more valid understanding of the real physical processes. 2.0 INPUT LANGUAGE Traditionally programs for the lattice design in accelerator physics had been written in the some standard input language 3 that was then interpreted by the package. This approach in particular stemmed from the desire to write basic algorithms as simple and portable as possible, and from the inability of Fortran to provide suitable language constructions. The powerful mechanisms of object-oriented programming (such as polymorphism, inheritance etc.) now allow one to write accelerator algorithms directly in C++ language without damaging program clarity. This report considers the object-oriented description of accelerator structure. Basically we suggest overloading arithmetic and assignment operators and describing the lattice element as a member of some linear space E. In Appendixes C and D the simplified implementation of the Low Energy Booster,19 based on the MAD input language and PAC++ syntax respectively, is presented. 2.1 Linear Space E In PAC++ lattice elements are considered as instances of C++ class Element and declared as : Element id( "Name of the element"); where id is any valid C++ identifier and "Name ofthe element" is some symbolic name of this element. We do not utilize specific keywords (Rbend, Quadrupole, Kicker etc.) for the type of element but rather describe each element with definite. (systematic) parameters as a member of a linear space E 8 , which contains a subset of instances of C++ class Element This approach enables one to describe an element without splitting it into some auxiliary parts and also forms the lattice in direct accordance with the sequence of real elements. We developed ideas, first suggested for the code TEAPOT,4 and included "nonstandard" 2 TEAPOT parameter IR that defines internal representation of the element. Certainly, the rules and algorithms of this transformation should be determined in the chosen code (Subsection 4.1). To represent the root mean square (rms) of random error for specific elements, we define C++ class Error. Class Error is derived from the class ElementParameter, inherits its arithmetic operators, and determines similar linear space £: (Appendix A One of the additional features of PAC++ is the inclusion of arbitrary time functions in the description of element to simulate the real physical processes (magnetic field ramp, power supply ripple etc.): It enables one to design the object-oriented implementation of ESME 7 and develop some special operators of different accelerator codes (e.g., Adiabatic variations in DIMAD 5 ). We did not use it for the Low Energy Booster (Appendixes C and D) because TEAPOT assumes that rf voltage has to be constant and matches different rf parameters in accordance with its own algorithm. If el is an instance of class Element and 12 is an instance of class Line, then reflect (el *12) is equal to reflect {l2)*el. The optimal accelerator structures and their sections may be allocated in the different header files and used together to study common physical processes: Line injection = linac-Ieb*lebj } 3.0 BASIC DEFINITIONS AND CLASSES As any physical object, accelerator and its elements are characterized by some set of input and output parameters: the linear transfer matrix and periodic twiss functions,14 the second order aberration coefficients,15 one-turn maps,17 position of closed orbit and particle coordinates referred to the ideal orbit, element coordinates in the global Cartesian system and all element parameters, described in the previous section. They are the important ingredients of all accelerator algorithms and may be considered as a set of C++ classes that form the platform for object-oriented implementation of modern accelerator programs (Appendix F). 3.1 Particle or Position In PAC++ the position of the particle is determined by the standard canonical variables 3 and considered as C++ class Particle. 5 If we will consider the accelerator as some object A of class Accelerator, the one-turn tracking may be defined as multiplication of this object A and phase space vector x: y=A*x; where x and yare the instances of class Particle and contain the particle coordinates before and after one turn, respectively. For multi particle tracking the arrays of Particles could be used: for(int i = 1; i <= number Particles; i++) for(int j = 0; j < numberTurns; j++ ) The common beam parameters, such as energy, particle mass and charge, are located in C++ class Beam. Class Particle is derived from this class and shares all its static data members. The default particle type is proton, and the energy is equal to infinite value. To change them the corresponding variables ENERGY, MASS and CHARGE may be used: ENERGY = 1.538; / / Beam energy, [GeV] This set of parameters could be developed to include in our model some additional physical effects (e.g., number of particles for simulation of space charge). Rmatrix The position x of the particle after some magnet transport system may be expressed by means of Taylor expansion as: j=1, 6 j,k=1,6 where Rij and Tijk are first and second order Taylor coefficients and vector xo is the vector of initial particle coordinates. The transfer matrix R (or the Courant-Snyder matrix We implement the Courant-Snyder matrix R as C++ class Rmatrix. Since its coefficients are determined by the physical parameters of the element or magnet system, data where x and xO are the instances of class Particle and contain the particle coordinates before and after this system, respectively. The subscripting operator [ ](int i) returns the reference to Particle, which represents i-th row of corresponding transfer matrix, and enables use of the instances of class Rmatrix as a usual matrix. We did not consider the second-order matrix because of the huge size of this material. The theory of aberration coefficients is exhaustively presented in several papers 15 ,16 and may be implemented simultaneously with the corresponding accelerator programs. 1 ,2,5,8 3.3 Twiss In linear approximation the horizontal and vertical motion of the particle in a circular machine usually is considered independently and described by the Twiss periodic 7 functions.1 4 For example, the horizontal position of a particle with initial coordinates 1(0) after n turns at i-th element may be determined as: where Vx is the horizontal tune and /3x( i), ct x ( i), ~x( i), Dx( i), D' x( i) From the other side, if we will include the momentum compaction ct = t.Yl in data members of class Twiss, its objects may be used for initialization of corresponding transfer matrixes: The similar class Couple could be considered for coupled betatron motion described in paper. where seed is int argument for the random number generator rmsEngine. To use setError in the derived accelerator programs we should modify only one protected virtual func-9 tion ownSetError(int n) that connects own data members with PAC parameters of n-th element. Because of memory problems instances of class Pac contain the second-order matrix only for the whole accelerator. It is returned by access function tmatrixO.t The corresponding parameters for i-th element may be calculated by the simil.ar function tmatrix(int i). To extract some specific set of elements from the accelerator structure, we introduce additional C++ class Set. It is derived from class Pac (Appendix E) and initialized by the public function set: Pac lebPac = leb; Set bpmH = lebPac.set(pm); where pm is the instance of class Element. The function set may have different arguments, but it is defined by single virtual functions ownSet(int* numbers, int n), where numbers is an array of original element numbers. Besides the inherited data members, class Set includes for each element second-order matrix coefficients, closed orbit and beam position. It allows simplified access to the data and uses these objects in different optimization algorithms. 4.0 SEQUELS In this report some common principles for object-oriented implementation of accelerator algorithms were described. Our consideration was limited by the direct (element-byelement) particle tracking and extraction of a one-turn Taylor map. As an example we present the initialization and tracking functions of two w:idespread programs TEAPOT 4 and Zmap.ll 4.1 Teapot The program TEAPOT has been developed as a symplectic integrator that produces exact particle tracking in some approximate lattice. In accordance with PAC++ rules this program is implemented as C++ class Teapot. It is derived from class Pac and inherits all its public and protected data members and functions. Program TEAPOT introduces its own internal representation of lattice elements as sequences of drifts and thin multi poles. These parameters may be considered as data members of auxiliary class TeapotElement, which instances are included in class Teapot. § To initialize them, the corresponding Pac virtual functions and assignment operators were modified. For To optimize the tracking procedure, TEAPOT considers the sequence of several drift regions as one total section. It breaks the original order of elements and complicates the use of element parameters between different accelerator codes. The propagation of the particle through a drift region may be described by a few mathematical operators and will take an insignificant amount of CPU time. To check it we saved the original accelerator structure in the C++ version and used the example of LEB lattice presented in Appendixes D and E. There are several accelerator packages 6 ,10 that perform differential algebra through the operations of expanded power series and allow one to obtain one-turn Taylor maps. In this report the object-oriented implementation of program Zmapll is considered. Zmap translates the Teapot tracking algorithm into TPS operations through the calling statements of the corresponding Fortran subroutines of differential algebra library ZLIB. A typical module III the Simulation Facility consists of the three processes runmng simultaneously: 1. display program to support interaction with an operator;, 2. application itself which realizes specific algorithms in accordance with operator requests; 3. simulator module to emulate a real accelerator. These processes are interactive only through the external database and so when the operator activates some command, the display program places the request into the database and then the application reads the command and activates the simulator, also through the database request. This scheme was chosen to insure the maximum portability because for some database management systems (e.g., EPICS) display programs exist only as independent tasks and cannot be directly incorporated into the source code of the application. Besides, this approach enables one to change realization of one process while not affecting two others. The application uses C++ Application Isolation Code (AIC) library13 to insure portable access to the database. AIC is realized as a set of C++ base classes that provide basic control data types and some operations for this data. Details of the database call interface are hidden from the High Level Application Code (HLAC). 12 AIC could utilize different underling database management systems. In particular, it could simply use a share memory model. Changing of the underling model would require only relinking of the application with another library. The AIC is to provide data concentration and isolation functions. This allows accelerator physicists to concentrate on the physics and avoid the complications associated with data attributes, error conditions etc. AIC is intended to provide the following features: • a simple representation of control data in a structured manner; • independence of high level application from database and hardware related features; • portability of control code with respect to different operating systems as well as different database packages; • uniform approach to data retrieved from varIOUS sources (EPICS database, text file( s ), share memory). To utilize access to the external database, PAC++ applieation must declare instance of the access handler: Ale database; This will enable one to read/write PAC++ constructions to the database by C++ I/O operators: database ~ bpm; / / Some calculations database ~ corr; where bpm and corr are instances of the class Set (Section 3.4). All specific features of the used database are hidden from the HLAC code and located in the AIC library that is linked to produce the executable file. 13 ACKNOWLEDGEMENT

Silicon optical nanocrystal memory

We describe the operation of a silicon optical nanocrystal memory device. The programmed logic state of the device is read optically by the detection of high or low photoluminescence intensity. The suppression of excitonic photoluminescence is attributed to the onset of fast nonradiative Auger recombination in the presence of an excess charge carrier. The device can be programmed and erased electrically via charge injection and optically via internal photoemission. Photoluminescence suppression of up to 80% is demonstrated with data retention times of up to several minutes at room temperature

Determination of coupled-lattice properties using turn-by-turn data

A formalism for extracting coupled betatron parameters from multiturn, shock excited, beam position monitor data is described. The most important results are nonperturbative in that they do not rely on the underlying ideal lattice model. Except for damping, which is assumed to be exponential and small enough to be removed empirically, the description is symplectic. As well as simplifying the description, this leads to self-consistency checks that are applied to the data. The most important of these is a {open_quotes}magic ratio{close_quotes} of Fourier coefficients that is required to be a lattice invariant, the same at every beam position monitor. All formulas are applied to both real and simulated data. The real data was acquired June, 1992 at LEP as part of decoupling studies, using the LEP beam orbit measurement system. Simulated data, obtained by numerical tracking (TEAPOT) in the same (except for unknown errors) lattice, agrees well with real data when subjected to identical analysis. For both datasets, deviations between extracted and design parameters and deviations from self-consistency can be accounted for by noise and signal processing limitations. This investigation demonstrates that the LEP beam position system yields reliable local coupling measurements. It can be conservatively assumed that systems of similar design at the SSC and LHC will provide the measurements needed for local decoupling

Abstract Particle Orbit Tracking on a Parallel Computer:

the vectorized tracking code ZTIWCK, it was realized that this could be most eticiently done by performing the initial operations on local workstations, then transfening a file A program has been written which performs particle containing the complete description of the lattice, with errors orbit tracking on the Intel iPSC/860 distributed memory and correction in place, to the Cray. This eliminated the need parallel computer. The tracking is performed using a thin for porting complex tuning algorithms to the supercomputer. element (TEAPOT-style[l]) approach. A brief description of The same strategy is used in Hypertrack; in fact, the same file the structure and performance of the code is presented, along format has been maintained. with applications of the code to the analysis of accelerator lattices for the SSC. The concept of “ensemble tracking”, i.e. Code Structure and Usage the tracking of ensemble averages of noninteracting particles, such as the emittance, is presented. Preliminary results of such studies will be presented. The code is based on a manager/worker model as shown in Figure 1. The single manager node first reads in the lattice data and command instructions from the input 6Ie

An Associative Memory with oscillatory CNN arrays using spin torque oscillator cells and spin-wave interactions architecture and End-to-end Simulator

An Associative Memory is built by three consecutive components: (1) a CMOS preprocessing unit generating input feature vectors from picture inputs, (2) an AM cluster generating signature outputs composed of spintronic oscillator (STO) cells and local spin-wave interactions, as an oscillatory CNN (O- CNN) array unit, applied several times arranged in space, and (3) a classification unit (CMOS). The end to end design of the preprocessing unit, the interacting O-CNN arrays, and the classification unit is embedded in a learning and optimization procedure where the geometric distances between the STOs in the O-CNN arrays play a crucial role. The O-CNN array has an input vector as a 1D array of oscillator frequencies, and the synchronized O-CNN array codes the output as the phases of the output 1D array. The typical O-CNN array has 1-3 rows of STOs. Simplified STO and interaction macro models are used. A typical example is shown using an End-to-end Simulato