Eigenmode viewer hooks

[Lazersmoke]

This includes all helper functions and hooks needed to make the eigenmode viewer work.

[Lazersmoke]

(since this is getting merged first, we'll see how the diff between main and asymmetric looks afterwards and proceed from there)

(also note this includes plot_band_intensities which is used in un-exported form by the eigenmode viewer)

[kbarros]

I pushed some updates:

• Now colors can also be animated using colorfn argument.
• The dipoles to be animated can no longer be detached from sys.dipoles. To support that use case, use clone_system. The memory costs will probably be much less than all the GLMakie objects anyway.
• The result of plot_spins is an object that supports both display and notify. This way users don't see observables.

Why not expose Makie Observables? Ultimately, that interface is not a nice abstraction for complicated objects with interior mutability. Later, for example, notify(fig) might animate other things besides the dipoles and colors, and users will get it automatically. I tried to make color an Observable following Makie conventions, but the code ended up being much less clean (both on the Sunny side, and the user interface side). I think the final result here is very nice to use. See, e.g., the new Heisenberg animation example: https://github.com/Lazersmoke/Sunny.jl/blob/eigenmode-viewer-hooks/examples/extra/heisenberg_animation.jl

[Lazersmoke]

This will be very slow because it empties the whole array of points and dipole vectors and then rebuilds it on every single frame. The point of having spin_data be separate is that it is fast to redraw (and modular to notify, unlike NotifiableFigure).

If this is the way that you want this in main Sunny, that's fine, and I'll write my own viewer function in SunnyContributed :)

[kbarros]

To the contrary, this is designed for maximal speed. Ping me on slack and we can work out how your use case will fit.

…

On Thu, Oct 26, 2023, 11:10 Sam Quinn ***@***.***> wrote: This will be very slow because it empties the whole array of points and dipole vectors and then rebuilds it on every single frame. The point of having spin_data be separate is that it is fast to redraw (and modular to notify, unlike NotifiableFigure). If this is the way that you want this in main Sunny, that's fine, and I'll write my own viewer function in SunnyContributed :) — Reply to this email directly, view it on GitHub <#180 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACG3HM7RZH526VMFRPUKT3YBKKO5AVCNFSM6AAAAAA6OIIBFSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBRGUYTMNBZGQ> . You are receiving this because you commented.Message ID: <SunnySuite/Sunny .***@***.***>

[kbarros]

Following discussion on Slack and various benchmarks, it appears that this implementation is getting about maximal speed. In particular, Makie is intelligent in ignoring extra notifications if the data hasn't changed. That is, these extra notifications don't matter.

notify.((vecs, pts, pts_shifted, arrowcolor))

For a system with 10k spins, I get these results for one notify

[COLORS ON]  0.012429 seconds (141.15 k allocations: 6.590 MiB)
[COLORS OFF] 0.009867 seconds (81.16 k allocations: 4.759 MiB)

This is much slower than I like, but I think the slowdown is fundamentally on the Makie side. Note the speedup we get if the arrowcolor data is unchanged, even though we spuriously notify(arrowcolor).

Another important thing to know is that this pattern is non-allocating:

function f(a)
    l = length(a)
    empty!(a)
    for i in 1:l
        push!(a, 42)
    end
end

r = randn(10)

using BenchmarkTools
@btime f(r)

In particular, empty! will not actually free the underlying data -- it will be saved for future use. To actually free, you would need something like size_hint!.