Intentional misalignment

[tpersson]

Missing feature in MAD-X: A way to introduce intentional misalignments of elements.

Proposal: Add attributes to every element that enables that: x_offset y_offset phi_offset psi_offset theta_offset

The physics will be the same as for misalignment (at least initially) except for SURVEY where it will be considered.

Things to solve/discuss: Should we have a vector instead of individual attributes? We can’t print them easily from MAD-X. Should we only be able to assign it to the element or also to the node? Can we prevent this problem of updating an element quietly disregarding all changes without slowing down the code?

When exporting to PTC, can it be included in the SURVEY like command to plot a sequence?

[rdemaria]

Great! Here my comments:

The inclusion of offset in survey needs to be optional (or vice-versa in twiss), otherwise it would become impossible to combine the orbit in twiss or track to compute trajectories in the laboratory frame. Same applies in PTC I think, although I am not familiar with the conventions there. By default I would assume the offsets do not change the survey (no jump in both survey and twiss for the PS use case) and add a flag in survey and twiss like "offsets_chage_ref" with which the offsets change the reference frame (jumps in both survey and twiss). In this way i

Another point is for aperture. When an element with an offset has an aperture, is the aperture defined with respect to the "machine" reference frame or the "element" reference frame? We should be able to support the case in which the aperture follows the element (use cases in LHC) and the case in which it does not (at least one use case in PS). This could be achieved for instance by assuming the conventions that the aperture follows the element, and aper_offset is extended to 6 values to be able to undo those of the element if required.

I prefer individual keywords since very often only one component will be used and it avoids remember the meaning of each index. On the other hand. I see from the implementation point of view a clear advantage from using a vector in terms of code and memory.

I think it would be useful if one could access the node information using a similar syntax of the beam command, such as

mbx.4l5@lhcb1->x_offset
mbx.4l5@lhcb2->x_offset
mbx.4l5@lhcb1->at
mbx.4l5@lhcb2->at

This should solve the issues with the assignment to the element including the update to the element.

[tpersson]

Thanks for your fast feedback!

My understanding was that we needed a flag in SURVEY that if used includes the offsets. If I understand correctly you would also like an offsets_change_ref which then changes the reference frame in TWISS in the same way as done with translate and rotations? This is clearly possible but adds a bit of complication since this is not then just the same way as the errors works in TWISS and TRACK. One would have to record the position before the back transformation.. What is the use case for this?

The aperture is indeed another issue. For it to follow the element is what the normal implementation would be like. When it comes to the case of PS I think one solution would be to simply place e.g. collimators around the element with the correct aperture. In some way that is more correct since the aperture is not limited by the element but the beam pipe.

[ldeniau]

Thanks for opening the ticket and making a proposal.

Missing feature in MAD-X: A way to introduce intentional misalignments of elements.

Proposal: Add attributes to every element that enables that: x_offset y_offset phi_offset psi_offset theta_offset

Would it be possible to use the same convention as in MAD-NG where everything is already implemented for a while... MAD-NG uses the same names as the MAD-X EALIGN command for consistency, namely, translate: dx, dy, ds (ds is treated as a drift with no time-of-flight correction). rotations: dtheta, dphi, dpsi To avoid any confusion in the convention, the same names are used for the element changeref (a property of the frame), the element absolute misalignment (a property of the element), and the element relative misalignment vs a sequence (a property of the link element-sequence). Concerning the selection, absolute misalignments and patches are always considered, while relative misalignments vs sequences are only considered by survey and track/twiss/cofind/etc if the attribute 'misalign' is set to true (false by default).

For physics, MAD-NG is exact for any angles and offsets because the code uses the functional application of maps (not composition) whether they are based on TPSA or not, while Twiss composes an expanded version of the rotations plugged into matrices, which the most approximative for large angles...

The physics will be the same as for misalignment (at least initially) except for SURVEY where it will be considered.

Things to solve/discuss: Should we have a vector instead of individual attributes? We can’t print them easily from MAD-X.

I suggest sticking to attributes with the aforementioned names for consistency with tables, EALIGN, and other potential uses.

Should we only be able to assign it to the element or also to the node?

EALIGN already provides assignments to nodes. Using the aforementioned element's attributes allows doing the same to elements easily with tables, loops, macros, etc.

Can we prevent this problem of updating an element quietly disregarding all changes without slowing down the code?

From our previous discussion, updating an element should not have any effect and should emit a warning for compatibility with your new check for "at" and "from". Absolute misalignments should be set during element creation and updated outside sequence creation.

When exporting to PTC, can it be included in the SURVEY like command to plot a sequence?

No idea, need some investigation. Maybe Piotr already knows the answer.

Cheers, Laurent.

[ldeniau]

Great! Here my comments:

The inclusion of offset in survey needs to be optional (or vice-versa in twiss), otherwise it would become impossible to combine the orbit in twiss or track to compute trajectories in the laboratory frame. The same applies in PTC I think, although I am not familiar with the conventions there. By default, I would assume the offsets do not change the survey (no jump in both survey and twiss for the PS use case) and add a flag in survey and twiss like "offsets_chage_ref" with which the offsets change the reference frame (jumps in both survey and twiss). In this way i

MAD-NG uses the attribute misalign=true for all commands, survey, track, twiss, cofind, etc.

Another point is for aperture. When an element with an offset has an aperture, is the aperture defined with respect to the "machine" reference frame or the "element" reference frame?

This was already presented, and it should follow the approach of MAD-NG if you want to avoid troubles when combining more and more features. See https://indico.cern.ch/event/779845/contributions/3245660/attachments/1779552/2895619/ld_1901-mad_tilt_slides.pdf

We should be able to support the case in which the aperture follows the element (use cases in LHC) and the case in which it does not (at least one use case in PS). This could be achieved for instance by assuming the conventions that the aperture follows the element, and aper_offset is extended to 6 values to be able to undo those of the element if required.

I don't understand...

I prefer individual keywords since very often only one component will be used and it avoids remember the meaning of each index. On the other hand. I see from the implementation point of view a clear advantage from using a vector in terms of code and memory.

And consistency. MAD-NG uses a set of attributes e.g. misalign={dx=0.1, dtheta=pi/12} such that redefinition of a misalignment needs to redefine them all but still use explicit names instead of indexes. For MAD-X this solution is not possible (array of attributes are not supported), so I would go for individual names attributes too.

I think it would be useful if one could access the node information using a similar syntax of the beam command, such as

mbx.4l5@lhcb1->x_offset
mbx.4l5@lhcb2->x_offset
mbx.4l5@lhcb1->at
mbx.4l5@lhcb2->at

This should solve the issues with the assignment to the element including the update to the element.

Good idea, but I would keep the convention already used by MAD-X, namely

mbx.4l5%lhcb1->x_offset
mbx.4l5%lhcb2->x_offset
mbx.4l5%lhcb1->at
mbx.4l5%lhcb2->at

There will be a difference between node information and element attributes, the former cannot store deferred expressions while the latter can...

Cheers, Laurent.

[rdemaria]

My understanding was that we needed a flag in SURVEY that if used includes the offsets. If I understand correctly you would also like an offsets_change_ref which then changes the reference frame in TWISS in the same way as done with translate and rotations? This is clearly possible but adds a bit of complication since this is not then just the same way as the errors works in TWISS and TRACK. One would have to record the position before the back transformation.. What is the use case for this?

I try to rephrase the point. We have three requirements (two of which are conflicting) :

1) SURVEY should allow to construct the P(s), ex(s) and ey(s) unit vectors and TWISS the x(s) and y(s) coordinates such that Q(s)= P(s)+ x(s) ex(s) + y(s) ey(s) is a physical trajectory in the laboratory frame. This is used every to plot a trajectory in 3D and, for instance, in LHC beam-beam codes to compute separations in D1. 2) SURVEY should provide the entrance and exit reference point of en element (request from survey team) 3) For misalignmed elements TWISS should not show discontinuities in the coordinates (request from Alex). This implies that if we keep 1) that P(s) should not have discontinuities and therefore cannot be used for 2)

Today TRANSLATION, ROTATION fulfill 1) and 2) while EALIGN fullfil 1) and 3). For this reason I think we need either: a) a flag in SURVEY and TWISS such that the offsets are treated differently for 2) or for 3) b) choose to drop 2) for survey and provide another command that computes the data specifically for the survey team (and we can drop the global tilt)

I would not drop 1) in any case.

[tpersson]

Thanks for the clarification. There is only one question from my part and it is basically why do we have to introduce the flag in both TWISS and SURVEY? Say that by default the misalignment is included and then as you said: 2 and 3 are fulfilled. We introduce a flag to exclude it from survey and now we should be able to add SURVEY with TWISS which then would fulfill 1.

[rdemaria]

I would introduce the flag for consistency and cross checks, but, I agree with you, it is not strictly needed for our use cases!