...
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 setskeep track of sets of beamlines, 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 conjointly. And we know which have got optics info in them and whether they're "design" or "extant machine" or "gold". This of course has to be in concert with the optics in the oracle DB, and if java objects of XAL accelerator sequences are automatically egenerated, synchronous with those too.
Using SLC modelling to expedite LCLS apps development.
...