Bug: Terminator lines appear on top of each other on 2026-03-20

[mikez]

Description of the problem

Terminator lines appear on top of each other on 2026-03-20.

Full script that generated the error

gmt begin terminator_test png
  gmt coast -Rd -JW15c -Bafg -Gdarkgreen -Slightblue
  gmt solar -Td+d2026-03-20T01:04:00 -Gnavy@85 -W0.5p -Rd -JW15c
  gmt solar -Tc+d2026-03-20T01:04:00 -Gnavy@85 -W0.5p -Rd -JW15c
  gmt solar -Tn+d2026-03-20T01:04:00 -Gnavy@85 -W0.5p -Rd -JW15c
  gmt solar -Ta+d2026-03-20T01:04:00 -Gnavy@85 -W0.5p -Rd -JW15c
gmt end show

Actual outcome

Expected outcome

Terminator lines are spread out, like here:

System information

• Operating system: macOS
• GMT version (gmt --version): 6.6.0

[github-actions]

👋 Thanks for opening your first issue here! Please make sure you filled out the template with as much detail as possible. We appreciate that you took the time to contribute!

Please make sure you read our Contributing Guide and abide by our Code of Conduct.

[Esteban82]

I can confirm the bug with GMT 6.7.

[Esteban82]

This is Claude's analysis and suggestion:

Root cause

The bug is triggered by an exact floating-point zero in the solar declination (SolarDec = 0.0) that occurs on both equinoxes, and manifests inside the polar-cap polygon closure logic — not in the radius assignment or the small circle computation.

Step 1 — pssolar_params() returns SolarDec = 0.0 exactly

The declination is computed as:
cSun->SolarDec = asin(sin(obliqCorr * D2R) * sin(lambda * D2R)) / D2R;
On the vernal equinox, the Sun's apparent longitude lambda evaluates to exactly 0.0 in floating-point. sin(0.0) == 0.0, so SolarDec is identically 0.0. The sub-solar point lands exactly on the equator.

Step 2 — four distinct radii are passed correctly to gmt_get_smallcircle()

The main loop does nothing wrong:

cfor (n = 0; n < 4; n++) {
    Ctrl->T.which = n;
    pssolar_params(Ctrl, Sun);   // Sun->radius = 90.833, 96, 102, or 108
    S = gmt_get_smallcircle(GMT, -Sun->HourAngle, Sun->SolarDec, Sun->radius, n_pts);
    gmt_geo_polygons(GMT, S);
}

The four radii (90.833°, 96°, 102°, 108°) reach gmt_get_smallcircle() correctly. The four returned segments are geometrically distinct.

Step 3 — gmt_geo_polarcap_segment() collapses all four polygons

This is where the bug is. When SolarDec = 0.0, every small circle has its pole on the equator. A small circle with a radius close to 90° centered on the equator is nearly a great circle — one that passes through both poles. The gmt_geo_polygons() call detects this and invokes the polar-cap closure to stitch the open arc into a closed polygon.
With the pole sitting exactly on the equator, the stitching path generated by gmt_geo_polarcap_segment() is identical for all four terminators regardless of their different radii. The four geometrically distinct arcs are closed into four identical polygons, and all four render on top of each other.
The same collapse happens via the clip path (-Gc) branch:

if ((n_pts = (int)gmt_geo_polarcap_segment(GMT, S, &lon, &lat)) == 0) {
    lon = S->data[GMT_X]; lat = S->data[GMT_Y];
    ...
}
PSL_beginclipping(PSL, lon, lat, n_pts, GMT->session.no_rgb, 2 + first);

Proposed fix

Add an epsilon guard in pssolar_params(), immediately after the declination is computed:

Sun->SolarDec = asin(sin(obliqCorr * D2R) * sin(lambda * D2R)) / D2R;

/* Avoid exact zero declination (equinox singularity).
 * SolarDec == 0.0 places the sub-solar pole on the equator, which
 * causes gmt_geo_polarcap_segment to produce identical closed polygons
 * for all four terminator types.
 * A nudge of 1e-10 degrees (~0.36 microarcseconds) is imperceptible
 * at any map scale. */
if (Sun->SolarDec == 0.0) Sun->SolarDec = 1e-10;

This also affects the September equinox (~September 22), which should reproduce the bug identically.

[Esteban82]

I tried Claude's suggestion but it didn't work.

[Esteban82]

I think that I find a solution with Claude's help. I will make a PR.

[Esteban82]

BTW, this is the image I got. @mikez does it looks fine?

Full script:

date=2026-03-20T12:00:00

gmt begin terminator_test png
  gmt coast -Rd -JW15c -B0 -Gdarkgreen -Slightblue
  gmt solar -Td+d$date -Gnavy@85 -W0.5p -Vd
  gmt solar -Tc+d$date -Gnavy@85 -W0.5p -Vd
  gmt solar -Tn+d$date -Gnavy@85 -W0.5p -Vd
  gmt solar -Ta+d$date -Gnavy@85 -W0.5p -Vd
gmt end

[mikez]

@Esteban82 I checked on timeanddate.com to compare to your time; and it looks the same to me. It seems like you found a fix! :)

[mikez]

@Esteban82 Also, apologies, I realized I put T12:00 in my code, but actually ran against T01:04 (I fixed this now).

[Esteban82]

This fix was committed directly to main by mistake.
@GenericMappingTools/core, @joa-quim what should I do? Should I revert it and make a PR? or leave it?

You can see the commit here:
e7adb9e

[joa-quim]

I think in this case it would be better to revert and submit a PR. This in sake of leaving a easier trace in documenting this issue.

[seisman]

This fix was committed directly to main by mistake.

https://github.com/GenericMappingTools/gmt/settings/branch_protection_rules/2145041

I'm not sure if you can see this, but as far as I understand, only @joa-quim and I are allowed to push directly to the master branch. Not sure what was happening.