...
Phase 1: Put Mad model run results in the Oracle database.
| 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]. 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: | Wiki Markup |
|---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="f9bb7512-fa29-444b-a489-2ad723d3acda"><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
...
REF-SLCBMLS. SLC/PEPII Beamline Definitions,
http://www-mcc.slac.stanford.edu/%7Egreg/MODEL_SKEL.HTML
Image Removed 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.TXTImage Removed
