Closed Lazersmoke closed 11 months ago
(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)
I pushed some updates:
colorfn
argument.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.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
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 :)
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 https://github.com/SunnySuite/Sunny.jl/pull/180#issuecomment-1781516494, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACG3HM7RZH526VMFRPUKT3YBKKO5AVCNFSM6AAAAAA6OIIBFSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBRGUYTMNBZGQ . You are receiving this because you commented.Message ID: <SunnySuite/Sunny .@.***>
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!
.
This includes all helper functions and hooks needed to make the eigenmode viewer work.