Elegant users forum

Hi Michael,

Normally people want to maintain a single lattice file with a specified starting point. However, for some applications, for example injection and extraction simulations, as well as local momentum aperture simulations, one needs to rotate the lattice and start tracking from a different element but at the meantime keep all the lattice settings. I don't know the detail about how you managed to handle this issue in the built-in momentum_aperture command, but I think it could be helpful to add some commands to allow the users to adjust the start of the lattice for further tracking. At least one could rotate the lattice and dump it to an external file using save_lattice and then call the new lattice later, so that the whole procedure could be scripted rather than done manually.

Best,

Zhe

Zhe,

You can use the BRANCH element to do this. E.g., This will result in elegant tracking through PART1, PART2, PART3, followed by a jump to PART3 again, after which it will track (PART1, PART2, PART3) repeatedly (if n_passes is set appropriately).

Using alter_elements, you can change the branch point, e.g., The manual gives several examples of using this. For example, one can implement a periodic bypass. Also, the ON_PASS parameter of MALIGN can be used for imparting kicks at arbitrary locations on specified turns.

--Michael

Hi Michael,

One thing still not clear to me, is how the closed_orbit command treats a rotated ring using a BRANCH element like the following syntax:

M0: MARK
M1: MARK
BR1: BRANCH, BRANCH_TO="M0", ELSE_TO="M1", counter=1, DEFAULT_TO_ELSE=1
RING: LINE=( BR1, M0, PART1, M1, PART2 )

I would like to calculate the closed orbit of the ring w/ M1 as the starting point, but the above syntax means that the first turn of tracking through the line covers only PART2, does the closed orbit calculation consider the PART2 as the whole storage ring?

I did some test and got the following output:

Starting point for closed orbit
-nan, -nan, -nan, -nan, 0.000000e+00, 4.239921e+153

If my understanding is correct, this is result of your first step of closed orbit calculation, using transfer matrices to obtain a guess for the closed orbit, which would be then be used as the initial values for the second step of closed orbit calculation using symplectic integrators. Does this hint that using BRANCH in this manner together with closed_orbit is not supported?

Thanks,

Zhe

Zhe,

To handle things in full generality, we'd need something other than the BRANCH feature. It really is intended only for tracking.

I'll think about how to do this. It shouldn't be hard.

--Michael