Current State of Live Plots in Atom/Juno?

New to Julia
1

What is the current status of live plotting/updating plots in Juno/Atom?

My ultimate hope is to have low latency 3-D scatter plots. So far I’ve tried every example I can involving tricks with GR, using gui(), etc. Then I tried Makie(can’t install correctly on my laptop due to HW so I’m stuck using CairoMakie backend). No luck, everything generates a new plot, or doesn’t display at all. The new plot for each animation step tanks my RAM insanely fast.

Would it be over-kill to send the data over ZMQ to a JAVA/JS plotting application or something? Is there something really easy I’m missing out on? I can offer a minimum working example, but honestly its just the following pseudo code:

a = scatter( data )
for i in 1:500
    update data
    update display
end
2

Not really “live”, but if an animation stored in a movie file is sufficient for your needs, GR is quite fast and cheap:

exampleanimation.jl:

x = randn(20)
y = randn(20)
z = randn(20)
GR.inline("mp4")
println(ENV["GKS_FILEPATH"])
for i = 1:500
    x .= randn(20)
    y .= randn(20)
    z .= randn(20)
    scatter3(x, y, z)
end
GR.inline("svg");

(After loading GR and making the first plot out of this file):

julia> @time include("exampleanimation.jl")
/tmp/juliayYRwSm.mp4
  9.097182 seconds (408.12 k allocations: 20.651 MiB, 0.07% gc time)
"svg"

The file name in tmp is where I can find the movie after the file is executed.

Run in Intel i3 @ 2.50GHz, 8GiB RAM, with Ubuntu 16.04.5-LTS

1 Like
3

Thanks for the reply!

Unfortunately I do need to see the plot live its the output of a simulation, and there’s a lot of wasted time creating then watching the entire run while debugging/fixing params.

That being said, is there a way to stream from a MP4/video file while it’s being written? or cast a video stream to icecast or something like that? That would work as well

4

I don’t have Julia on my current computer, so I cant test anything for you. However, I think that the GIFs in this blog should help you:

Basically, you have to replace update display in your psuedo code with display(scatter(data)). If latency is a problem and you are running out of RAM, then you could consider not displaying every step of your simulation while you are in the development phase. Flux has the throttle functionality, however, you should be able to get something fairly similar in your own code.

5

when you do this

data = randn(100)
a = scatter( data )
for i in 1:10
    #update data
    data = randn(100)
    display(scatter(data))
    #update display
    sleep(0.1)
end

in Juno it makes a new plot each iteration(that’s what kills my memory).

7

Okay I got the behaviour I wanted!

Had to use Interact.jl and Observables… Kind of lateral thinking, but it works really nicely!

using Interact, Plots
plt_obs = Observable{Any}(scatter(data))
data_obs = Observable{Any}(data)

map!(t -> scatter(t), plt_obs, data_obs)

ui = dom"div"( plt_obs )

for i in 1:10
    data_obs[] = randn(100)
    sleep(0.4)
end

I’d still like to see other solutions, so please fire away, or offer suggestions

1 Like
8

Plotly from Plots gives me an interactive 3d plot in atom

1 Like
9

Hah that’s actually what I was going to suggest. We run a lot of live simulations in the atom plot window.

You shouldn’t need Interact.jl, just Observables.jl and WebIO.jl.

The good thing is that should also work in jupyter, a web page or an electron window without changes (which is also what we do).

2 Likes
10

Using Observables + WebIO is the correct solution for this, yes.

that’s what kills my memory

Is it the Atom process taking up too much memory? I thought I had implement a limit on how many plots are kept in memory, but maybe I forgot about that.

1 Like
11

Its possible there is a plot number limit and the problem was just me polling new plots too quickly. Or maybe my settings were set to be too demanding - I’m not sure. The use case involves potentially 10’s of thousands of points being plotted and updated at about 1/100th the speed of real life. So it’s pretty demanding.

Sounds like I’ve stumbled on a good enough solution here I appreciate everyones input.

12

Turns out I did indeed forget to implement that. Fixed with
https://github.com/JunoLab/atom-ink/pull/238
though.

2 Likes
13

Thank you for posting this. This solution was useful to me so I generalised it into a package: SmoothLivePlot.jl. Hope it can be useful for other people too.

2 Likes