Major Components

This is a basic list of major components in the LCLS applications system. Each of these will require significant requirements and design work. The comments following are only an extreme outline.

BASIC DESKTOP APPLICATIONS FRAMEWORK

PRJ-BA: This is the basic foundation of the client application framework. Using this framework only, a developer can proceed to write an application.

  • Design and implement the way the appropriate control network (EPICS_CA_ADDR_LIST, AIDA_MODE etc) is defined and implemented at runtime.
  • Directories and version control. Suggest 3 versions of eclipse? (SLAC wide, plus our own dev, plus prod).
  • Installation of basic components; XAL, Eclipse, JCA, Aida, (which if any Control System Studio - CSS eclipse plugins?). Suggest CSS probe, CSS DataBrowser iff tested and found reliable. Probably PV Logger only as distinct project.
  • Distribution System to desktops, especially control room heads (eg "kiosks").
  • Launching displays and external applications

JCA fixes for Eclipse interoperability, see project #PRJ-JCAJNIFIX.

BASIC MODELLING ENVIRONMENT

This will proceed in 4 phases:

Phase 0: SLC Modelling System.

For BC-1 commissioning, physicists will use the SLC online model system. DIMAD decks generated in the familiar way. The only addition will be to use AIDA's interface to the SLC model system for new (matlab) applications and ad-hoc analysis in matlab:

PRJ-ADDFILEMODELDATA: Add to the model data acquisition already in Aida, the ability to get QUAD, BEND etc data from SLC model output file.

Phase 1: Put Mad model run results in the Oracle database.

PRJ-MODELARCH: In this phase we will architect the model hierarchy - how one or more model sections comprise a beamline [#REF-SLCBMLS], and the beamline modelled in one or more energy profiles (aka "Twiss modes") [#REF-MBITS]. A requirement clear from SLC/PEPII experience is that > 1 model and its consequent set of twiss/R params should be storeable in the DB for each beamline (in each twiss mode); that is, not just the design model run with extant values, but a test lattice with test and extant settings too. Hence, 4 combinations of the two input types should be supported:

  1. design lattice + extant settings (PV values) - aka "database"
  2. design lattice + design settings - aka "design"
  3. test lattice + extant settings (PV values)
  4. test lattice + test settings

PRJ-RUNMODEL: Simultaneously we will create a Mad model server, that runs those models. Modelling the extant machine will be done by running the mad input through a filter, which will find the epics PV or slc db name associated with each device (via the "symbols" Oracle schema), and create an file which can be run by Mad.

PRJ-TWISSTODB: The resulting Twiss and R-mat will then be loaded into Oracle.

PRJ-BDESTOKMOD: We will need a "bdes-to-kmod" as part of this. If after analysis that seems hard, we should consider jumping straight to phase 2, since XAL's tracking will acquire klystron readings and make the conversion directly, at the time of tracking, so in this respect it would be easier than implementing an online model system for Mad.

Phase 2: XAL MODEL

Q: To Decide: Are the model inputs for this phase hand written XAL input files, or generated from the DB? I suggest they're hand written, or at least hand tweaked from the DB, rather than a fully automatic and reliable process. The full reliable process should be codified as Phase 3.

PRJ-XALMODEL: Functionally as phase 1, but for XAL. Phase 1 precedes phase 2 since we already have a Mad model.

PRJ-XALACCEL: Phase 2 will additionally involve adapting XAL for the LCLS beamline requirements (acceleration, solenoid)

Create a model server for XAL. The model server runs (in XAL language it's called "probe") the input file on demand. That is to say, this is not a continuous accelerator simulator. The output Twiss and R-matrices will be "persisted" to the Oracle database (just as in phase 1), so both Mad and XAL model runs are in the DB.

Q: Should we make a project to probe an XAL beamline to produce a regular 6x6 transfer matrix, as opposed to the correlation matrix now output by XAL?

Q: Should we write a plane coupled probe for XAL?

Phase 3: Generate Models from Online DB

PRJ-MODELSAUTOGEN: Automatic generation of online "design" models' source files (XAL and MAD) from the Oracle database devices, plus design values in the DB.

Model Diagnostics

Two model utility applications are needed:

PRJ-MODELOPTICS: Additionally we must create a LIPS application for helping a user submit models to be run (the SCP "Optics" panel)

PRJ-MODELDIAG: a way to view the twiss and Rmat of a single device, and Rmat "a to b". This is part of phases 1, 2 and 3 above.

DATA ARCHITECTURE

This section outlines projects to support the requirement for control setpoint processing ("set") and read data ("get"), for online physics applications.

Control Data

PRJ-SAIOCCOMP: Completion of the "SLC Aware IOC" project, and Beam Synchronous Acquisition and Control (BSAC) in particular.

PRJ-JCAJNIFIX: Fixes to JCA, using the JNI interface. JCA through the JNI interface to CA must be fixed to be operable within Eclipse. We will not use the JCA interface through CAJ due to other errors which are probably more serious. See #DECN-JNIJCA

PRJ-ADDXMLTOAIDA: Add XML data packaging to AIDA. This facilitates trivial structured data display, since AIDA will have prepackaged the data for rendering via a cascading style sheet (CSS) to an xhtml "browser" display (although we won't use a browser in the normally understood sense, we'll use the built in Eclipse browser.

Model Data

PRJ-DBDATAVIAAIDA (sm) : Oracle DB access through AIDA.

Model data will be stored in the Oracle database after phase 0 (see #PRJ-MADTWISSINDB, #PRJ-XALMODEL). Modelling applications should be able to easily acquire that data (that is, without direct JDBC calls). The same solution to that problem can be generalized trivially for other applications both in LIPS and outside, so that they are able to access the DB without specific knowledge of the schema. So we shall create a simple AIDA data server for retrieving Oracle DB data, in which the SQL statement itself can be stored in the AIDA db, so the application need only know the name of the AIDA instance/attribute pair (like an EPICS PV) which is then translated by the AIDA Nameserver system, into an SQL query, which this new AIDA Oracle DB Data Provider then retrieves.

Eg TORO:23:IM20's TWISS params for energy profile 3 == AIDA query "TORO:23:IM20//Twiss Mode=3", translated by AIDA nameserver to the SQL query "select twiss from symbols.twiss where device = 'TORO:23:IM20' and mode = 3" and this string is then used by AIDA's Oracle DP to retrieve the value.

Textual Displays

PRJ-DISPMAN (med): Create a standard textual display system.

This system is intended to make very trivial the process of displaying formatted, tabular, textual data on the display. Since much of the bulk data a physics GUI application will want to display will have been retrieved from some system like Oracle or AIDA, that is able to get bulk tabular data in one call, if that data were retrieved as XML, then rendering it to a display would be trivial using Cascading Style Sheets to create either tabular text, or simply xhtml. If the display language were xhtml, then the display driver would be the web browser already in Eclipse. Writing a display would then be a matter of writing the data acquisition; the display formatting would be defined in CSS (Cascading Style Sheets).

data (Oracle, JCA, Aida) -> XML "Serialization" -> CSS -> xhtml (displayed in any viewer, eg Eclipse).

Textual displays described as such could then be mixed with Channel Access data brought in directly through webCA. The AJAX mechanism would be used to mix the two in a smooth user interface (no page redraw for every new data fetch etc).

Associated project #PRJ-ADDXMLTOAIDA.

Notes

  • Visualizing 3-d data.

Working Decisions and Standard Practices

DECN-JNIJCA: We will use the JNI interface of JCA, rather than CAJ interface, until CAJ is fixed. In particular CAJ is reported to easily overload IOCs and crash them.

Bibliography and References

REF-SLCBMLS. SLC/PEPII Beamline Definitions, http://www-mcc.slac.stanford.edu/%7Egreg/MODEL_SKEL.HTML
REF-MBITS. Steph's old email about how SLC DB MBITS define which "twiss modes" a device is modelled in, http://www-mcc.slac.stanford.edu/%7Egreg/MODEL_PROG_GUIDE_MBITS.TXT

  • No labels