...
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
...
:
...
Anchor | ||||
---|---|---|---|---|
|
- 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:
Anchor | ||||
---|---|---|---|---|
|
Phase 1: Put Mad model run results in the Oracle database.
Anchor | ||||
---|---|---|---|---|
|
- design lattice + extant settings (PV values) - aka "database"
- design lattice + design settings - aka "design"
- test lattice + extant settings (PV values)
- test lattice + test settings
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
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.
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
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
Anchor | ||||
---|---|---|---|---|
|
Model Diagnostics
Two model utility applications are needed:
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
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
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Model Data
Anchor | ||||
---|---|---|---|---|
|
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
Anchor | ||||
---|---|---|---|---|
|
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
Anchor | ||||
---|---|---|---|---|
|
Bibliography and References
Anchor | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|