...
| Wiki Markup |
|---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="e2213ecdf32e5461-b2e60aaa-43c8418e-b824ae5c-e9e37bcd0fed93296d23b3ae"><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]\]. 4 combinations of the two input types should be supported: |
...
| 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.
...
