Address a series of issues related to vectors#6161
Conversation
There have been several issues identified in GMT vectors lately (e.g., #6108) and we have had some partial fixes. This PR reconciles several problems and completes started enhancements: The new minimum vector shrink in +mnorm/limit was stated to be 0.25 but in fact was never set so it was still zero. This is now fixed. The check for geovector to skip heads if exceeding the vector length was flawed so some small vectors ended up with bad heads (e.g., #6108). Now the test is fixed and heads exceeding size is not plotted. Cartesian vectors never bothered to check and hence always plotted the heads even though exceeding vector length. This has now been addressed. FInally, there are uses of vectors where the vector length should not be considered when plotting heads. Many of these are internal (e.g., adding a vector head at the end of the line or at the end of a math x-axis), but placing flow vectors on a graph may also fall prey to the limitation. Using +n without any argument means always plot the head regardless of vector length. These corrections meant that 8-10 PostScript plots needed to be updated. For some I chose to use +n to avoid having to change the plot, while others would benefit from a refresh (e.g., properly giving scaling in km for geographic bectors in sample.sh). Closes #6158 and #6108.
|
The new met_uv test is failing on linux and windows due to rounding error when the vector length is close to the vector head size (see diff below). @PaulWessel, would you be able to modify the test to avoid this?
|
|
Interesting. The decision to draw head or not is just
so there is nothing I can do code-wise to beat any roundoff. As for the test, I guess we would have to hunt for a slightly different scale or initial head size that gives the same plot? Another take: I am about to improve the documentation on the geovector and Cartesian vector as the docs are not clear enough. Basically, the geovector means you specify a length in map units (km, for example) and then we plot that length on the map. This means the actual plot length on the paper depends on the map projection. A 50 km-long vector at Equator is half that of one at 60N. This is not what people who have vectors in other units (plate velocity, wind speed, etc) want, since it is biasing what the user sees. For those applications they need to plot Cartesian vectors, which do have the same length regardless of location and projection. To make matters worse, we have some tests that mixes these cases up, such as met_uv.sh which you can see is using geovector due to the -Si20k setting instead of, say, a -Si5c argument (random number, not sure what it needs to be to be visible). But for some perspective projections (-JG for instance), a geovector is suitable for those applications since the length is affected by the perspective. Documentation with figures on the grdvector page is needed for this. So I think I will fix met_uv.sh to use Cartesian vectors first, and then we can see if that causes different images for different OS. OK? |
|
I don't understand the roundoff story. There are rules for rounding and all compilers should produce the same result. Unless some are using fastmath compiler options. |
|
Hm, yes. Perhaps the cloud are doing things lie -O3 or -O? for some other setting that affects accuracy at the benefit of speed? Do we know the compilation flags for GMT as they are used in the cloud, @meghanrjones ? |
|
I got the failure locally on linux using the same compilation flags as on macOS. If it's worthwhile, I could run through the debugger to check exactly what is different between the two. |
|
If the examples can be reduced to a very simple case where the results are different in MacOS vs Others you can print the dr[0] & h_length_limit of the |
|
dr[1] and h_length_limit are the same on macOS and linux, but for this particular vector it is only drawn on macOS: |
|
Probably needs %.16lg to see the difference in values. |
|
Sorry, here is the comparison (I'll edit the post to add the linux case):
|
|
So, it's the last bit that differs. This case can be solved by setting |
|
Would be OK to use >= instead of > in general here, since that means the length equals or is larger than the limit. |
There have been several bugs and omissions identified in GMT vectors lately (e.g., #6108) and we have had some partial fixes. This PR reconciles several problems and completes incomplete enhancements:
These corrections meant that 8-10 PostScript plots needed to be updated. For some I chose to use +n to avoid having to change the plot, while others would benefit from a refresh (e.g., properly giving scaling in km for geographic vectors in sample.sh).
Closes #6158 and #6108; the latter is also the inspiration for new test met_uv.sh