I’m at a loss, please help! I expected the colorbar to be centered beneath the subplot, but for some reason it’s not ending up where I think it should. I have scripts that make a whole bunch of maps with 1x2 subplots, each subplot with a color bar centered below it. I changed something and now it’s not working. I’m sure it’s a small flag or offset that I can’t find (and of course I’m on a deadline…)
Here’s a stripped down sample with only one subplot (with both subplots, the colorbars are plotted on top of each other)
gmt begin test-cbar png A+m0.1c
gmt subplot begin 1x1 -Fs4i/0 -R-125.5/-110.5/37.0/49.5 -JM4i -Sr -BWeSn -Baf
gmt subplot set
gmt coast -Na/0.2p,dimgray -W0.2p,dimgray -Df -A10000
echo "Dummy subplot" | gmt text -F+cTL+f10p -Dj0.15c/0.2c -C0.1c -Gwhite
gmt colorbar -Cbam -DJBC+w90%/5%+e -Bxa0.1f0.05g0.1 -F+g255+c0 -Np
gmt subplot end
gmt end show
Thanks!!!
Unable to reproduce - works fine here. What GMT version and OS?
I was afraid of that.
gmt 6.3.0 on macOS (installed via conda).
I’ve also been getting gmt [WARNING]: GMT_COMPATIBILITY: Expects values from 6 to 6; reset to 6., so it seems to be grabbing a bad/old config file from somewhere, but I’m not sure where.
Seems fine with 6.3.0 here on my mac (via bundle). Look for old gmt.conf files lurking around.
Shouldn’t adding -C to the gmt begin command make sure that the session is started with no old gmt.conf files? I do this and still get the mis-placed colorbar and GMT_COMPATIBILITY warning. gmt defaults -D, which I expect to get the system defaults, has GMT_COMPATIBILITY = 6, so I’m not sure where this is coming from (and I’ve made sure ~/.gmt/gmt.conf and ./gmt.conf match the system defaults)
yes. Not sure of course. Things to check: More than one GMT installation and mixup in paths? printenv | grep GMT and look for odd environmental settings. Maybe someone else using GMT via conda can list other issues.
printenv | grep GMT returns nothing. gmt --show-sharedir points to ~/miniconda3/envs/gmt_py3/share/gmt in the conda environment . Last time I updated gmt, I deleted the entire environment and started from scratch with a saved environment file. Unfortunately, I don’t remember when those compatibility warnings started cropping up as I thought it was just because of an older config file hanging around in a different project.
I do have some older GMT installations, all in conda environments (so these should be isolated). This afternoon, I’ll probably delete all copies of gmt.conf that I can find on my machine, delete all conda environments containing GMT, and start over.
Apparent solution (may work without uninstalling/reinstalling all GMT installations):
gmt clear sessions
I eventually found and ran gmt clear sessions after noticing that there were a few dozen or so gmt_session.##### folders in ~/.gmt/sessions/. This removed all of these and the next time I tried running a script, it worked - no compatibility warnings and color bars as expected. I notice that gmt_session.##### folders don’t persist after my recent runs, maybe old ones were hanging around (and re-activated???) after I interrupted scripts with Ctrl+Z or Ctrl+.?
Before I found the solution above, I uninstalled all instances of GMT (all were in conda environments, so I deleted those environments) and deleted/renamed all gmt.conf files I could find on my machine. After a reboot, I recreated the conda environment with GMT (now v6.4.0). I reran an existing script that hasn’t been modified since it ran successfully (i.e. put the color bars in the right place), and got the same GMT_COMPATIBILITY warning and misplaced color bars.
@pwessel - lacking any gmt.conf files on my computer (as best I can tell), where does gmt defaults -Ds get the defaults? For me, this returns defaults with GMT_COMPATIBILITY=4 (from a clean v6.4.0 installation via conda: gmt, version = 6.4.0, build = h7f1b9d3_1, channel = conda-forge). This doesn’t seem to cause the compatibility warnings after clearing the sessions, so those warnings must have been coming from something in one of those.
From where the GMT documentation explains it does. From memory: current dir, user home dir, GMT default values. Now if Conda, and the crazy idea that every installation should go into its own environment (and makes a copy of everything like it does on Windows), is mixing this simple rule, that I don’t know.
I skipped a thought or two in my question, after deleting or renaming all gmt.conf files on my system (so nothing in current dir or home dir or ~/.gmt/, where are the system GMT default values stored? I seem to recall, from many machines/OSes/GMT versions ago, system default files (.gmtdefaults?) somewhere in the GMT installation directory, but I haven’t found the equivalent with recent versions (installed by conda).
The compatibility warning was, I think, a red herring, since even with the compatibility set to 4 after clearing the sessions, I’m no longer getting the compatibility warnings or misplaced color bars.
Peter, Joaquim - thanks for your help!
Yep, many moons ago the gmtdefauts used to be stored in an internal text file but now they are inbeded in the binary code.
1 Like
All good. If you want to get compatibility warnings so you can upgrade any affected options in your script then you just set the compatibility level to 6 and it will complain.
1 Like
