...
| Wiki Markup |
|---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="15f73cdafcaaf1ad-06e41d43-4d004466-a8eba4cd-8cdf1bd6f1837c4623961ed4"><ac:parameter ac:name="">PRJ-MODELARCH</ac:parameter></ac:structured-macro> *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: |
- 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 |
|---|
| PRJ-RUNMODELMADRUNMODEL |
|---|
| PRJ-RUNMODELMADRUNMODEL |
|---|
|
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.
| Anchor |
|---|
| PRJ-TWISSTODBMADTWISSTODB |
|---|
| PRJ-TWISSTODBMADTWISSTODB |
|---|
|
PRJ-TWISSTODB: The resulting Twiss and R-mat will then be loaded into Oracle.
| 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.
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)
| Anchor |
|---|
| PRJ-XALRUNMODEL |
|---|
| PRJ-XALRUNMODEL |
|---|
|
Create , and creating 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. 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
...
