...
The problem is to get from a beamline designer's view of the accelerator (the "geometry" - the physical layout of the machine and its gross beamline elements) to the "lattice" (how the beam is constrained in terms of controllable devices, how magnets are split, marker points etc), to the description of the transport system "optics" (R-matrices and Twiss parameters) used in online model based applications.
...
Systematics of Optics Computation
In XAL, each application which uses optical parameters (Twiss and R-matrices) must track a lattice for itself, or use a special "pre-tracked" version of the XAL beamline description file which includes the Twiss parameters - from which it must compute R-matrices if it needs them. If tracking, it must acquire the energy values from klystrons and k-value of optical components, and track the lattice (which XAL calls "probe"). One of the apps, the Model Optics application, allows a user to browse optics so calculated.
For LCLS, we will pre-compute the optics from the lattice, to produce the XAL file files which includes include 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.
...