Page History

...

See also Application Framework Architecture

Basic Model Environment

...

Geometry, Lattice, Optics

Model Optics refers to This section describes the process by which we 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), to the description of the transport system and "optics" (R-matrices and twiss Twiss parameters) used in online model based applications.

...

The results of tracking (Twiss, R-matrices, global machine params, k-values of optical components) 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 in CVS.

The combinations lead to a number of such outputs, calling for careful filenaming. Additionally, if it's sufficient to do tracking in the initialization stage of each modeling program's startup, whcih recall involves getting extant PV values and tracking the lattice, we can do that. 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.

...

Presumably only the Model Optics application presently allows a used to implement new k-values of optical components following tracking -see questions.?

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

Using SLC modelling to expediate LCLS apps development.

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.

ARCHITECTURE

This section articulates the specific libraries, packages and programs that will be used to implement the LCLS high level applications.

...

Eclipse also has 3 distinct components: Firstly it's an integrated development environment for writing programs in java and C++. More importantly for LCLS applications, it includes a sophisticated skeleton for GUI based applications (the Rich Client Platform, or RCP). Applications integrated into the RPC use SWT/Jface as the GUI framework. XAL on the other hand extends the JFC/Swing GUI framework. So, one could not use the GUI components, esp widgets, of XAL in an Eclipse RPC application. Never-the-less one can use all of the non-GUI aspects of XAL for an RPC application, just like matlab XAL programs do, and conversely one can use the SWT/jface framework to write a graphical XAL application.
Therefore, depending on the application, a programmer can choose to write a given LCLS application that uses XAL, either using JCF/Swing, in which case they will be able to use the GUI framework of XAL, or SWT/Jface.

Eclipse Plugins, Software Development and Distribution

Eclipse includes an excellent facility for developing extensions to the basic Rich Client Platform. Eclipse is itself composed of a hierarchical system of plugins. Programmers can develop plugins adding their functionality (for instance an orbit correction plugin). The plugin self-describes the precise versioning requirements it has with the plugins on which it builds. Eclipse includes a facility for distributing plugins via an update site. This provides a framework in which we can develop and distribute new code, both internally and externally with the "EPICS Office collaboration".

TOOL SUMMARY

...