Asynchronous Makie


I wrote a toy CFD solver computing pressure and velocity fields for successive timesteps and I use Makie for plotting the result and store a movie.

Although I only plot new frames every 200 timesteps, the plotting time becomes dominant (e.g. contour with 100 levels or streamplots).

I wonder if there is a simple way (or even better an example) to execute Makie computations on another cpu core ?

I’d guess that you could use Distributed and a RemoteChannel. Have the worker generate the data and pass it to the controller over the RemoteChannel. Then your code that feeds Makie would read the data from the RemoteChannel and pass it to Makie.

Things should run faster however if you generate data faster than Makie can process it (Makie is using more that 50% of the time in your current setup) then your generate process will end up idling waiting for Makie to catch up. However with this setup the total time should be controlled by how long it takes Mackie to process the data.

Thanx, I wonder if 1.3 threads could make this simpler…

streamplot & contourplot are probably some of the slowest Makie plot types, since they do most of the work on the CPU…So using other plot types could be an order of magnitude faster - if you share your code, we could take a look at it…
Threads won’t help yet, since makie currently isn’t thread safe. You could also consider starting makie in a different process and then sent the data to that process!

Hi Simon.
First a big thank for your wonderful job on Makie !

I did notice that contour was slower than other kind of plots. I also have the feeling that when I use a user defined level arrays like
contour(..., levels=[l1,l2,..,li])
contour gets even slower.

I did not study the contour algorithm so I don’t know if it could be easily adapted for GPU (it would be great).

My toy CFD is a bit too large (and messy) to be shared by now but I shall find some time to send a MWE.
In particular I wonder if my use of observable and animation is optimal.

I have a loop like

q=myMakiePlot(....) # where q is an array observable
record(scene,"test.mp4",framerate=10) do io
    for i=1:ntimesteps
       # compute a new array Q
      if mod(i,100)==0
function myMakiePlot(...)
     contour!(scene,x,y,lift(a->a,qn),linewidth=2,levels=100,fillrange=false,limits=limits,axis = (showticks = false, showaxis = false,))

You could try:

contour(rand(4, 4), fillrange = true)

Which should execute on the gpu, but will look different and maybe a bit more ugly :wink:

1 Like

Thanks, I will try that.

@LaurentPlagne Very interested to find out more about your CFD solver. I worked for an F1 team and we used a commercial package - no not the obvious one.
I am asking though - you are doing the plots after every timestep? As you know better than me the usual workflow is to run the solver, then run a post processing step to produce the pressure plots, contours, and the movies etc.
Using Julia from start to finish with Makie does give you the facility to do it in real time I suppose. Wow.

1 Like

Hi John,

This CFD “solver” is only a toy solver that we intend to use as a basis for a Julia lecture (just like I did with my toy 2D Shape collisionner Plot a circle with a given radius with Plots.jl

I have translated the famous mit18086 from Matlab to Julia and replaced the cholmod solver by an home made geometric multigrid solver (that must be able to solve full neumann B.C.) translated from C++ to Jula.

The resulting Julia code is reasonably fast (5-100 times faster than the matlab original code depending on the mesh size)

For your question, I dot not use the classical post-processing workflow and the Makie plots are computed and displayed during the simulation (and the movie being recorded live) but I do not emit a frame by timestep: there is about 20k \Delta t and around 200 frames :wink:

I agree that visualization during simulation is rather convenient and do this only with Julia is very nice !

Wow, the speedup with fillrange=true is impressive (x10) !
Thank you again


P.S. I would not say that the GPU contour is ugly… maybe stylish :wink:
Contour GPU
Contour on cpu
… the youtube compression is ugly :sleepy:

1 Like

Yeah this is a case where the contour algorithm on the GPU works out really nicely :slight_smile:
There are some others where it looks pretty odd compared to what people expect.

What does fillrange do? Could you add a blurb to the Contour docstring about it if possible?