LCLS Online Physics Applications Outline
From 20000 ft.
This document describes a possible architecture for physics applications for the LCLS. It outlines the existing support for accelerator optics modeling in XAL and in the online SLC control system, and includes recommendations for a technology track, the process for XAL modeling, how SLC and XAL modeling can be brought together to meet the commissioning schedule, and highlights issues that will require attention. It is assumed that both the SLC modeling environment and SCP applications will be replaced by XAL based equivalents over some period.
Desktop Hardware and Filesystem
Our target desktop processors will be x86 CPUs running RedHat linux, with the GTK window system (see details). The executables may be housed on either AFS or NFS filesystems, little difference. Each user (including control room heads) additionally requires their own configuration file area - the precise configuration seen by each head may be unique therefore. This is a feature of XAL and the other desktop technologies we'll use. That configuration file area will be NFS because a long-lived executable (>25hrs - the AFS token lifetime) must be able to write to it at any time.
X11
XAL (that is JFC/Swing) and SWT/Jface applications may be used on any X11 equipped workstation (Windows PC, Solaris) with some performance degradation since JFC/Swing performs poorly over X11. These apps could be run "natively" on Windows (Swing is pure Java, which is platform independent, and any SWT components could be delivered for Windows too, but the added complexity of synchronizing filesystem resources between the Unix filesystem and the Windows filesystem probably makes this option undesirable - see questions) and redflags.
Overall User Interface
Use Case: A user (physicst or operator) types "lips" (or iscp or any other name we like) at a Linux console - a GUI based application launches. This application can launch any EPICS display (DM, dm2k etc), any XAL application, the SCP (on MCC), or any EPICS extension application like archive browser, alarm handler watchdog, stripchart, cmlog browser etc. These are launched on the correct host for that application or display. The "local" messages generated by each application appear in a console window dedicated to that application - "global" messages appear in the jcmlog browser window.
Starting Applications
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.
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.
