z-logo
open-access-imgOpen Access
Mapa-an object oriented code with a graphical user interface for accelerator design and analysis
Author(s) -
Svetlana Shasharina,
John R. Cary
Publication year - 1997
Publication title -
aip conference proceedings
Language(s) - English
Resource type - Conference proceedings
SCImago Journal Rank - 0.177
H-Index - 75
eISSN - 1551-7616
pISSN - 0094-243X
DOI - 10.1063/1.52386
Subject(s) - graphical user interface , computer science , code (set theory) , source code , set (abstract data type) , programming language , interface (matter) , user interface , graphical user interface testing , operating system , user interface design , bubble , maximum bubble pressure method
We developed a code for accelerator modeling which will allow users to create and analyze accelerators through a graphical user interface (GUI). The GUI can read an accelerator from files or create it by adding, removing and changing elements. It also creates 4D orbits and lifetime plots. The code includes a set of accelerator elements classes, C++ utility and GUI libraries. Due to the GUI, the code is easy to use and expand. 1 OBJECT ORINTED APPROACH C++ was chosen for the project (mapa) because it is the most commonly used object-oriented programming (OOP) language in scientific and programming communities. It is portable across many platforms and works elegantly with C procedures of X/Motif. This language provides data encapsulation, inheritance (including multiple inheritance) and dynamic binding (1). It allows overriding and overloading of methods. The code, written in OOP language has a better chance to be clear, expandable, flexible and reusable. Mapa uses many patterns (idioms) of OOP (2). First of all, we used classical patterns of canonical classes, which emulate behavior of built-in types. Thus, we can treat vectors, Matrices, strings in a most convenient way (i.g. we can add them and perform other "natural" operations). We also used the Composite pattern for building primitive (single) and composite (beamline) accelerator elements, so that we can treat them equally. From behavioral patterns we used the Handle/Body pattern to build the garbage collection for strings, vectors and matrices. The Observer pattern was used for realization of Model/View-Controller structure, which allows to separate model from views and update the views upon changes in models. The Template method, which encapsulates logical parts of algorithms and leaves their definition to derived classes, saved us a lot of coding and made the code more transparent. We also used the Letter/Envelope pattern for providing polymorphic behavior for arithmetic classes (latter will be used for implementation of TPSA). 2 SYSTEM HIERARCHY AND MAPA'S CAPABILITIES The code has two hierarchy trees describing the models of interest. One tree has to do with general systems, which have names (class System), parameters and options with unified I/O (class SimpleSystem). The map hierarchy describes systems with dynamic features (the Advance methid propagates dynamic variables though time). The two hierarchies meet to create (through multiple inheritance) the SimpleMap class (which is still an abstract class), from which most of mapa systems are derived. Thus, an abstract Element is derived from the SimpleMap, as well as Accelerator, set of classical nonlinear dynamics maps (Henon's, standard map etc.) and Torus (class for studying motion of particles on toroidal fusion devices). Concrete elements and composite element (Beamline) are derived from Element. Accelerator and Element are related through aggregation: Accelerator has a list of Element pointers.

The content you want is available to Zendy users.

Already have an account? Click here to sign in.
Having issues? You can contact us here
Accelerating Research

Address

John Eccles House
Robert Robinson Avenue,
Oxford Science Park, Oxford
OX4 4GP, United Kingdom