Create a new lattice modelling with shifting elements

[xresende]

new idea to be expanded.

[xresende]

• would allow for elements with interpenetrating fields (no interaction approximation)
• would allow for more aggressive lattice optimizations (which would probably be non-implementable)
• would allow for more systematic optimizations of the orbit correction system.

[fernandohds564]

I didn't understand the idea, @xresende.

[xresende]

The idea is: instead of defining the lattice as a sequence of consecutive elements, you define each element with its internal data (length, field profile, strengths) and its longitudinal position. A lattice would be a list of 'boxed' elements with internal data and its location along the circumference where it is to be place. This way you could define the lattice incrementally in (in my opinion) a more intuitive way : first define the circumference, then dipoles, then quadrupoles, sextupole, correctors, etc. I believe this has the potential to ease optimizations where you also want to vary the location of elements. I have in mind, for example, optimization of orbit correction system where you mat want to vary the number and locations of BPMs and correctors. Emittance and dynamical aperture optimizations may be easier with this kind of model.

Moving or adding elements around the lattice with these lists of boxed elements will be much easier. (think of how many small changes have been perfomed on the SI and BO lattices).

Naturally for tracking and Twiss calculation purposes this list of boxed elements would have to first be translated to a traditional lattice with consecutive elements.

One more benefit of boxed element lists is that you can have independent elemnts with field profiles that intersect in space.

[liulin-lili]

I can think of disadvantages in using boxed element lists too: it is hard to see the distance between adjacent element borders, and thus hard to decide, for example, if a BPM can be placed between a quadrupole and a sextupole. It is also easier to misplace elements, for example, by moving or placing elements that collide physically with and existing element. It is also harder to see what element is next to what.

[xresende]

I agree with all the issues you raised. The idea is not to abandon the
current concatenation model but to add a layer of abstraction on top that
could be used for optimization purposes. The concatenation model would
still exist for, among other things, the reasons you listed.

On Thu, Sep 24, 2015 at 5:58 PM, Liu Lin notifications@github.com wrote:

I can think of disadvantages in using boxed element lists too: it is hard
to see the distance between adjacent element borders, and thus hard to
decide, for example, if a BPM can be placed between a quadrupole and a
sextupole. It is also easier to misplace elements, for example, by moving
or placing elements that collide physically with and existing element. It
is also harder to see what element is next to what.

—
Reply to this email directly or view it on GitHub
#7 (comment).