Uh oh!
There was an error while loading. Please reload this page.
Let gmt.history and gmt.conf be hierarchical and separate for panels and figures - #3523
Conversation
We do not want an automatic region determined for one panel to apply to another panel.
Fix the inset stuff.
Still to do:
I suggest @joa-quim and @seisman try this branch, I have tested it on things like this and the levels work. If you run one command at the time and monitor what is happening in the .gmt/sessions/gmt_session.* directory you will see many gmt.conf and gmt.history files now come and go at the right times. The example below sets a figure-level title font (not used), then a subplot-level font (used for all panels), except overridden for one panel. One panel also overrides the interpolant to be cubic but it is back to being Akima at a later panel: #!/usr/bin/env bash |
joa-quim
commented
Jun 23, 2020
PaulWessel
commented
Jun 23, 2020
I can tell we have not converged on a modern font selection. And @KristofKoch has gone quiet and not here to defend it. I will see what I need to do to strengthen the implementation but it seems straightforward. Oh, I cut/paste the last plot call after subplot end! I will edit the script next. |
PaulWessel
commented
Jun 23, 2020
Script updated. I will work on documentation for all of this and the 11 failing tests due to "wrong" syntax. |
joa-quim
commented
Jun 23, 2020
PaulWessel
commented
Jun 23, 2020
Data stops at 40, no? |
joa-quim
commented
Jun 23, 2020
Yes, so it seems. Had not looked at it since first run. |
KristofKoch
commented
Jun 23, 2020
@joa-quim beauty is in the eye of the beholder. What makes you prefer the Times-Roman font? I wrote a lengthy comment over at 3344 why I prefer a sans-serif font and backed it with the NASA Technical Report "On the typography of flight-deck documentation"; especially chapter 3.2 "Typeface (Fonts)".
Source: chapter 3.2 "Typeface (Fonts)", NASA-CR-177605 As @PaulWessel was unhappy with Helvetica as the default GMT font (I still prefer it) the only other sans-serif option is the Avant Garde font family. This is if we stick to the default fonts. Maybe there is the possibility to include an open source font with GMT which appeals to all/most of us? Paul: I'm still alive - but the current COVID19 situation ties up almost all of my resources. |
We had several instances wehre we set -R in a panel expecting it to carry over to othre panels.
PaulWessel
commented
Jun 23, 2020
I am down to two failures: ex16 and ex18. What happens here is this sequence of events:
So, as usual, there are options to choose from to fix this:
This is not entirely black and white to me. In those examples, we do have plot region = data region so we would want a shared region. However, I can imagine entirely different cases where a surface call inadvertently picks up a -Rg plot region and spends forever. Here is an example from the (still pending) NASA proposal: We plan to let plotters be allowed to take input files like @earth_relief (i.e., no resolution specified) and we let GMT figure out what is the best given plot size. But we will not let producers have that capability. What the hell would grdfft @earth_relief be expected to do, for instance? So those modules need resolution. Same here I think: Leaving the data region undefined is not good, and all it takes is to specify it outside the subplot and now both plot and data regions will be set. Agree? |
joa-quim
commented
Jun 23, 2020
I'm lost. The (one) problem in line? What is the problem of it inherits the the -R from |
PaulWessel
commented
Jun 24, 2020
You are not lost - that is the line in ex18. The problem is one of coding - we currently do not allow a RP history to serve as RG history. However, one possibility is when a plot region is given via a data file (-R@AK_gulf_grav.nc, -Rmygrid.grd). Since those are data domains perhaps that is a reasonable rule to add? It means determining if the -R argument in RP history is a file and not w/e/s/n. |
joa-quim
commented
Jun 24, 2020
Well, @KristofKoch you are 100% right. It's in my eyes. I guess that I don't like |
Before I forget: We are please that @KristofKoch is still alive! And yes we understand very well what you are up against. |
joa-quim
commented
Jun 24, 2020
You mean |
Yes it would. Maybe this is such a frequently occurring situation that we should accept any -R given to subplot (and only subplot) to serve both as plot region and data region unless overridden below. I think this is the only situation where this could make sense. |
PaulWessel
commented
Jun 24, 2020
Thinking some more about this, I think letting subplot -R set both data region and plot region makes sense. If you have another data region in mind in that context you can specify that separately on the modules before or after subplot begin. What say you @seisman? I think that would add plenty of flexibility and avoid us changing those examples as well. |
PaulWessel
commented
Jun 24, 2020
Please comment on this @joa-quim before it is bedtime. |
joa-quim
commented
Jun 24, 2020
Yes, at this time I agree that subplot -R should set both data and plot regions ... but it has been a very intense pair of days so mind changes are allowable. |
PaulWessel
commented
Jun 24, 2020
So that handles ex18, but not ex16: In that example, we are sharing the -R (now) for gridders and plotters, but in the first panel we run |
PaulWessel
commented
Jun 24, 2020
Just moving the first surface call to before the first panel plot fixes the problem since now all grid settings (R, I, r) are shared at the subplot level. I think this is good. I will update subplot man page to explain how this works. |
Otherwise we are looking to find -R when not required or wanted.
New version is correct in that -Jx implies equal scaling so it should not scale x and y sepsrately.
I have completed this upgrade. After minor changes to some rouge scripts, all test pass as before minus the 2 known. Implementing the hierarchical scheme for history and conf was useful and found a few problems in the C code as well as bad scripting. Please check and approve, @joa-quim and @seisman . Closes #3520. |
seisman
commented
Jun 25, 2020
Just tried a little with this branch. I would say it works as I expect. Here are some comments:
|
PaulWessel
commented
Jun 26, 2020
Only common options are remembered, but we learned the hard way that for grids we kind of need not only region and registration, but also increment. Since -I was never a common option (think -I in grdimage), I made grid increments behave that way in the history. |
PaulWessel
commented
Jun 26, 2020
Uh oh!
There was an error while loading. Please reload this page.
Co-authored-by: Dongdong Tian <seisman.info@gmail.com>



We do not want an automatic region determined for one panel to apply to another panel.
This addresses #3520 but still needs some more work. It also extends this idea to gmt.conf which now is also hierarchical. Hence, current cpt, settings and history are now all hierachical. This leaves us with ~12 failures due to syntax that is now incorrect.