-
-
Notifications
You must be signed in to change notification settings - Fork 244
Description
Using Skyfield 1.54 I came across a somewhat rare warning:
Image
I have reduced the code to an MWE as best I could. I get no information where this fails in my code.
Here is my simplified code to reproduce the error:
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
from datetime import date, datetime, timedelta
from skyfield import VERSION
from skyfield.api import Loader, wgs84, N, S, E, W
from skyfield import almanac
d = date(2000, 1, 1) # select DATE year, month, day
lat = 67.0 # select latitude
obj = 6 # select PLANET 0, 1, 2, 3, 4, 5, 6
print("\nSkyfield version = ",VERSION)
load = Loader("./")
ts = load.timescale()
eph = load('de421.bsp')
mercury = eph['mercury']
venus = eph['venus']
earth = eph['earth']
mars = eph['mars']
jupiter = eph['jupiter barycenter']
saturn = eph['saturn barycenter']
uranus = eph['uranus barycenter']
neptune = eph['neptune barycenter']
pl_name = ['Mercury', 'Venus', 'Mars', 'Jupiter', 'Saturn', 'Uranus', 'Neptune']
pl_name2 = ['Mercury', 'Venus ', 'Mars ', 'Jupiter', 'Saturn ', 'Uranus ', 'Neptune']
pl_eph = [mercury, venus, mars, jupiter, saturn, uranus, neptune]
planet = pl_eph[obj]
dt = datetime(d.year, d.month, d.day, 0, 0, 0)
dt_start = dt
daysinyear = (date(d.year+1, 1, 1) - date(d.year, 1, 1)).days
latns = 'N' if lat >= 0.0 else 'S'
print("year {}: {} at latitude {:.1f}°{}".format(d.year,pl_name2[obj],abs(lat),latns))
#---------------------------------------------------------------------------
topos = wgs84.latlon(lat, 0.0 * E, elevation_m=0.0)
observer = earth + topos
print("... raw data from almanac.find_settings and almanac.find_risings:")
for i in range(daysinyear):
t0 = ts.ut1(dt.year, dt.month, dt.day, dt.hour, dt.minute, dt.second)
t1 = ts.ut1(dt.year, dt.month, dt.day+1, dt.hour, dt.minute, dt.second)
planetset, iS = almanac.find_settings(observer, planet, t0, t1)
planetrise, iR = almanac.find_risings(observer, planet, t0, t1)
for ndx, dt0 in enumerate(planetset):
print(" set ",dt0.utc_iso(' ') ," ",iS[ndx])
for ndx, dt0 in enumerate(planetrise):
print(" rise",dt0.utc_iso(' ')," ",iR[ndx])
dt += timedelta(days = 1)
I am using Python 3.13.9. My code works perfectly, i.e. as expected, in 99.999% of cases and I have since enhanced the code to over double the length above. As far as I can tell, there are TWO ISSUES here:
- the RuntimeWarning from almanc.py in line 339 (Skyfield 1.54)
almanac.find_settings()oralmanac.find_risings()outputs a TIME value thatdt0.utc_iso(' ')cannot convert and crashes with the messageValueError: cannot convert float NaN to integer.
Initially I believed that the ValueError is a consequence of the RuntimeWarning. Now I tend to think the reverse is true. I adapted the program below that scans all planets for a given range of latitudes for several years so that the ValueError is trapped: it prints rise ----- NaN error ----- or set ----- NaN error ----- usually without any RuntimeWarning, however runing the program above for the given year/planet/latitude will always print the RuntimeWarning first (on the date on which it fails).
I would REALLY APPRECIATE it if the RuntimeWarning and associated ValueError could be eliminated.
As always.... sincere thanks for all assistance!
UPDATES:
It occurs on 2031年04月18日 and you can set for i in range(1): in the last for loop.
It then fails also with a second RuntimeWarning, this time in timelib.py at line 673:
I have now switched to incrementing the latitude in tenths of a degree as an integer, e.g. from 670 to 720, increment 1, and I divide by 10 to get the latitude (degrees) as a float. This way I avoid accumulating the error using a float increment of 0.1 repetitively.
Next failure point I noticed (using a later program version) is with Neptune on 2000年03月18日 at 68.7°N:
Image
By comparison, here is correct data from Skyfield 1.49:
Image
Nothing unusual happens on 2000年03月18日 ,,,,,,,,
Take a look at my chart for Neptune in 2000 at 68.7°N with Skyfield 1.49:
Initially I thought that something broke in Skyfield 1.54
Using Windows 11, numpy 2.4.1, and Skyfield 1.54, here are some random test cases using where I detected this issue occurs:
2000年09月17日 50.0N Jupiter
2000年12月12日 50.0N Neptune
2000年11月17日 50.5N Uranus
2000年07月27日 50.7N Jupter
2000年04月29日 54.9N Neptune
2000年10月26日 55.6N Neptune
2000年05月20日 56.1N Uranus
2000年10月24日 56.8N Neptune
2000年05月29日 59.3N Neptune
2000年06月26日 60.4N Neptune
2000年05月03日 61.1N Neptune
2000年05月03日 62.1N Uranus
2000年05月06日 63.0N Neptune
2000年04月22日 63.8N Uranus
2000年10月10日 64.2N Uranus
2000年03月24日 64.4N Neptune
2000年05月27日 65.6N Uranus
2000年06月08日 67.0N Neptune
2000年03月18日 68.7N Neptune
2000年10月06日 69.3N Neptune
2000年05月13日 71.6N Uranus
2001年08月18日 50.4N Mars
2001年01月15日 51.2N Neptune
2001年10月29日 52.3N Uranus
2001年04月29日 56.0N Uranus
2001年07月05日 56.1N Neptune
2001年11月22日 57.3N Jupiter
2001年10月10日 57.6N Saturn
2001年11月21日 58.1N Jupiter
2001年05月13日 58.5N Neptune
2001年01月16日 58.8N Jupiter
2001年09月12日 58.9M Meptune
2001年06月06日 60.6N Neptune
2001年04月13日 61.2N Neptune
2001年07月12日 63.4N Jupiter
2001年01月02日 64.0N Saturn
2001年10月31日 64.2N Jupiter
2001年08月31日 64.7N Neptune
2001年05月22日 65.8N Uranus
2001年05月26日 66.0N Neptune
2001年05月14日 66.1N Uranus
2001年10月14日 67.0N Neptune
2001年06月23日 68.1N Uranus
2001年09月20日 70.0N Neptune
2001年07月05日 70.2N Uranus
2001年10月14日 67.0N Neptune
2001年06月23日 68.1N Uranus
2001年09月20日 70.0N Neptune
2001年07月05日 70.2N Uranus
2020年05月23日 68.4N Uranus
2021年06月03日 67.3N Saturn
2021年06月30日 68.7N Uranus
2023年12月31日 70.9N Uranus
2025年02月09日 69.8N Uranus
2026年02月08日 50.7N Uranus
2027年07月16日 60.2N Uranus
2028年04月04日 56.9N Uranus
2028年07月23日 69.3N Saturn
2029年11月04日 52.0N Mars
2029年04月23日 54.0N Uranus
2029年01月26日 62.2N Jupiter
2029年12月23日 65.9N Uranus
Initially I suspected this issue is caused by Skyfield 1.54 alone, though I saw no reason for it.
So I decided to test using Skyfield 1.53 (and numpy 2.4.1 in Windows 11):
I tested the years 2027, 2028 and 2029 for latitudes between 50.0°N and 72.0°N in 0.1 degree steps [using integer steps because it is impossible to represent 0.1 (decimal) precisely in binary with a finite number of digits]
Using Windows 11, numpy 2.4.1, and Skyfield 1.53, I found these cases where it fails with the same symptoms:
2027年08月11日 Neptune 50.0N
2028年01月20日 Jupiter 55.7N
2029年07月14日 Saturn 56.8N
So I see that this issue is not limited to Skyfield 1.54 (though 1.54 is more error-prone than 1.53).
(TBD: look at Skyfield 1.49, which I think is 100% free of this problem.)
I switched to another hardware platform: an old ASUS Zenbook with Intel i7-8565U CPU.
Using Windows 11, numpy 2.4.2, and Skyfield 1.54 I got exactly the same four failures for the year 2029 between 50.0°N and 72.0°N as above.