Dear all,
I was wondering if any of you have came across a package that could be use for making stereonets (stereographic projections on a Wulff/Schmidt nets), e.g.:
https://www.geological-digressions.com/tag/pi-diagram/
I’ve not found any examples of such diagram construction using Julia but I may have simply missed it…
Cheers and thanks!
I’m not aware of such specific Julia package, but GMT.jl would be the first place to look at, as it provides both Schmidt and Wulff projections.
If needed, the data processing could be done in Julia and the display could call a stereonet package in Python:
# In Windows Powershell do: pip install mplstereonet
using PyCall
using PyPlot
mplstereonet = pyimport("mplstereonet")
fig = plt.figure()
ax = fig.add_subplot(111, projection="stereonet")
strike, dip = 315, 30
ax.plane(strike, dip, "g-", linewidth=2)
ax.pole(strike, dip, "g^", markersize=18)
ax.rake(strike, dip, -25)
ax.grid()
plt.show()
1 Like
Thanks a lot, that looks nice.
I was looking for a pure Julia solution initially.
Besides notebook working fine. The combination Julia/Python has always been problematic for me (working on macs). And somehow GMT.jl also fails on my computer:
ERROR: LoadError: InitError: could not load library "/Users/imac/.julia/conda/3/lib/libgdal.29.dylib" dlopen(/Users/imac/.julia/conda/3/lib/libgdal.29.dylib, 1): Library not loaded: @rpath/libexpat.1.dylib Referenced from: /Users/imac/.julia/conda/3/lib/libgdal.29.dylib Reason: Incompatible library version: libgdal.29.dylib requires version 10.0.0 or later, but libexpat.1.6.12.dylib provides version 8.0.0
Take a look at this GMT on Mac post.
1 Like
That error means you are using the GMT bundle for Mac and unfortunately we don’t understand what Xcode does that sticks those @rpath/... in the library dependencies such that it only works for the bundle but render that installation useless when calling the libs from external programs like Julia does. Some two weeks ago a user had the same trouble and solved it by removing the bundle and installing GMT via homebrew. Not having any GMT installed should also trigger its installation via Conda, but like mentioned in the GMT.jl install instructions that implies an absurd amount of disk space (blame Conda).
Now, regarding the question, also here some shits is happening. This should work but apparently a bug is interfering (opened an GMT issue)
using GMT
plot([315,30], marker=:circ, mc=:green, ms=0.2, region=:global,
proj=(name=:Stereographic, center=(0,0)),
frame=(annot=:auto, grid=:auto), show=true, coast=true)
psxy [WARNING]: Latitude (315) at line # 1 exceeds -|+ 90! - set to NaN
Some good news. It turns out the bug lies somewhere in the data transference between Julia and the the GMT lib. Things work well if one saves the data to be plotted in a text file and plot it after.
This works. Note, I’m plotting the coastlines just confirm that the data plots where it should.
plot("point.txt", marker=:circ, mc=:green, ms=0.2, region=:global, proj=(name=:Stereographic, center=(0,0)), frame=(annot=:auto, grid=:auto), show=true, coast=true)
1 Like
Sorry, my bad. No bug at all. Only in my command, which used a vector (which meant two points without xx coordinates in this case) as input when it should have used a matrix.
This works as expected
plot([315 30], marker=:circ, mc=:green, ms=0.2, region=:global,
proj=(name=:Stereographic, center=(0,0)),
frame=(annot=:auto, grid=:auto), show=true, coast=true)
1 Like
if I may ask, how did you proceed for this cleaning step?
Let’s hope this will not be an issue on more recents macs…
But are you using the GMT bundle distributed by the GMT site? If yes then just remove the GMT installation from the Applications dir like you do with any other apps.
And no, unfortunately this does not depend on the Macs age, it’s an Apple long standing issue for which we never found a solution.
No I’ve installed GMT from macports. Now GMT.jl loads:
but the figure does not look as nice:
I’ll probably reinstall everything over again and get things running during the next weeks.
Yep, a MacPorts build should be OK too. But I’m pretty sure that the plot above was not produced by GMT. Better to post the plotting command.
Ah OK, I see (my) things are messy. I’ve used your plotting command , but since Plots.jl was already loaded, seems Plots.plot was used as default - that’s why it looked weird.
Now I’ve forced to use GMT.jl by replacing the plot command to GMT.plot and I’m now back to the original libgdal problem. I’ll try the homebrew version then. Thanks again for your hints 
On a second (and more attentive) read of the error message, yes that’s a problem with the macports build. It shows the *nix suffering of permanent dependencies breaking.
At least on clean starts the homebrew build works fine. I’, saying this because yesterday I added MacOS to the GMT.jl CI tests and it worked fine.