Page History

This document describes a possible software architecture for online physics applications in the Linac Coherent Light Source. The LCLS .

...

is an electron particle accelerator and coherent x-ray laser being developed at Stanford University to study phenomena in the 1.5 - 15 Ångstrom, 1-230 femtosecond realm.

Author: Greg White, Dec 2005, Stanford Linear Accelerator Center. 

INDEX

1. Objective
2. Desktop
3. Basic Modelling Environment
4. Architecture
5. Applications
6. Matlab
7. Error Handling, Logging and Viewing
8. Tool Summary
9. Red Flags
10. Required Additions to SLC Control System
11. Required Solutions
12. Job List
13. Questions
14. R&D
15. Details
16. Glossary
17. References

...

High-level applications packages refers to the controls software used by physicists and
accelerator operators to:

• tune or optimize the beam,
• to keep the beam running stably in the optimized state,
• monitor performance for long-term optimization
• to diagnose problems with machine performance
• detect, prioritize and notify of fault conditions

Here we outline the support for accelerator optics modeling in XAL, and in the exiting online SLC control system, and include 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 highlight 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

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 (see Filesystem). Each user (including control room heads) additionally requires require their own configuration file area - therefore 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.

...

XAL (that is JFC/Swing) and SWT/Jface applications may be used on any X11 equipped workstation (Windows PC, Solaris) with some performance degradation because JFC/Swing performs poorly over X11 (even in Java >=1.4). These apps could be run "natively" on Windows (since Swing is pure Java, which is platform independent, and any SWT components could be delivered for Windows too). However, the added complexity of synchronizing filesystem resources between the Unix filesystem and the Windows filesystem probably makes this option undesirable - see Redflags. Hence, Proposal: no native Windows apps, Windows only over X.

...

1. Eclipse external launching (EPICS displays, archive viewer, and MCC SCP are shown launched, but many are available: eg matlab, xterms, DECterms on MCC, Elog, Physics Log).
2. Eclipse launching external VM java SWT/Jface application (jcmlog shown in bottom right)
3. Eclipse launching internal VM java SWT/Jface application (aida probe shown bottom right)
4. Eclipse launching external VM java JFC/Swing (XAL) application (NOT SHOWN YET)

...

In addition to the overall lattice modeling framework and interface to device control, XAL provides one GUI Application framework (based on JFC/Swing) (though not all XAL applications use this framework, even if they use JFC/Swing - #see ref_XAL_applications. All the existing XAL applications, using the aplication application framework or not, will be provided through "lips" such, such as Scan ("Correlation Plots"), SCORE ("configs"), XIO ("z-plots"), or just the XAL root application.

...

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. Such applications may be expected to run with better performing use interfaces (though there is some controversy over this point in the literature) and have native look and feel (as opposed to JFC/Swing apps that always have the Swing look and feel of the operating platform).

See also Application Framework Architecture

...

Use Case: A beamline physicist will provide MAD, Parmela or Elegant files (see #ref ref_latticefiles). 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 (See questions). 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.

...

For LCLS, we will pre-compute the optics from the lattice, to produce the XAL files which include the Twiss params, so each modeling application doesn't have to track a lattice for itself before starting. The online modeling "tracker" will be that in XAL (primarily in the gov.sns.xal.model package). The output of this phase will be the 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 (path length, energy, betamax), so new output files will be designed for that (either extending the XAL syntax, or creating some other XML file). proposal: write tracker to probe Twiss params and (coupled - see Red Flags) R-matrices, and additionally output global parameters to a file.

...

As stated repeatedly elsewhere, the existing SLC applications, such as correlation plots, steering, bumps etc, can be used to access LCLS beamline orbit and control data. That is, SLC apps will work for LCLS. This is ensured by the "SLC-aware-IOC" project, in which VMS hosted SLC control system signals will be processed by field IOC's IOCs, and data returned in a manner transparent to the VMS SLC control system.

...

At the time of writing it has not been decided which new history data system to use LCLS. The nominal EPICS archive protocol stack is given at left. Paul Chu reports that in LCLS. Paul Chu reported that specific experiments in the SNS used PVlogger rather than EPICS archiver where possible, but that the archiver is used as a general history facility. It's not clear whether performance questions related to the EPICS archiver are specific to the archive browser, or to data retrieval in general.

The nominal system would be that below. The EPICS archiver protocol stack is given at left. The existing SLC history system is show at right; SLC history data can now be acquired by new applications or by matlab through Aida.

...

...

err=Err.getInstance();
err.log("I got an error");

ERROR HANDLING, LOGGING AND VIEWING

A programmer spends half their time handling errors, so making that as easy as possible is a productivity priority. For LCLS we will use the following technology stack:

Err package (see http://www.slac.stanford.edu/grp/cd/soft/err/^{Image Removed}) makes the process of rigorously handling errors easy. It allows a programmer to define an error code in a structured, recorded global way; and to use that code to issue errors and associated diagnostics from or linux, solaris, windows platforms in either java or C/C++, and issue them directly to CMLOG (or some other message logger). It includes support for exception chaining ("caused-by") and exception translation, so the end user can see what systematic thing caused their functional problem (E.g. of a error logged by Err in cmlog might be "UnableToTrackBeamlineException: LCLS ; caused by FileNotFoundException: LCLS.XML when attempting to steer LCLS".

...

...

Some important choices or questions.

1. *SLC CAMAC Magnet control and SLC BPM data acquisition by XAL Applications.*The SLC CA server does not presently support "set" operations, so there is not presently a way for XAL applications, which use EPICS Ca through JCA, to change the value of CAMAC magents. Possible solutions are to add set to SLC CA, or to change XAL applications to use AIDA, or to accept that XAL applications can not control SLC CAMAC magnets - that would be bad for orbit correction for instance, since most magnets in the linac will be SLC control system. Similarly, the SLC-aware-IOC and EPICS BPM acquisition API will allow both an XAL based application, or the SCP, to acquire IOC hosted BPMs, but are there "classical" SLC BPMs that must be acquirable by XAL applications.
2. *XAL uses JFC/Swing - will that be too slow?*Have to evaluate the user interface GUI performance of XAL apps in different platform and network configs. In particular we propose to host apps only on Linux, which means many users will be displaying over ssh tunneled X11 to their PC using xwin32.

   Anchor
   WindowsFilesystem WindowsFilesystem

3. Windows filesystem.
   If we do require native execution on Windows that decision should be made clearly and early, and resources assigned to implement the common executable and configuration file distribution so that Unix and Windows running applications are in sync and see the same configuration files. Java Web Start and Eclipse update site technology may be places to find solutions. Use of Matlab from Windows for instance requires some well known Windows filesystem home for the matlab support files.

   Anchor
   XAL_nocoupling XAL_nocoupling

4. XAL Plane Coupled modeling.
   The existing XAL probes for calculating R-matrices, run on either the X-plane or Y-plane and returns only a 2x2 matrix for each element. That is, it's uncoupled. This is reflected in the fact that only the Twiss parameters can be stored into an XAL file - it only contains uncoupled optics. It may be that XAL is in fact tracking a plane coupled system, but only returning the X or Y plane block-matrices - need to verify. So, if plane coupled orbit correction is important for us, we need to verify what XAL is doing, add at least 4x4 probe API, also probably also 6x6 tracking.
5. XAL Modelled acceleration and solenoid. XAL does not model acceleration completely, nor solenoid field see Questions
6. Archiver. Which one?
7. XAL file generation directly from Oracle. Is there a mechanism to flag items in the oracle db for inclusion in the lattice? Danger is people will edit the Oracle db to say move an item to a new z location or include a dummy bpm, and the lattice will change.
8. Scripting. It may be that the requirement for user-level scripting of complex operator procedures is a requirement. Scripting user level procedures, for instance button-pushes on GUI applications, as opposed to control-system PVs, will be hard.
9. Matlab. It's expensive and we may be highly reliant on it especially at first (see Questions).

...

1. XAL http://www.sns.gov/APGroup/appProg/xal/xal.htm
2. XML entry in Wikipedia http://en.wikipedia.org/wiki/XML

3. Anchor
   ref_latticefiles ref_latticefiles

   LCLS lattice files http://www-ssrl.slac.stanford.edu/lcls/linac/optics/
4. JAMA http://math.nist.gov/javanumerics/jama/

5. Anchor
   ref_XAL_applications ref_XAL_applications

   http://www.diamond.ac.uk/CMSWeb/Downloads/diamond/Events/EPICS/XAL_Applications_Correlator_Framework.pdf^{Image Removed}

...

1. Acquisition through JCA should also be verified, since the SLC BPM acqusition is oriented toward acquisitions of whole beamines and is highly parameterized.
   ANS: Diane (posted by Greg): the EPICS BPM API will largely mirror the SLC BPM API in that it will be oriented toward acquisitions of beamlines and allows specification of timing parameters. Greg: That's ok then as long as the setup required in an application is invariant whether it's talking to an SLC BPM through the SLCCAS (and if there is any requirement in LCLS apps to talk to SLC BPMs) or a new IOC hosted BPM.
2. Does XAL offer matrix manipulation, linear algebra and fitting adequate for the LCLS? Ans: yes, uses JAMA.

To add to this document

Basic Architecture FAQ

Desktop

x86 Linux RH, KDE/GTK window system. Apps will run on the desktop host (not over X11). Control room heads will simply be an example of this, ie locally on a kiosk or sunray (running linux/GTK). Windows later; Mac later. Apps can be run over X11 onto Windows and Mac in offices (with some performance degradation).

Frameworks

Eclipse Rich Client Platform (RPC) and XAL applications. Therefore mixing Eclipse (SWT/Jface) and XAL (AWT/Swing). Control System Studio Eclipse plugins will be used as they mature.

Modelling

4 phases: 1) for BC-1 use SLC model system, data retrieved over AIDA; 2) MAD twiss/R-mats persisted to Oracle db, applications and ad-hoc physicists apps in Matlab use AIDA to retrieve optics; 3) XAL, twiss/R-mats persisted to Oracle, existing XAL apps use XAL files, new XAL apps we write use Oracle; 4) As 3, but XAL input file is generated from Oracle device list.

Databases

Oracle, SLACPROD for "prod", SLACDEV FOR "dev". Program access by jdbc, AIDA, hibernate.

Applications Servers (for web based applcations)

3 Application servers: 1) Oracle APEX (aka Application Express, aka ORAWEB) for items managed by the LCLS Database team; 2) tomcat, for physics elog, and other web applications.

Display and Plot generation.

Textual displays defined by xml data + css (Casscading Style Sheet) producing xhtml rendered by browser in Eclipse.

Plotting by GnuPlot v4, or possibly JAS. The last data plotted will be immediately available in an octave window.

Help

By Eclipse help system.

Error handling

err.stanford.slac java package. errors issued to cmlog db. Default browser will be jcmlog.