Extend FloorPlot

[giadarol]

Note that this PR can be merged only after xtrack v0.73.1 is released.

The following modifications and extensions are introduced:

• Plotting the XY projection is now supported.
• The FloorPlot is now generated from the survey table alone without requiring access to the line. This allows plotting the survey after the corresponding line has been modified or deleted. For this purpose additional columns (length, isthick and element_type have been added to the survey table in xtrack v0.73.1.
• The type of magnet is inferred from the element type and not from the strengths. This is to support the common use case in beam-line design, in which one defines a lattice geometry and wants to visualize the positions of the elements before defining the magnetic strengths. A side effect of this modification is that thin elements are all shown as multipoles and in the same color (we could think of doing something more sophisticated in the future, if required by users).

Examples including horizontal and vertical bends are available at https://github.com/xsuite/xplt/blob/extend_floorplot/examples/line_cases.ipynb

[eltos]

Aside from CI failures:

The type of magnet is inferred from the element type and not from the strengths. This is to support the common use case in beam-line design, in which one defines a lattice geometry and wants to visualize the positions of the elements before defining the magnetic strengths. A side effect of this modification is that thin elements are all shown as multipoles and in the same color (we could think of doing something more sophisticated in the future, if required by users).

This was already the idea, therefore it was using order from survey data (MAD-X had this), falling back to "nominal_order(element)" which would check for nominal strength even if not yet set, as opposed to "effective_order" which would check for actual strength values. Adding element type to survey is very good. However, since multipole handling is a major regression, let's keep the option to pass in the line object, and if done so, then use that extra information to colour the multipoles and other elements properly with the existing function. Let's not intentionally break what used to work before.

Examples including horizontal and vertical bends are available at https://github.com/xsuite/xplt/blob/extend_floorplot/examples/line_cases.ipynb

I think this can be reduced to one line with both, H and V bends, with two examples plots for two projections, and included in the main line.ipynb

[eltos]

@giadarol I noticed that some CI tests were never performed due to a mistake I made. I have fixed CI tests on dev branch with cde8527. If you could please rebase your PR onto current dev?

[giadarol]

@giadarol I noticed that some CI tests were never performed due to a mistake I made. I have fixed CI tests on dev branch with cde8527. If you could please rebase your PR onto current dev?

This is now done

[giadarol]

Aside from CI failures:

The type of magnet is inferred from the element type and not from the strengths. This is to support the common use case in beam-line design, in which one defines a lattice geometry and wants to visualize the positions of the elements before defining the magnetic strengths. A side effect of this modification is that thin elements are all shown as multipoles and in the same color (we could think of doing something more sophisticated in the future, if required by users).

This was already the idea, therefore it was using order from survey data (MAD-X had this), falling back to "nominal_order(element)" which would check for nominal strength even if not yet set, as opposed to "effective_order" which would check for actual strength values. Adding element type to survey is very good. However, since multipole handling is a major regression, let's keep the option to pass in the line object, and if done so, then use that extra information to colour the multipoles and other elements properly with the existing function. Let's not intentionally break what used to work before.

Examples including horizontal and vertical bends are available at https://github.com/xsuite/xplt/blob/extend_floorplot/examples/line_cases.ipynb

I think this can be reduced to one line with both, H and V bends, with two examples plots for two projections, and included in the main line.ipynb

The line can now be provided an optional argument, in which case knl is used to extract order for Multipole elements.
I didn't want to pollute the very clear line example with multipoles/vertical bends. The additional notebook is a bit more of a test than an example, aiming at covering the different scenarios for checks and debugging. Feel free to remove it or modify if you like.

[giadarol]

The Xtrack version with the additional columns in the survey is now released.
@eltos We can go ahead and merge this PR whenever you are ready

[eltos]

I'll review and merge asap

[giadarol]

I'll review and merge asap

No rush :-)

[eltos]

Had to do some changes to get tests running, and did some refactoring in the process for better performance and maintainability. Also included your v-bend example in the docs.

[eltos]

Will be available on PyPI as pre-release 0.11.3-rc6 soon. I have recently updated the CI workflows to allow for pre-releases. PyPI and the version picker on the sphinx docs page reflects this. This means we can publish new features more quickly, while keeping the release cycle of "stable" versions (with possibly breaking changes, and for which docs are kept long-term) to every couple months.

However, if you agree and tested it on your end, we could promote this RC version to stable 0.11.4, and continue development in the 0.12.* cycle @giadarol?

[giadarol]

@eltos, all good on my side. For me we can can go ahead.