improve legend for bifurcation diagrams using Makie

[rveltz]

Hi,

The following situation is not very nice. Can it be improved?

using Revise, GLMakie
using BifurcationKit
const BK = BifurcationKit

# vector field of the problem
function COm(u, p)
	(;q1,q2,q3,q4,q5,q6,k) = p
	x, y, s = u
	z = 1-x-y-s

	[
		2q1 * z^2 - 2q5 * x^2 - q3 * x * y,
		q2 * z - q6 * y - q3 * x * y,
		q4 * z - k * q4 * s
	]
end

recordCO(x, p; k...) = (x = x[1], y = x[2], s = x[3])

prob = BifurcationProblem(COm, [0.07, 0.2, 05], (q1 = 2.5, q2 = 0.6, q3 = 10., q4 = 0.0675, q5 = 1., q6 = 0.1, k = 0.4), (@optic _.q2); record_from_solution = recordCO)

opts_br = ContinuationPar(p_max = 1.9, dsmax = 0.01)
br = continuation(prob, PALC(), opts_br; normC = norminf)

sn_codim2 = continuation(br, 2, (@optic _.k), ContinuationPar(opts_br, p_max = 2.2, ds = -0.001, dsmax = 0.05);
normC = norminf, bothside = true, detect_codim2_bifurcation = 2,)

hp_codim2 = continuation(br, 1, (@optic _.k), ContinuationPar(opts_br, p_max = 2.8, ds = -0.001, dsmax = 0.025) ;
normC = norminf, detect_codim2_bifurcation = 2,bothside = true,)

BK.plot(sn_codim2, hp_codim2)

Idem for this

BK.plot(sn_codim2, hp_codim2, vars = (:q2, :x))

[rveltz]

@BambOoxX do you know how to improve this?

[BambOoxX]

Could you be more specific ? Is it about the legend ? The improper overlap ?

[rveltz]

Exactly, it would be nice to combine the legends. And tackle the overlap.For example if you do plot(br, br) they will be duplicates

[BambOoxX]

Regarding the legend, I would say it is more like defining the proper legendelements extension.
For the overlap, there is a chance that this is due to improper indexing into the results array or something close.
I might have time later in the week to have a look.

[rveltz]

Hi,

Did you have time to look into this?

[BambOoxX]

Hi, unfortunately no, I got busy with something else, but definitely next week, I have some free time to look at it.

[BambOoxX]

So I analysed a bit the different problems :

1. I am actually not sure if there is a problem with the branches and points. Could you test again with the latest Makie ?
2. The legend problem, from my perspective, comes from the fact that
   • you create one Legend per branch (what axislegend does in the background is not much more than that)
   • I think it is generally a bad idea to "enforce" (for the lack of a better word) legends as it gives little flexibility to the user.

Now to improve legends. I think one of the immediate difficulties comes from the fact that you did not define a custom recipe for e.g. a BranchPlot which would be built on Makie primitives. This would allow to implement the proper legendelements .
Typically, one could build the list of legend items on the fly and make it available if the user wants to have a legend, as described in Makie's documentation here : https://docs.makie.org/dev/reference/blocks/legend#Creating-Legend-Entries-Manually.
Also I think one could define the entries using groups such that there is something like

**Branch 1**  
---- branch
* bt
* ...
**Branch 2**  
---- branch
* gh
...

Note that all of the above completely disregards compatibility with what the Plots equivalent does, so I may have completely missed a constraint coming from that side.

[rveltz]

1. it seems you are right. Now the legend duplicates are correctly removed.
2. Yes you are right. Additionally, in the Plots backend, you can scatter(br) which would be nice to have in Makie.

I don't have constraint from the Plots backend, I just want them to perform the best they can. My experience is that the Makie backend seems slower than the Plots one. I think observables should be used for updating the plot during continuation

[BambOoxX]

OK. I we disregard any equivalence between the Makie and Plots backend, I can try and refactor the code to be more Makie-ish, so that legend construction works better.

If you have an example where you find that the plot update is a bit slow, I can try and improve that. My own experience with observables is that they require some thinking to be optimal, but that they can be very fast nonetheless/

It is also totally feasible to define a branchplot / branchplot! recipe that could be called by the current plot / plot!, and also to define a scatter method for branch objects.

Let me know what you think is best.

[rveltz]

If you have an example where you find that the plot update is a bit slow

Not really. It is only when I compare to the Plots backend

I think what you suggest concerning the plot recipe is really nice. We can look at the observable later. The goal is to have the user a plot that can be published

[BambOoxX]

Ok, so I will focus on building a recipe that replicates what is already done.
The only constraint is that empty function branchplot end; fuction branchplot! end signatures must be defined in the package itself so that once Makie is loaded, the extension loading is triggered, and the extension adds methods to the function. Except for that, everything should be implemented inside the extension itself.
With a bit of luck, this will also lead to performance improvements.
If you have an example of plot update available, I would still like to see how things are between Makie and Plots, just out of curiosity.

[rveltz]

great, thanks a lot.

[BambOoxX]

@rveltz Sorry for the delay, I have very little spare time right now, I'll post a PR as soon as I can.

[rveltz]

no worries.

[rveltz]

it seems to work ok for Cairo but if you can improve the API, please do!