...
For LCLS, we will pre-compute the optics from the lattice, to produce the XAL file which includes the Twiss params, so each modeling application doesn't have to track a lattice for itself before starting. The online modeling "tracker" will be that in XAL (primarily in the gov.sns.xal.model package). The output of this phase will be the Twiss parameters of each element of the beamline. A second probe can calculate the transfer matrices (R-matrices). The Twiss param outputs will be captured in a series of second XAL files. There is presently no file-handling code in XAL for statically recording the R-matrices or global parameters (path length, energy, betamax), so new output files will be designed for that (either extending the XAL syntax, or creating some other XML file). proposal: adapt probe for coupled R-matrices.
One In the existing XAL API one can track an XAL beamline in either of 2 "modes", i) "design" or ii) "from EPICS PV" - which is to say using settings for each lattice element found either in the XAL input file ("design") or by accessing the EPICS Process Variables of optical components, and since XAL is energy dependent, the klystron values also, energy components themselves at runtime. The latter produces a model of the optics of the extant machine. We should have file management capability to store a single recognized "design" lattice file, plus a "gold" lattice (the inputs "from PV" that produced good optics (see To Add), plus at least one experimental lattice file. This capability to switch easily between a lattice of the extant machine and an ad-hoc lattice was badly missed in the SLC modeling environment.
...