Lattice file format
Opened this issue · 2 comments
@PaulGoslawski @MichaelMAB2020 @tomerten
Problem:
To leverage multiple simulation tools we have to generate lattice files in different formats.
Solution 1: Maintain different formats by hand
This can become very tedious, especially if we have tens or hundreds of different lattice files. This could also be error-prone. I think the only advantage is, that we don't have to write any custom software.
Solution 2: Generate different lattice files automatically
Decide on one main lattice file format. This file format will be the ground of truth format. This requires the files to be clean (no markers, simulation-tool specific attributes/variables), because otherwise it is very difficult to convert to other formats.
To make lattice-development more convenient, we could than provide some template files, where markers or other utility elements are automatically injected.
I would propose to go with the LatticeJSON format, because it will be the easiest way to generate other lattice files. It is much harder to parse stuff than generating stuff! If you don't I think it is a good idea to use a custom file format, my second-favorite approach would be to agree on a restricted subset of the MADX format (no variables, only basic elements)
I think the best way is to allow all three formats: json, madx, lte. but restrict the madx and lte files, so that a 1:1 mapping between them exists
Elegant basic elements:
- ideally the same elements can be used for each kind of simulation (twiss, chromaticity-correction, dynamic aperture and off momentum tracking, ...)
- asuming tracking to be the most sensitive procedure elements should be choosen accordingly to its requirements
- from the manual symplectic tracking is performed with CSBEND, KQUAD, KSEXT, KOCT and if needed KPoly for magnets; critical values: nKicks, edge-Parameters, integration order, ...;
- DRIF for drifts - NO! use EDRIFT for symplectic tracking !!!
- SR-Loss calculations/RF/Cavity: tbd
- Apertures: tbd
- markers, watchpoints, etc might be stored for generation of other formats but don't have to be used
- ...