impactx
impactx copied to clipboard
MAD-X input reader: constants, elements, lines, segments
We want to support reading accelerator lattices directly from MAD-X input files. For this, we will need to support at least the following syntax elements:
- constants
- elements
- lines
- segments
- simple math
from MAD-X definitions.
For that, we could explore if @janfschmidt's palattice could be used as a library :)
https://github.com/janfschmidt/palattice
References on MAD-X:
- https://mad.web.cern.ch/mad/webguide/manual.html
- https://github.com/MethodicalAcceleratorDesign/MAD-X/blob/master/doc/latexuguide/format.tex
- MAD websites
- MAD-X http://cern.ch/madx (current version)
- MAD-9 http://cern.ch/mad9
- MAD-8 http://cern.ch/mad8
- MAD-NG http://cern.ch/madng/dev (next generation under development)
Example files for MAD-X lattices:
- LBNL/ImpactX/ABLASTR team: https://drive.google.com/drive/u/0/folders/1-BZysj84iEjhDOw-JsEDuu7IytGdl8YN
@qianglbl and @cemitch99 mentioned: MAD-X also has an "optics" command that can output a simple CSV file with one element per row. IMPACT-Z can read this file in.
We might want to add support to:
- write the same file format for the lattice from ImpactX
- read in the same file format to initialize our lattice.
Optics CSV file structure
Columns with names (column 1), type (column 2) and values: meaning of the column depends on the element type (column 2).
Values: note that parameters are not in that CSV file, e.g., fringe-field details.
With the new Python layer, we could also implement the first MAD(-X) reader on the Python side.
Warp has some routines we can get logic from (@jlvay):
- https://bitbucket.org/berkeleylab/warp/src/master/scripts/lattice/lattice.py
- https://warp.lbl.gov/how-tos/lattice/adding-lattice-elements
This is the link to the Python MADX parser that Andreas Adelmann wrote and pushed to a repo https://gitlab.psi.ch/adelmann/pymadxparser.git
Implemented via #214
https://github.com/MethodicalAcceleratorDesign/MAD-X/blob/master/src/mad_parse.c is the current source code where parsing seems to happen. I'll have to look closer to see what it is parsing into, and how that connects with any notion of a persistent structure of environments.
My planned approach right now is to mod the source code such that it reads MadX scripts normally, but instead of executing on LHC or some other particle accelerator the information is kept in some notion of an environment; upon script end or intended pause, the environment is DFS-traversed and dumped onto a general YAML or JSON.
Right now I intend on only a static implementation of an accelerator's initial state; anything and everything in the MadX file refers to t=0 for the simulation.
Mad-X Parser Notes.pdf I am no longer working on this issue. Here are my design notes and plans moving forward with implementing this issue.
Potentially something to explore to reuse from Sirepo if we get a Phase 2.
The Synergia MAD-X parser is pretty complete and is implemented in a few classes. You could look at using its parsed output to create the ImpactX beamline.
That is awesome! I would be down to replace ours with the one in Synergia, if you like!