How to make a wind rose in Julia

Thanks for your responses! GMT looks like an interesting package with some useful features outside of the windroses. I was able to install the package (thank you for supporting Fedora), but am having a few issues. When I try to load the package using Juno, it hangs indefinitely for some reason. It precompiles in the Julia terminal, but whenever I try to plot I get

could not load library "libgmt"
libgmt.so: cannot open shared object file: No such file or directory

When I run the .sh scripts from the command line in the test suite, they throw the error:

psrose: Error: Unrecognized option -J

If I delete the J option things seem to work from the bash shell, so maybe that test code is just outdated?

So the install seems to work, but I can’t seem to get the Julia package running properly (let me know if I should open a new thread for that). It seems like a Fedora / path issue, but I am not sure where libgmt is, or how to tell the package where it is.

Thanks-

That’s a unix thing. When the GMT shared libraries are not stored in standard places one must help the OS. In linux it works setting the LD_LIBRARY_PATH to point to the shared lib dir. A more general solution is like explained in the readme page. Add this to startup.jl

using Libdl
push!(Libdl.DL_LOAD_PATH, "/path/to/gmt/lib")

I use it in Visual Studio Code (Windows) with no problems.

Ahh, I saw that, but though it might be mac specific. The only libgmt I can find is /lib64/libgmt.so.5, but when I added the above to startup.jl I get the same error. Seems like it is looking for libgmt.so and the 5 is throwing it off?

Whilst the GMT route is the best way to go long term, in dire straits you could use the polar histogram plotting function in an old repo of mine (see instructions in the readme file there).

julia> using CircPlot

julia> θ = 2π.*rand(10_000);

julia> cplot_histogram(θ, 2π/30)

will give you this:
basic_polar_hist
and you can tweak the appearance using the usual Plots keywords:

julia> cplot_histogram(θ, 2π/30, showaxis=false, grid=false, line=(:red,1), fill=(:blue, 0.5), circ=(lc=:black, fill=nothing))

giving
better_polar_hist

(Note that passing a named tuple, Dict, etc. to the circ keyword argument sets the plotting style of the outer circle.)

The docstring describes the usage:

help?> cplot_histogram
search: cplot_histogram

    cplot_histogram(a, binwidth, degrees=false; azimuth=false, axial=false, weights=ones(length(a)), circ=nothing; kwargs...) -> ::Plots.Plot

Plot a polar histogram of a set of angles `a` using bins `binwidth` wide.
`binwidth` should be given in the same convention (radians or °) as the data.
If π (or 180°) is not an integer multiple of `binwidth`, then the nearest value
for which this is true is selected.

Use `azimuth=true` to plot angles clockwise from north.

Use `axial=true` if data are π-ambiguous (i.e., are orientational rather than
directional data).

`weights` must have the same length as `a`, and if passed in will scale each
point `i` by `weights[i]`.

Set options for the surrounding circle using `circ=Dict(:opt=>val)`, where
the keys and values in the Dict will be passed to Plots for plotting the circle
shape around the plot.

Additional keyword arguments `kwargs...` are passed to `Plots.plot()` when
plotting the bars.

Ideally this should be implemented as a recipe, in StatsPlots or similar, but as yet there aren’t many directional distributions or measures implemented in Distributions nor tools for these in StatsBase. There is some very basic circular statistics stuff in CircStats.

Edit: I should say by way of explanation that you will want to use the weights keyword argument and set the binwidth to match the bar locations you need, with one point per bin and the bar length specified by the respective value in weights:

cplot_histogram(theta, step(theta), weights=r, azimuth=true, circ=(lw=1, fill=nothing), showaxis=false, grid=false)

windrose

1 Like

For the Travis CI (a Ubuntu machine) I just do

export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$HOME/gmt/lib"

(HOME/gmt/lib because it’s there that it gets installed).
Other people have reported this type of problem and the solution has always been either the LD_LIBRARY_PATH for Linux or the setup.jl for Mac & Linux
So, in your case perhaps

export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/lib64"

I have used the command line version of GMT quite a bit but I’m still a novice with the Julia interface. This should get you started.

using GMT

theta = range(0, stop = 1.5π, length = 100)
r = abs.(0.1 * randn(100) + sin.(3 * theta))
rose([r theta.*180/π], region=[0 1.4 0 360], A=270/99, frame="xg0.2",
    L="270,90,180,0", pen=(:thin, :blue), fill=:orange, fmt=:png, show=true)

2 Likes

Same error - for some reason the julia package can’t find it. I installed from the fedora repo, I’ll try the binary package and see if that makes a difference - will let you know…

Also thanks for the lead on this code. I might dig into it tomorrow if I can’t get GMT working…

If you run in command line gmt --show-bindir it will tell you where the gmt executable is located. You can then run `ldd`` on it ad see where the dependencies are. For example for my WSL version I get

ldd gmt
...
libgmt.so.6 => /home/j/programs/lib/libgmt.so.6
...

so.6 possibly because I’m building it from source (master).

Yeah, that gives me the same as before:

libgmt.so.5 => /lib64/libgmt.so.5 (0x00007fb76a52b000)

Let me reboot and maybe this will magically fix itself…

Does GMT run from the command line? A simple test is to type just
psxy
If it prints the online help it means it’s working fine. If not you may want to post for help in the GMT forum

That seems to be an issue. psxy doesn’t run, but gmt does. So maybe my install is flawed, even though I can sort of run some of the test scripts. I will have to work on this more tomorrow and report back. Thanks for all your help!

Sorry, my mistake. Now by default one have to run gmt module (e.g. gmt psxy) and if that runs it means there is no problem with your GMT installation. We can continue this tomorrow in GMT forum since t’s no longer a Julia question.

Can’t you just draw the bars basically by hand on the polar graph?

You have no idea how happy I would be to go back to the days of using a drafting table! But seriously, I am not really sure what you mean by “by hand”. I was planning to write some code bin everything, but my main concerns were that I can’t seem to reverse/rotate the axis, display labels properly, plot from an radius that is not zero, get the bars to fill. Its a task that definitely deserves “canned code”. I have been digging further, and it looks like the PGFPlots backend might actually work for this, I was just avoiding it because it is very slow and doesn’t work well with Juno in my experience.

1 Like

You can try quick and dirty by doing sudo ln -s /lib64/libgmt.so.5 /lib64/libgmt.so

This will not hurt anyone but keep in mind to update the link once you update GMT (so.6 etc.).

It would be nice if you can update GMT.jl and try again. I’ve came up with what I think is a general solution to those could not load library "libgmt" errors in all *nixes

Hey,

sorry for all the radio silence, I seem to have a cold or minor Covid-19. I did a fresh install on my home machine, which is running Fedora 31. It compiles without error, but I get this error when I try to do a basic plot from the docs:

ERROR: error compiling common_plot_xyz: error compiling gmt: could not load library "/usr/lib64/libgmt.so"
/usr/lib64/libgmt.so: cannot open shared object file: No such file or directory
Stacktrace:
 [1] #scatter#171 at /home/scone/.julia/packages/GMT/5hUOG/src/plot.jl:303 [inlined]
 [2] (::getfield(GMT, Symbol("#kw##scatter")))(::NamedTuple{(:limits, :xaxis, :yaxis, :proj, :zcolor, :size, :alpha, :title, :fmt, :show),Tuple{NTuple{4,Int64},NamedTuple{(:annot, :grid),Tuple{Int64,Int64}},NamedTuple{(:annot, :grid),Tuple{Int64,Int64}},Symbol,Array{Float64,1},Array{Float64,1},Int64,String,Symbol,Bool}}, ::typeof(scatter), ::Array{Float64,1}, ::Array{Float64,1}) at ./none:0
 [3] top-level scope at none:0

I also tried tamasgal’s suggestion and got the same error, so it looks like I was on the wrong track…

Very hard unixes. I start to think that you are having an issue of the same type as this but that is on a Mac with dmg install and MacOS manages to get into dependencies conflicts. I wonder if you are not also having a dependency conflict.

Yeah, I am at a loss. Let me know if there is anything else you would like me to test out. In the mean time I have a pile of other things to get through, so I am just going to put the wind roses off for a while…