...
| Wiki Markup |
|---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="da86afebe9ae8d6a-57a3d64f-49ed4fff-91f49523-31855e29922535847b42ea6e"><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: |
...
PRJ-RUNMODEL: 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 file which can be run by Mad.
| Anchor |
|---|
| PRJ-TWISSTODB |
|---|
| PRJ-TWISSTODB |
|---|
|
PRJ-TWISSTODB: The resulting Twiss and R-mat will then be loaded into Oracle.
...
