Page History

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.

h3. BASIC DESKTOP APPLICATIONS FRAMEWORK

*PRJ-BA*:

 {anchor

:prj-ba

} Architectural and network design; including;

* 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

* Launching displays and external applications

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

].


h3. BASIC MODELLING ENVIRONMENT
This will proceed in 4 phases:
# Phase 0: 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. {anchor:PRJ-ADDFILEMODELDATA} *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 {anchor:PRJ-MADTWISSINDB} *PRJ-MADTWISSTODB*: Put Mad model run results in the Oracle database. Both "design" and "extant" machine should be supported. 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 output file which can be run by Mad. The resulting Twiss and R-mat will then be loaded into Oracle. 
{anchor:PRJ-BDESTOKMOD} *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: Functionally as phase 1, but for XAL. Phase 1 precedes phase 2 since we already have a Mad model. Phase 2 will additionally involve adapting XAL for the LCLS beamline requirements (acceleration, solenoid), and creating a model server for XAL.

  
# Phase 3: Automatic generation of the online model source files from the Oracle database devices.

h4. Model Diagnostics

Additionally we must create a LIPS application for helping a user submit models to be run (the SCP "Optics" panel), and 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.

  

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

h4. Control Data

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

# {anchor:PRJ-JCAJNIFIX

} *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 [#Decision-JNIJCA

]
# {anchor:prj-ADDXMLTOAIDA

} *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.
  
h2. Textual Displays
{anchor:PRj-DISPMAN} *PRJ-DISPMAN*: 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 xhtml, thne 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). 
 
Antecedent project {PRJ-ADDXMLTOAIDA}.

h2. Notes
* Visualizing 3-d data.

h2. Working Decisions and Standard Practices
{anchor:Decision-JNIJCA} Decision-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.