Bugfix/madx misalignments

[kparasch]

Description

Order of dx/dy and dpsi when importing from madx error tables was wrong.
Added test to check, and reversed the order.

Fixes xsuite Issue # 302 (xsuite/xsuite#302)

tests/test_prebuild_kernels.py does not pass, but was also not passing before.

Checklist

Mandatory:

• I have added tests to cover my changes
• [] All the tests are passing, including my new ones
• I described my changes in this PR description

Optional:

• The code I wrote follows good style practices (see PEP 8 and PEP 20).
• I have updated the docs in relation to my changes, if applicable
• I have tested also GPU contexts

[rdemaria]

Please make sure not to break the ealign logic.

[kparasch]

Doesn't work if thin multipole has angle...

[rdemaria]

Doesn't work if thin multipole has angle...

Multipoles with angle are a bit special and we were considering changing the behaviour (as it is not documented yet). Have a look here for more details:
MethodicalAcceleratorDesign/MAD-X#911

[kparasch]

Multipoles with angle are a bit special and we were considering changing the behaviour (as it is not documented yet). Have a look here for more details: MethodicalAcceleratorDesign/MAD-X#911

Until (and if) behaviour is changed, should we replicate the track of mad-x?

A particle entering a multipole (knl,ksl = 0, angle=a), and with an ealign diplacement dx, exits with a shift in the x coordinate equal to "dx * (a * sin(a) + cos(a) - 1 + O(1.e-5))". Since there can't be a change in the actual position of the particle, this change must be happening in the reference orbit.

[rdemaria]

The matter is a bit tricky. Thin elements do not exist, (si)xtrack elements are indeed integration steps. I am not sure it makes sense to rotate an integration step in the general case, but it can work in specific cases.

[giadarol]

@rdemaria and @paraschou
What is the state of this PR? Is it ready to be merged?

[giadarol]

Closed by mistake