xsuite / xplt

Plotting library for Xsuite and other accelerator physics codes
https://xsuite.github.io/xplt/
Apache License 2.0
10 stars 4 forks source link

editing FloorPlot boxes #17

Open cchall opened 1 week ago

cchall commented 1 week ago

I'm trying to use the FloorPlot function on a simple beamline imported in from MAD-X. Plotting with mostly default options seems to work well:

xplt.FloorPlot(
    sv, line, 
    figsize=(18, 7),
    labels=table_multipoles.name
)

image

However, when I go to edit the color of my kickers (imported as multipoles) something strange seems to happen. I'm guessing this is connected with ".*: "True" to get the other elements to plot in their default configuration?

    xplt.FloorPlot(
        sv, line, 
        figsize=(18, 7),
        boxes={
            "vs.": dict(color="green"),
            "s.": dict(color="green"),
            ".*": True
        },
        labels=table_multipoles.name
    )

image

eltos commented 1 week ago

Yes, since .* matches everything, you overwrite the default behaviour and ask it to show all elements explicitly.

What elements are the ones you don't want to show up? Can you provide the MADX file and minimal code to reproduce?

If it's drift spaces then it's a bug because these should never be rendered. In this case we need a reproducible example to debug.

If it's some other elements then it's intended behaviour. In this case you can either change the regex to match only the elements you actually want to see, or use the ignore parameter to exclude certain elements again. But we could think about having a default_boxes=True/False parameter to keep the default boxes in addition to custom ones for convenience (instead of forcing the user to manually replicate the default by providing an appropriate regex).

eltos commented 1 week ago

But in any case please provide a reproducible minimal example.

cchall commented 1 week ago

It looks like this was caused by the drift spaces being rendered from including .*. I'm not sure from your statement if this is actually a bug or is expected when you ask for every element to be shown. In either case the addition of default_boxes seems to make it much easier to create the figure I intended. Thanks for your help!

As a side issue it looks like the coloring for Bend elements may have been broken in the recent commits. They now appear to default to the same color as Quads.

import xtrack as xt
import xpart as xp
import xplt
xplt.apply_style()

ele_line = {
    'drift_0': xt.Drift(length=0.5),
    'qf_0': xt.Quadrupole(length=0.25, k1=1.0),
    'drift_1': xt.Drift(length=0.5),
    'qd_0': xt.Quadrupole(length=0.25, k1=-1.0),

    'drift_2': xt.Drift(length=0.5),
    'bend_0': xt.Bend(length=0.175, h=0.686, edge_entry_angle=0, edge_exit_angle=0.06),
    'drift_3': xt.Drift(length=0.5),
    'bend_1': xt.Bend(length=0.175, h=-0.686, edge_entry_angle=-0.06, edge_exit_angle=0.0),
}

beam_line = xt.Line(
    elements=[ele for ele in ele_line.values()],
    element_names=[name for name in ele_line.keys()]
              )

beam_line.particle_ref = xp.Particles()
beam_line.build_tracker()
table = beam_line.get_table()
plot = xplt.FloorPlot(line=beam_line, labels=table.rows[table.element_type == 'Bend'].name)
plot.legend()

image

plot = xplt.FloorPlot(line=beam_line, boxes={'.*': True})
plot.legend()

image

eltos commented 1 week ago

Thanks for the MRE @cchall. Yes, drift spaces showing up as bends was a bug, should be fixed now (backport to v0.10, will release if you confirm). The other elements showing up were intended, but I understand that it's inconvenient, so this behaviour will change in the next regular version v0.11 (the old behaviour can then be restored with default_boxes=False and explicit boxes={..., ".*": True}).

However, with the recent commits on fix-0.10 (437a57a88a15e55a886b81524bda032bee2f1cfa) and also on main (d655ea31fd168f9a217bbcb7809bfe535ee2e6a5) and the package versions as in tests-requirements-py3.12.txt, I cannot reproduce it any more. For the code you posted above, I get this output instead, which I think is what one would expect.

Can you confirm?

Unbenannt Unbenannt-1