Page History

...

Anchor
PRJ-MODELARCH PRJ-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 teh the two input types should be supported:

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

Simultaneously we will create a Mad model server, that runs those models.

Anchor
PRJ-MADTWISSINDB PRJ-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. The resulting Twiss and R-mat will then be loaded into Oracle. REQ-DESANDTESTTODB: 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.

...

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. Phase 2 will additionally involve adapting XAL for the LCLS beamline requirements (acceleration, solenoid), and creating a model server for XAL. The model server runs (in XAL language it hall "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. That is to say, this is not a continuous accelerator simulator.

Phase 3: Generate Models from Online DB

Anchor
PRJ-MODLEAUTOGEN PRJ-MODLEAUTOGEN

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

Model Diagnostics

Two model utility applications are needed:

1. Anchor
   PRj-MODELOPTICS PRj-MODELOPTICS

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

2. Anchor
   PRJ-MODLEDIAG PRJ-MODLEDIAG

   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.

...

Anchor
DECN-JNIJCA DECN-JNIJCA

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

Anchor
REF-SLCBMLS REF-SLCBMLS

SLC/PEPII Beamline Definitions, http://www-mcc.slac.stanford.edu/%7Egreg/MODEL_SKEL.HTML^{Image Added}
[anchor: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 Added}