...
The results of tracking (twiss, R-matrices, global machine params, optical component settings) for each of these beamlines for each of the choices of model (design, gold, experimental) for each source of input data (design, PV), will have to be stored. This could all be handled by careful filenaming if it's sufficient to do tracking in the initialization stage of each modeling program's startup. But if that proves too slow then we'll need to persist the outputs into the Oracle DB and programs will go to the db to get optical parameters. See figure 2.
Beamline Descriptions
The number of beamline description input files we need depends on the number of beamline geometries the LCLS will be run in (for instance, how many modeled extraction lines for experiments will there be)? It additionally depends on how many energy profiles will there be? Also high-level applications that deal with beamlines (bpm orbit displays, steering etc) will initialize displays based on the end-points of an input XAL beamline description file. So the XAL orbit correction app for instance, will always initialize to steer the whole LCLS unless a separate beamline file is written for smaller regions of interest - such as injection separately from main linac.
It seems reasonable to assume we'll need to deal with at least the injector, main linac and wiggler separately. So, we'll need some way to manage beamline sets, possibly in a similar way to SLC, where a given named "beamline" is composed of conjoined sections, and each can be tracked or used independently or conjoinedly.
Short-term Optics Modeling Environment and Applications - using SLC modeling.
XAL is intended to provide much of the code-base of new applications of the LCLS. Until the XAL modeling environment is ready for use we're going to use the SLC modeling environment to model the optics of the LCLS injection. However, this need not stop us developing and deploying XAL based modeling applications (such as emittance measurement); since XAL uses an input XML file for both lattice description and to store the Twiss parameters following tracking, and it is this combined output file which is used as input by XAL applications, we can take an input XAL beamline description file, and insert the correct Twiss parameters from a corresponding model run on SLC via AIDA. See Fig 3. The resulting output file can be used by XAL applications before the XAL model system is ready.
Non XAL unix based applications in general (eg matlab) can also be developed ahead of the XAL modeling environment using Aida to get R-matrices and Twiss parameters etc from the SLC model environment.