...
See figure 1, a screenshot of representative user applications for LCLS. This shows a minimally modified Eclipse Rich Client (that is, basically Eclipse out of the box) in the Resource Perspective where the Eclipse Workspace has been configured to launch various kinds of program. A number of execution modes are represented (in-process, out-of-process, using Swing and SWT GUI frameworks, plus EPICS display technologies):
#Eclipse external launching (epics displays, archive viewer, scp etc).
#Eclipse launching external java SWT/Jface application (jcmlog)
#Eclipse launching internal java SWT/Jface (same VM) application (aida probe)
#Eclipse launching external java JFC/Swing (XAL) application (NOT SHOWN YET)
Graphical User Interface (GUI)
XAL will provide the overall lattice modeling framework, interface to device control, and one GUI framework (based on JFC/Swing). All the existing XAL applications can be provided by "lips" such, such as Scan ("Correlation Plots"), SCORE ("configs"), XIO ("z-plots"), or just the XAL root application.
Additionally lips may include applications which use non-GUI aspects of XAL but use some other GUI framework, such as matlab applications, or applications the use SWT/Jface for implementing the user interface view and controls, for instance the jcmlog browser. These are run in a sub-process of the lips executable with no resource splitting.
The distinction the user sees between these applications is relatively minor as long as they are running on linux to a local display, so window repaints are relatively fast for Swing based apps.
Additionally applications may be written which leverage the Eclipse Rich Client Platform, in which case they run in-process and in the same VM as Eclipse. A trivial example shown is the Aida probe shown in bottom left, which was started from the "Controls" menu.
| Anchor | ||||
|---|---|---|---|---|
|
Basic Model Environment: Geometry, Lattice, Optics
Model Optics refers to the process by which we get from a beamline designer's view of the accelerator (geometry and lattice), to the description of the transport system and optics (R-matrices and twiss parameters) used in online model based applications.
Use Case: Beamline physicist will provide MAD, Parmela or Elegant files 3. Some designated person will update the Oracle db with relevant information from these files, and run some process (presumably a SQL script) which outputs an XAL lattice input file in XML - the file containing the lattice description of the machine Test page. Given this input lattice file, software in the XAL package library can then be used by applications to compute optics (Twiss, R-matrices, etc), which they can then use to calculate bumps, orbit corrections, beta-match settings etc.
Systematics
For LCLS, we will pre-compute the optics from the lattice, so each modeling application doesn't have to track a lattice for itself before starting. The online modeling "tracker" will XAL 1. XAL has a number of components, one part of which (primarily the gov.sns.xal.model package) can be used to "track" a lattice description (which XAL calls "probe"), defined in an XML file. The output of this phase will be the Courant-Snyder (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, so new output files will be designed for that (XAL, or some other XML).
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 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#td_GW1 (the inputs "from PV" that produced good optics), 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.
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.
