SkyAlmanac-Py3 stops working.

[CIRK22]

First of all I must thank you for your work and applications you've made (and for that they are free).
I appreciate your knowledge about astronomy, astronavigation, tex, python ...
Wow it's awesome. It made a great impression on me.

However, I have to write about the problem I encountered.

'Pyalmanac-Py3' - works without problems.
'SFalmanac-Py3' - works great. It has created for me Almanacs up to 2200 ... I love it.

But 'SkyAlmanac-Py3' doesn't work for me.
It stucks when full almanac is being created.
It stucks especially at June.
I've tried to run it on many machines - on Desktop PC (Intel CPU, Windows 11), tablet with Windows 10, other PC (amd CPU, Win 11), Ubuntu 18 on Virtual Machine, Ubuntu 19 on Virtual Machine, Ubuntu 20 on Virtual Machine.
And also on various versions of Python - Python 3.5, Python 3.6, Python 3.9, Python 3.10.
Always the same problem.

I've tried PIP version, non pip version.
Versions from july 2021, may 2021, april 2021.

Whether modern or traditional almanac is commisioned.

Below i enclose console dump:

c:\SkyAlmanac-Py3-master>skyalmanac -v

What do you want to create?:

1   Nautical Almanac   (for a year)
2   Sun tables only    (for a year)
3   Nautical almanac   -  6 days from today
4   Sun tables only    - 30 days from today
5   "Increments and Corrections" tables (static data)

1
Please enter the desired year
as yyyy ... or the FIRST and LAST year as yyyy-yyyy
2020-2050
What table style is required?:

    t   Traditional
    m   Modern

m
Be patient - this may take a while.

Creating the nautical almanac for the year 2020

Jan ..........
Feb ........
Mar ..........
Apr .........
May .........
Jun .......

==========================================

And that's it, even hours later it looks the same.
Nothing is created (i mean no TEX or PDF file).
Unlike when i select any of other options.
Creating 'Sun tables only" works fully with no errors.
In brief options 2-5 works fully without errors.

Best Regards,
CIRK22

[aendie]

Hello CIRK22 and thanks for your positive feedback. SkyAlmanac is rather neglected as I built it initially to be a hybrid giving better performance than SFalmanac (in single-pricessing mode). When I finally got SFalmanac to run using multi-processing I saw no further justification for SkyAlmanac.

However, I am motivated to check this out - it should not just hang up. Currently I am miles away from my PC, but I promise I'll dig into it when I am back home again. Please be patient, I should have an answer by end of April.

Kind Regards, Andrew

[aendie]

Hello CIRK22. I discovered another problem (in both Skyalmanac and SFalmanac)...

The IERS server that provides Skyfield with EOP (Earth Orientation Parameters) data is down since at least the beginning of April 2022. Officially it is only down for maintenance, but it is taking longer than expected. The effect is that when Skyalmanac or SFalmanac require new EOP data, the program fails with an error message.

I discovered that USNO (US Naval Observatory) also store the EOP data. However, from a brief chat with the folks at IERS, someone reminded me that the USNO server was previously down for 2.5 years!! So switching to USNO instead makes little sense. Henceforth I built a check to see if the IERS server is alive (as first priority), and if not I then download the data from the USNO server (as second priority). This bugfix is now in Skyalmanac and SFalmanac.

I then looked at your problem. Skyalmanac should proceed with the same speed when creating data for each month - it never needs longer time within the year. So if you see it stop processing, don't wait ... just cancel processing with Ctrl/C. In fact I was unable to reproduce your problem - it ran just fine on Windows 10 and Ubuntu 20.04 LTS.

So please try again. I think you are running Skyalmanac with files downloaded from GitHub. There is an alternative way to execute Skyalmanac ... use an empty folder (no need to download files) and follow the instructions here: https://pypi.org/project/skyalmanac/

It is possible to have an issue with too little memory (typically with Option 5), but the link above explains how to solve that problem. Maybe you did this and Option 1 ran out of memory? ... then just try downloading the GitHub files instead.

To discover your problem, it may help to know which Operating System you are using (I can do no testing on MacOS).

So please try once again with the new versions I have published (both in GitHub and in PyPI). Good luck!

[aendie]

Okay ... finally I am able to reproduce the problem (testing on my Windows 10 laptop). It hangs on June 2020. So THANK YOU for reporting this to me, and I will investigate further.

As a side-note: I had to re-publish the Skyalmanac version (now 1.3.8) on PyPI as I had an undefined variable that made no difference (and no error) in Python 3.9.4 but is correctly picked up as an error by Python 3.10.4, which I have not tested with until now. My apologies!

Also I was unable to fully download the de421.bsp ephemeris data. It hung at 98% and second time at 96%. This is not my problem ... it has always worked before. Simply copy the ephemeris data file into your new testing folder if you have already successfully downloaded it before. Unlike finals2000A.all, it does not change.

I will report back later ... thanks for your patience.

[aendie]

This error comes from Ephem (not from Skyfield), which is used by Skyalmanac and Pyalmanac. It is an endless loop in very specific cases, e.g. between 23.06.2020 and 25.06.2020.

I have no error using Ephem 4.1 - it appears to come with versions after 4.1.1. I cannot install Ephem 4.1 on my laptop because of a dependency on "Microsoft Visual C++ 14.0 or greater". Attempting to install this on my laptop failed, but it would only prove that Ephem 4.1 works.

It looks like this same "endless loop" error has already been identified here: brandon-rhodes/pyephem#232 so I will follow up on it.

[CIRK22]

After i read your post with the information about that 'Ephem 4.1.1 or newer' may be a culprit i run 'Ubuntu 20.04 LTS' in VM.
Downloaded newest 'SkyAlmanac-Py3' from GitHub, reinstalled Ephem to version 4.1 and run 'SkyAlmanac-Py3'.

So far I have Nautical Almanacs generated for years 2020-2050 based on DE421.bsp, no issues occurred.
Also I have Nautical Almanacs generated for years 2020-2200 based on DE405.bsp, no issues occurred.

So it seems that, as you wrote, Ephem was the source of problems.

I wouldn't like to harass you with messages about problems with app, but I found another one.
I write it only to inform you not to complain or something like that...

This time in 'SFalmanac', to be exact when 'Event-Times Tables' are created for the year 2063.
For me it's a minor problem, so don't bother with it.
I think that more important is Nautical Almanac, so as long as app can generate Nautical Almanac, it's very useful.
And since we know how to deal with 'SkyAlmanac' (install Ephem 4.1) and since we can produce Almanacs - most users shoudn't complain.

I have to mention that Event-Times Tables for the range of years 2020-2062 and 2064-2112 have been created successfully.
Windows 11 and Ubuntu 20.04 LTS in both these systems generation of Event-Times Table for the year 2063 fails.

PS
Here is a console dump (OS: Windows 11 x64, RAM: 24 GB, CPU: Intel(R) Xeon(R) X5550 @ 2.67GHz (CPU: 2))

==================

c:\SFalmanac-Py3-master>sfalmanac -v
[#################################] 100% de405.bsp

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   Nautical almanac   -  6 days from today
5   Sun tables only    - 30 days from today
6   Event Time tables  -  6 days from today
7   "Increments and Corrections" tables (static data)

3
Enter as numeric digits:

- 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)
- nothing for the current day

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

NOTE: only 8 logical processors are available for parallel processessing

Creating the event time tables for the year 2063

Jan ...............
Feb .............
Mar ..............
Apr ..............
May ...............
Jun ..............
Jul ..............
Aug ...........Traceback (most recent call last):
File "C:\SFalmanac-Py3-master\sfalmanac.py", line 564, in
outfile.write(maketables(first_day,0,ts))
File "C:\SFalmanac-Py3-master\eventtables.py", line 595, in maketables
alm = alm + pages(first_day,dtp,ts)
File "C:\SFalmanac-Py3-master\eventtables.py", line 421, in pages
out += page(day1,ts,dpp)
File "C:\SFalmanac-Py3-master\eventtables.py", line 374, in page
page += equationtab(date,dpp)
File "C:\SFalmanac-Py3-master\eventtables.py", line 329, in equationtab
eq = equation_of_time(d,d + timedelta(days=1),UpperLists[k],LowerLists[k],True,True)
File "C:\SFalmanac-Py3-master\alma_skyfield.py", line 1807, in equation_of_time
mp_lower = find_transit2(d, LowerList, True)
File "C:\SFalmanac-Py3-master\alma_skyfield.py", line 1682, in find_transit2
if(iLoops == 0 and se > 0): raise ValueError('ERROR: sec_start ({}) too large on {} at {} ({})'.format(se, d, gha_time, txt))
ValueError: ERROR: sec_start (6) too large on 2063-08-24 at 00:00:07 (Lower Transit)

c:\SFalmanac-Py3-master>

==================

[aendie]

The above problem with event times on 24.08.2063 is fixed (in SFalmanac).

I have also added a new feature in SFalmanac: an option to generate Lunar Distance tables....

A brief description of Lunar Distance is here: https://en.wikipedia.org/wiki/Lunar_distance_(navigation)

Frank Reed does a workshop on the Lunar Distance method: http://reednavigation.com/lunars-class/

And here Frank Reed created reliable tables to compute Lunar Distance predictions.

On 2nd May 2019 the Cambridge University Press published this article by Eric Romelczyk.

But this PDF download link by George Huxtable is maybe the best explanation of Lunars.

I believe taking Lunar Distance observations is the supreme discipline of sextant use.

[aendie]

I'll close this issue soon, but I wanted to let you know that I have published a new version of SFalmanac, the May 2022 update:

• here in GitHub: https://github.com/aendie/SFalmanac-Py3
• in PyPI: https://pypi.org/project/sfalmanac/
• in DockerHub: https://hub.docker.com/repository/docker/aendie/sfalmanac

This now also includes Lunar Distance Charts in addition to the Lunar Distance Tables. This was large update to integrate the new modules into SFalmanac. I hope you try them out.

Thanks again for your testing ... it proved to be useful.