Event time sequence ERROR on year 2029 - Finishes almanac, but 2 errors underway

[nkh-dk]

Hi,
Thanks for the good work - Installed via PyPi and everything works, except NA for 2029, I get two errors "Event time sequence ERROR...":
Tried 2 diff. installations, Intel CPU (i7-9700K & i5-8365U). Same result. Single year, multi year, same.
Looked in source, not getting wiser - Google didn't provide much help either.
NA Y2026 - Y2036 compiles without trouble, except for 2029.

~$ python -m skyalmanac
Path to config.py: /home/xxxxx/.local/lib/python3.13/site-packages/skyalmanac/lib/
Downloaded data in: /home/xxxxx/.local/lib/python3.13/site-packages/skyalmanac/astro-data/

What do you want to create?:

1   Nautical Almanac      (for a day/month/year)
2   Sun tables only       (for a day/month/year)
3   Event Time tables     (for a day/month/year)
4   Lunar Distance tables (for a day/month/year)
5   Lunar Distance charts (for a day/month)
6   "Increments and Corrections" tables (static data)

1
Enter as numeric digits (or 'x' for a brief sample):

- starting date as 'DDMMYYYY'
- or just 'YYYY' (for a whole year)
- or 'YYYY-YYYY' (for first and last year)
- or just 'MM' (01 - 12) for the current or a future month
- or '-MM' for a previous month (e.g. '-02' is last February)
- or 'x' for 6 days from today
- nothing for the current day

2029
What table style is required?:

t   Traditional
m   Modern

t
Take a break - this computer needs some time for cosmic meditation.

NOTE: only 8 logical processors are available for parallel processessing

Creating the nautical almanac for the year 2029

Jan ..........
Feb ........
Mar .........
Apr .....Event time sequence ERROR on 17-04-2029 in mp_nautical.fmt_rise_set
....
May ..........
Jun .........
Jul .........
Aug .........
Sep Event time sequence ERROR on 02-09-2029 in mp_nautical.fmt_rise_set
.........
Oct ..........
Nov .........
Dec .........

execution time = 419.64 seconds
stopwatch = 2378.72 seconds
(stopwatch = time spent getting moonrise and/or moonset times)
Moonrise/moonset time seeks = 10920
Above/below horizon searches = 1536

This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023) (preloaded format=pdflatex)
restricted \write18 enabled.
entering extended mode
finished creating 'NAtrad(A4)_2029.pdf'

[aendie]

Greetings! I am able to reproduce this (almost the same) error on a Windows 11 system using Skyfield 1.54:

(venv) D:\_DEVvenv>py -m skyalmanac
 Path to config.py:  D:\_DEVvenv\venv\Lib\site-packages\skyalmanac\lib\
 Downloaded data in: D:\_DEVvenv\venv\Lib\site-packages\skyalmanac\astro-data\

  What do you want to create?:

    1   Nautical Almanac      (for a day/month/year)
    2   Sun tables only       (for a day/month/year)
    3   Event Time tables     (for a day/month/year)
    4   Lunar Distance tables (for a day/month/year)
    5   Lunar Distance charts (for a day/month)
    6   "Increments and Corrections" tables (static data)
1
  Enter as numeric digits (or 'x' for a brief sample):

    - starting date as 'DDMMYYYY'
    - or just 'YYYY' (for a whole year)
    - or 'YYYY-YYYY' (for first and last year)
    - or just 'MM' (01 - 12) for the current or a future month
    - or '-MM' for a previous month (e.g. '-02' is last February)
    - or 'x' for 6 days from today
    - nothing for the current day
2029
  What table style is required?:

    t   Traditional
    m   Modern
t
Downloading EOP data from USNO...done.
Take a break - this computer needs some time for cosmic meditation.

Creating the nautical almanac for the year 2029

Jan ..........
Feb ........
Mar .........
Apr .........
May ..........
Jun .........
Jul .........
Aug .........
Sep Event time sequence ERROR on 02-09-2029 in mp_nautical.fmt_rise_set
.........
Oct ..........
Nov .........
Dec .........

execution time = 76.31 seconds
stopwatch      = 329.20 seconds
(stopwatch = time spent getting moonrise and/or moonset times)
Moonrise/moonset time seeks  = 10920
Above/below horizon searches = 1536

This is pdfTeX, Version 3.141592653-2.6-1.40.27 (MiKTeX 25.4) (preloaded format=pdflatex.fmt)
 restricted \write18 enabled.
entering extended mode
finished creating 'NAtrad(A4)_2029.pdf'

And I place my bets that this is a side-effect of a problem I recently identified with Skyfield 1.54: Issue #1114 If so, then please note also that I get different error failure points on a Linux system (I can't explain why).

This error is not reproducible using Skyfield 1.49 (my old "favorite") although I think this problem is only harder to find in older versions of Skyfield. It would be good if you could confirm that any earlier version of Skyfield works for you. If so, please track the progress on Issue #1114

Minor point - you posted this error under Pyalmanac instead of Skyalmanac ..... but I caught it anyway :-)

[nkh-dk]

Hi aendie,

Thank you for answering and sorry for the misplacement - Can I somehow move it to the correct place?

I'll test with Skyfield 1.49 right away...

[aendie]

You can keep it here ... that's fine by me.

[nkh-dk]

No errors whatsoever with skyfield 1.49, error(s) comes with skyfield 1.50 and forthgoing...
Same place of error btw.

I'll follow the progress on Issue#1114

Thanks for pointing me in a usable direction!

I diffed an extract from the day of error in the final result (Almanac) using Skyfield 1.49 and 1.54, there are apparently no differences in the final output.

[nkh-dk]

Getting late, some more funny details. As I wrote, I can't find any differences in the output on 17042029 pages, but:

I if run only the single day 17042029, I get no errors. If I run 30 days from 02042029, I get no errors.

The "september error" does not come if I run only the single reported day of error, the 2nd.

And if I run from 02092029 and 30 days forward, no error is produced.

It seems as running the whole month makes a difference...

[aendie]

I guess that's while using Skyfield 1.49
The new issue #1114 that I reported is weird and I can believe it's the same unresolved problem as you are experiencing.

Something appears to be unstable and I'm fairly confident the failure does not come from Skyalmanac but deeper within the Skyfield code (or deeper still maybe). I think that the changes between Skyfield 1.53 and 1.54 highlighted this problem ... but until we find and fix it, we won't be sure. Till then patience is required.

Oh, one idea. When I have issues, I usually turn off multiprocessing first and run the code (slower) using single-processing. Just add the switch "-sp" to your command line. Now if you find the error appears only during multiprocessing (which I doubt), that would be difficult to locate... I have had no issues at all while multiprocessing. Issue #1114 runs purely in single-processing mode (and fails).

[nkh-dk]

I'll try doing some runs on singlecore later. My issue arises already using ver. 1.50 of Skyfield, obviously something has changed between v1.49 and 1.50 - And the problem continues into the following versions.
I'll see if I can get some idea by looking into Skyfield version changes docs.

As we with Skyfield 1.49 runs fine, can we then consider the rest of the code is fine...?

[aendie]

Yes... personally I think the rest of the code is fine. Back in 2021 I generated all almanacs from 2020 to 2050 without any errors using the default de421.bsp ephemeris. I truly think the current problems lie within Skyfield itself (rather than in the numpy version or Python version). I have the highest regard for Brandon Rhodes and Skyfield is a brilliant invention of his. I'm sure we'll discover the cause and a solution.