Page History

...

PRJ-BA:

Anchor
prj-ba prj-ba

Architectural and network design; including; 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

...

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

Anchor

unmigrated

PRJ-

wiki

MODELARCH PRJ-

markup<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="1e0dcc68-bb15-4203-b5cf-15390cca45f5"><ac:parameter ac:name="">PRJ-MODELARCH</ac:parameter></ac:structured-macro> *

MODELARCH

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]\]. 4 combinations of the two input types should be supported: . 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 "designdatabase"
2. design lattice + design settings - aka "databasedesign"
3. test lattice + extant settings (PV values)
4. test lattice + test settings

Anchor
PRJ-MADRUNMODEL PRJ-MADRUNMODEL

PRJ-RUNMODEL: Simultaneously we will create a Mad model server, that runs those models. AnchorPRJ-MADTWISSINDBPRJ-MADTWISSINDB PRJ-MADTWISSTODB: 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.

Anchor
PRJ-MADTWISSTODB PRJ-MADTWISSTODB

PRJ-TWISSTODB: The resulting Twiss and R-mat will then be loaded into Oracle. A requirement clear from SLC/PEPII experience is that > 1 set of twiss/R params should be storeable in the DB for each beamline (in each twiss mode), not just the design model run with design and extant values, but a test lattice with test and extant settings too. That is, all 4 combinations above.

Anchor
PRJ-BDESTOKMOD 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: 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
PRJ-XALMODEL PRJ-XALMODEL

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

Anchor
PRJ-XALACCEL PRJ-XALACCEL

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

Anchor
PRJ-XALRUNMODEL PRJ-XALRUNMODEL

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 model inputs for this phase will be a hand written XAL input files. 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

...

Anchor
PRJ-ADDXMLTOAIDA 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.

Model Data

Anchor
PRJ-DBDATAVIAAIDA PRJ-DBDATAVIAAIDA

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

For phase 1 of model development we will continue to use Mad, where the model results are put in the SLC database (See #PRJ-MADTWISSINDBModel 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.

...

Anchor
REF-SLCBMLS REF-SLCBMLS

REF-SLCBMLS. SLC/PEPII Beamline Definitions, http://www-mcc.slac.stanford.edu/%7Egreg/MODEL_SKEL.HTML^{Image Removed}

Anchor
REF-MBITS REF-MBITS

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^{Image Removed}