I have a series of plots, each associated with a different value of a parameter called
k. The idea was to plot each line with a different color from a colormap and have the colorbar indicate which value of
k each plot is associated with, rather than using a legend. The plots are created by a loop, creating one plot per iteration.
I’m quite happy I found the parameter line_z, which automatically creates a colorbar and assigns the right color to the plot, rather than having to create both of them seperately, as suggested in some places on the internet.
However, the parameter
k is exponentially spaced (from 5 to 500, so 50 is the midpoint) so I need logarithmic scaling.
colorbar_scale=:log10 seems to do that for the colorbar just fine, but the plots don’t follow, so the colors don’t match. I suppose one option would be to take the log of
k instead and change the tick labels, but I haven’t figured out how to change tick labels and that also seems like an ugly workaround for something that should work out of the box. Setting
zscale=:log10 just prints a warning
No strict ticks found.
I’m using this before the loop:
plot(xlabel="\$L_v\$ (pu)", ylabel="frequency (Hz)", colorbar_title="k")
This at the end of the loop
plot!(x, y, seriescolor=:roma, line_z = k, label="", colorbar_scale=:log10)
and somehow I still need to run
plot!() after the loop for the plot to actually show up, I’m not quite sure why.
This is without the parameter
colorbar_scale, plot colors and colorbar locations match, but you can’t tell the first 2 plots apart, because they have almost the same color:
This is with the parameter
colorbar_scale, the colorbar looks fine, but the plots don’t look any different and thus no longer match the values indicated by the colorbar
Taking the log10 of
k gives me correct plot colors, but the colorbar scale if obviously wrong:
I was thinking I could use the latter and modify the tick labels, but I haven’t figured out how to do that and I also think that I should not need to do this - the correct color scaling should work out of the box.
My problem seems very similar to what is discussed in this issue, but it says the issue is solved and I don’t really know how to transfer the workarounds to my problem without major changes to the plotting code.