Krivosheev, O E

CERN Document Server

A LEX-BASED MAD PARSER AND ITS APPLICATIONS∗O. Krivosheev† , E. McCrory, L. Michelotti, D. Mokhov‡, N. Mokhov, J.-F. OstiguyFNAL, Batavia, IL 60510, USA‡ University of Illinois at Urbana-Champaign, USAAbstractAn embeddable and portable Lex-based MAD languageparser has been developed. The parser consists of a front-end which reads a MAD file and keeps beam elements,beam line data and algebraic expressions in tree-like struc-tures, and a back-end, which processes the front-end datato generate an input file or data structures compatible withuser applications. Three working programs are described,namely, a MAD to C++ converter, a dynamic C++ objectfactory and a MAD-MARS beam line builder. Design andimplementation issues are discussed.1 INTRODUCTIONThe MAD[1] lattice description language has become thelingua franca of computational accelerator physics. In or-der to achieve acceptance, new codes and libraries need torecognize lattice descriptions expressed in MAD format.Our objective was [2] to produce an embeddable parser ableto read, parse and store lattice descriptions in memory. Theparser had to be flexible enough to support various formats;in particular, we needed to translate MAD input format filesinto C++ files compatible with the BEAMLINE class li-brary [3] as well as a dynamic C++ factory module com-patible with that library.2 DESIGN ISSUES2.1 General ConstraintsBecause its grammar does not conform to the LALR(1)conventions1, the MAD language as described in [4] is notwell-suited for parsing using standard tools like Lex andYACC. While it is technically possible to hand-code a spe-cialized parser, the flexibility arising from using Lex andYACC is compelling. We therefore chose to eliminate am-biguities by putting minor restrictions on admissible MADinput files.The first design decision we faced was to select an imple-mentation language. We wanted the parser to be usable notonly with C++ class libraries, but also as a module linkablewith C or Fortran. C, the least common denominator, waschosen.The other design decision came directly from the MADlanguage definition and parser requirements. Because∗Work supportedby Universities Research Association, under contractDE-AC02-76CH03000 with the U. S. Department of Energy.† kriol@fnal.gov1In brief, this means that it must be possible to tell how to parse anyportion of an input string with just a single token of look-ahead.MAD variables, and thus beam element definitions, can bealtered at any point, the only sensible way to build a parseris to make it a two-stage program. The first stage, or front-end, reads the MAD input file and parses it in memory. Thesecond stage or back-end, generates output in a suitable for-mat, e.g. C++. This design is very flexible since the back-end can be modified to support other formats or to dynam-ically instantiate data structures (C++ factory).2.2 Front-EndThe front-end uses a lexical analyzer built with Lex (inits Flex[5] incarnation). It recognizes MAD keywords,identifiers, numbers, strings, and comments from regular-expression-based rules and returns corresponding tokensand semantic values. The parser, written in YACC (we areusing the Bison[6] flavor of YACC), contains the gram-mar for MAD definitions. It recognizes those definitionsand stores them into internal data structures. Because Lexand YACC communicate with each other via tokens, sup-port for abbreviated keywords is an issue. For example,HKICKER is often shortened to HKICK. We decided not tosupport shortened names and directives generically. Rather,we handle several common cases separately. Any shortenedform can be handled by altering the lexical analyzer andparser in a simple, non-intrusive way.Because of its two stage design, the parser needs to storeconstants, variables, beam element definitions and beamline definitions in memory. In order to preserve as muchinformation as possible for further processing, expressionsare parsed and kept as expression trees, not as calculatedvalues. They can either be evaluated explicitly or appear inthe translated output in a form equivalent to the one used inthe original MAD input file.Parser internals The MAD parser uses four tables forstoring constants, variables, beam element definitions andbeam lines. Since accelerator descriptions often requirethousands of symbols, there is a requirement to perform fastsearches. Hash tables provide O(1) performance and aretherefore used as the container for tables. C does not pro-vide standard containers and algorithms, so we used thoseprovided by the Glib library[7]. The general parser schemais shown below.0-7803-7191-7/01/$10.00 ©2001 IEEE. 3036Proceedings of the 2001 Particle Accelerator Conference, ChicagoMAD parserConstants table Variables table Beam lines tableBeam elements tablename    constant* name    variable* name   beam element* name          beam line*name    constant* name    variable* name   beam element* name          beam line*...          ........ ... ........ ... ...... ... ......In each hash table, the key is the name of the object andthe value is a pointer to an expression tree. The tables belowshow all these structures. N-ary trees from Glib are em-Constantnamestring valuealgebraic expressionglobal line numberlocal file numberfile nameVariablenamealgebraic expressionglobal line numberlocal line numberfile nameBeam Elementnamekindlengtharray of parametersglobal line numberlocal line numberfile nameBeam Linenamebeam element listcounterglobal line numberlocal line numberfile nameployed by the parser for storing algebraic expressions usedby constants, variables, and beam elements. Doubly-linkedlists (GList pointers in Glib) are used for storing informa-tion about the beamline elements. Finally, arrays of point-ers (GPtrArray pointers in Glib) are used to store comments.What is Handled• MAD constant definitions are parsed and stored in therelevant table. Constants can be assigned algebraic ex-pressions as well as string values. Built-in constantsfrom MAD (π, etc.) are predefined.• All variables with arbitrary algebraic expressions asallowed by MAD syntax are parsed.• All beam element definitions are parsed, including ex-otic ones like matrix and lump elements.• Beamline definitions are parsed and stored, includingbeamline expressions: inversion, inclusion, and repli-cation.• All MAD comments are preserved. Because it is im-possible to analyze a comment, we associate a com-ment appearing on the same line as a statement withthat statement. A full-line comment is associated withthe statement that immediately follows it.What Is NOT Handled• The parser was designed for handling data definitionsonly. Hence, MAD commands (e.g. TWISS) are notinterpreted with the exception of the INCLUDE com-mand which imports definitions from another file. Al-though the lexical analyzer recognizes all commands,the output is limited to a message to the log file. Theparser can handle nested INCLUDE commands; infor-mation about file names and local line numbers is pre-served.• As mentioned before, only a limited number of spe-cific shortened directives are handled. The parser pro-duces an error if unsupported shortened forms are en-countered; it is usually a simple matter to substitute thelong form using a text editor.Implementation Details Once MAD definitions arestored into internal data structures and before any output isgenerated, several actions need to be taken: checking forvariable loops, sorting, and dependence resolutions. Con-stants, variables, beam elements, and beam lines are sortedaccording to the line number on which they were defined inthe MAD input file. Forward dependencies are checked andresolved by re-arranging the order of appearance of the def-initions. To prevent and detect circular definitions, a stan-dard Depth-First Search algorithm is used to walk the ex-pression trees and verify that the corresponding graphs areacyclic.2.3 Back-EndOnce the parsing step is completed, all tables are avail-able for further processing. Using Glib support functions,one can walk through the tables to either generate output ina suitable format (e.g. C++) or alternatively, dynamicallyinstantiate objects as needed.C++ output A major goal for us was to produce a toolthat would support translation of MAD input files into aformat suitable for the BEAMLINE[3] C++ class library.This has been accomplished. In the BEAMLINE descrip-tion, constants, variables, beam elements and beamlines aredefined in that order. This makes the resultant C++ file eas-ier to use and better reflects the structure of the MAD inputlanguage. All expressions and comments are preserved andincluded in the translation.Conversion Difficulties Difficulties arise in thetranslation from from MAD to BEAMLINE input for-mat(essentially C++) because of the absence of an exactone-to-one correspondence between MAD and BEAM-LINE elements. Elements like ELSEPARATOR andcollimators have no direct BEAMLINE equivalent for themoment and are replaced by drifts. Other elements are cor-rectly represented in memory but either generate commentsin the BEAMLINE input file or are treated as instances3037Proceedings of the 2001 Particle Accelerator Conference, Chicagoof placeholder classes (for example, SOLENOID). Formost elements, the generated output includes informativecomments whenever the correspondence is not exact.Values of parameters that do not have any equivalent arelisted in these comments.C++ factory The MAD parser module can also be usedin C++ factory mode. In that case, there is no need to pre-serve expressions; and they are therefore evaluated. Onceexecution of the first stage is completed, the code walksthrough the beamline element table and instantiates objectsfor every entry. Beamlines are then instantiated and pop-ulated with cloned (i.e. deep copies) of the previously cre-ated elements. Beamlines objects, as defined in the BEAM-LINE class library, contain pointers to beamline elementsrather than the elements themselves. Cloning the elementsensures that all beamline elements are distinct. Once allbeamlines have been instantiated, the tables and the parseritself may be destroyed.3 MAD-MARS BEAM LINE BUILDERThe parser has been adapted to serve as a basis for theMAD-MARS Beam Line Builder (MMBLB). This modulereads a MAD lattice file and constructs the correspondingMARS [8] geometry to allow realistic Monte Carlo simu-lations of beam-induced energy deposition effects in arbi-trary accelerator and beamline configurations. The MMBLBis already successfully used in applications to the Fermi-lab Booster, Proton Driver, extraction of the Main Injectorbeam to the NuMI beam line, and to the joint KEK-JAERIproject to study beam loss distributions, induced radiationeffects and design beam collimation systems. An exampleof the injection-collimation region description created forthe Proton Driver is shown in Fig. 1.4 TOOLSSeveral tools were used for developing and testing theMAD parser. The parser code was tested with the GCCv.2.95 compiler. It should be fairly portable (it passes gccwith -Wall options without warnings) and we expect thatcompilation with any ANSI-C-compatible compiler shouldnot pose any problem. The lexical analyzer was created us-ing the GNU Flex v.2.5.4 scanner generator. It should befairly compatible with AT&T Lex but minor changes to theinput file may be required. Similarly, the GNU Bison v.1.27parser generator was used to create the parser and the in-put file should be highly compatible with AT&T YACC.The program can be compiled and linked using the pro-vided makefile, which is written for GNU Make v.3.77. Asmentioned, the C data structures for storing the informationabout MAD objects were created using the Glib v.1.2.4. li-brary. The source code for this library can be freely down-loaded from http://www.gtk.org. The GNU tools canbe obtained from the GNU project website http://www.gnu.org.ZY−1.65e+03−1.10e+03−5500cm0 1.00e+03 2.00e+03 3.00e+03 4.00e+03 5.00e+03cmFigure 1: Longitudinal view of the collimation region withshielding as built with MMBLB and implemented into theMARS14.5 CONCLUSIONThe MAD parser is now functional and developmentcontinues. It was successfully tested with several very largelattice descriptions including the Tevatron, the RecyclerRing and the NLC. For information about the code and itsavailability contact kriol@fnal.gov.6 REFERENCES[1] F.Christoph Iselin, “The MAD program(Methodical Accel-erator Design) Version 8.13/8”, Physical Methods Manual,CERN/SL/92, 1992.[2] D.N. Mokhov et al.: “MAD Parsing and Conversion Code”,Fermilab-TM-2115, 2000.[3] Leo Michelotti et al, MXYZPLTK/Beamline class library,http://www-ap.fnal.gov/~michelot/, 1999.[4] Hans Grotte, F.Christoph Iselin, “The MAD pro-gram(Methodical Accelerator Design) Version 8.13/8”,User’s Reference Manual, CERN/SL/90-13(AP), 1990.[5] Vern Paxson, Flex, version 2.5.4. A fast scanner generator,Free Software Foundation, 1999.[6] Charles Donnelly and Richard Stallman, Bison, version 1.28.The YACC-compatible parser generator, Free Software Foun-dation, 1999.[7] Now part of Free Software Foundation GNOME project,http://www.gtk.org, 1999.[8] N. V. Mokhov, “The MARS Code System User’sGuide”, Fermilab-FN-628 (1995); N. V. Mokhov andO. E. Krivosheev, “MARS Code Status”, Fermilab-Conf-00/181 (2000). http://www-ap.fnal.gov/MARS/.3038Proceedings of the 2001 Particle Accelerator Conference, Chicago

A Lex-Based Mad Parser and its Applications

Abstract

Similar works

Full text

Available Versions

CERN Document Server