Complete Multiple Beam Line Support

[Laurie Nevay]

Issue to keep track of progress towards supporting multiple beam lines. Currently, we can place multiple beam lines, but not track in them. Also the sensitivity will have the wrong curvilinear coordinate system.

Issues to be resolved / completed:

• extend auxiliary navigator to be w.r.t. a particular beam line -> fixes tracking
• separate eloss hits branch for each beam line
• ensure energy counter SD records pointer to beam line and index in mass world for that one
• check collimator hits for each beam line
• collimator information for all beam lines (currently only main beam line)
• consider a 'join' element - dipole with outgoing angle points?

[Laurie Nevay]

• Define policy for S coordinate (0, continuation, joining) (case of 3 branch ERL).
• Primary Frist Hit & Last Hit S (add beam line index too)
• Placements w.r.t. beam line must be able to choose beam line
• All things that inherit placement must be able to do this (sampler placement, scoring mesh, blm placement, general placement
• Consider that beam lines may both split and join again - do they align correctly - check alignment / matching up

‌

[Laurie Nevay]

• The synchronous time and phase for any time dependent elements (rf, field maps, lasers)
• The T0 for that beam line

‌

[Laurie Nevay]

• The Model tree should be augmented / revised to account for multiple beam lines
• The survey output will currently overwrite the same survey file so therefore only the last one is there.

‌

[William Shields]

The survey output overwriting issue has been fixed in develop. Each placement beam line is now written out to a separate file using the supplied survey file name appended with “_” plus the placement name. The main beam line is still written out to the original survey file name.

[Laurie Nevay]

Commenting to bring back to the top.

[Laurie Nevay]

For the Model tree we should also now include the nominal Ek and P of the design particle along the line as it can vary and is calculated by the code from the input so useful to know.

When multiple beamline support is added the Fill method for the model should take a set (or vector) of beamlines as an argument rather than get them from the singleton BDSAcceleratorModel inside the Fill function (to be clearer).