brandon-rhodes
commented
1 year ago Alas, the logic used by find_discrete() routine has not changed between 1.35 and 1.46, so we must look elsewhere for the reason you are getting different results. Your search technique looks like it would be a bit fragile, so my first guess is that updates to the ∆T table are what changes its results. And it turns out that's indeed the cause! Running Skyfield from the repository, I get no gaps when I run your script immediately after:
git co d5e627cbut get the gaps when I try the next revision:
git co 914f87dThe commit in question updated the ∆T table right before the 1.44 release:
914f87d
So, how is your search routine fragile, so that slight differences in its starting conditions can throw it off? I think it's because of this setting:
is_obj_up_at.rough_period = 0.5 # twice a dayThat setting does not, in fact, mean ‘this happens twice a day’ — but, rather, ‘check the value of this variable every 4.0 * rough_period hours’ — a confusing meaning, that has resulted in rough_period getting deprecated back in Skyfield 1.23; the documentation now recommends a much more straightforward value step_days which lets the step size between samples be specified directly.
So by setting rough_period to 0.5, you are getting a sample taken every 2 hours. Which means that when Mars is up for at least two hours, you are guaranteed to find out, since one of your samples will land inside and one outside the state where Mars is up.
But if Mars is up for less than 2 hours, you are taking a gamble. Maybe you'll be lucky and, as Skyfield takes samples 2 hours apart, it will happen to see Mars change state from up to down. But when you're not lucky, then, as you see in your examples, you can miss Mars being up. So I'd recommend two changes:
- Abandon
rough_periodand usestep_days. - If you want to guarantee seeing Mars up for even, say, 15 minutes a day, then your step size needs to be 15 minutes — or, since it's specified in days,
1.0 / 24.0 / 60.0 * 15.0. Once Mars is up even more briefly, you'll again be gambling with whether you miss it.
Another possibility would be to grab the whole year, and run find_maxima to find all the times when Mars is highest. That way, it doesn't matter whether Mars is up at all, since it will still experience a maximum and a minimum altitude about 12 hours apart, even if both of them are below the horizon, so there isn't a danger of missing those events. Then, filter the resulting list and look for rises and sets around the maxima that actually bring Mars above the horizon.
There's an even better approach towards risings-and-settings than that, that I started coding up once, but I can't remember in what state I left the routine. I'll take a look tomorrow and let you know what I find! But these ideas should at least get your investigation moving again.
aendie
I have a big issue with
almanac.find_discretewhich I need to describe in detail. Of course I am looking into my particular issue and I am unaware of other issues that might have been fixed in the meantime. My example relates to one particular condition: MARS rise and set times at latitude 64.0°N. That sounds very specific. I have not found any issues with Mercury, Venus, Jupiter or Saturn. I have no issues with Mars at lower latitudes. So here's how the problem originally surfaced....I am making graphs of planet visibility and Mars looks okay at latitude 63.0N:
There is a small mistake (a shading omission) in the graph above but that's for me to fix. I then tried latitude 64.0N and everything broke. Looking at the graphs without shading I saw a problem immediately:
The Mars SET between Jan 1 and Mar 2 has a gap in it. So does Mars RISE in the same timeframe. It's between Feb 24 and Feb 26 inclusive. In order to investigate this I developed a test program (included below) which outputs Mars' rise and set times in chronological order per day. I also include a calculated 'hbh' field which prints the hours the planet is below the horizon. This field supports my argument why I believe the data is incorrect.
Next I had to investigate if this issue is reproducible in Windows (on Intel) as well as Ubuntu (on AMD). It is! Eventually I found it is tightly connected with the Skyfield version. I also tried the
de440s_plus_MarsPC.bspephemeris besides usingde421.bsp... there was no difference: both had the same issue.Looking at the output from my test program with Skyfield 1.46 you see:
Up to Feb 23 (inclusive) the 'hbh' span slow reduces to Mars being 0.96 hours below the horizon on Feb 23. Then it jumps suddenly to zero for the next three days. And from Feb 27 to Mar 2 it's well-behaved again going down from 0.65 to 0.28 before Mars correctly enters the range Mar 3 to Apr 4 where Mars is above the horizon all day. The issue is with Feb 24 to 26 inclusive. It even suggests that the correct data probably gradually steps 'hbh' down from 0.96 to 0.65 hours.
Next I began to look for the results from other Skyfield versions .... all screenshots are from Ubuntu Desktop 22.04.2 LTS. Skyfield 1.35 gives these results:
Note that there is no "zero hours above horizon" range gap during February but I find the final Feb 23 hbh (0.96 hours) and the initial Apr 5 hbh (0.65 hours) rather high on either side of the time when Mars never sets. Skyfield 1.40 gives me the same results. Skyfield 1.41 on the other hand gives me beautiful data:
And one sees that the Feb 23 to Apr 5 range in previous versions excluded several days of significant data. The final Mar 2 hbh is just 0.28 hours and Apr 3 just 0.35 hours. This has reduced the "days above horizon" from 40 days to 31 days! And the data just looks and feels good. Skyfield 1.42 and 1.43 give the same good results. Skyfield 1.44 is where things break:
This introduces two days (Feb 24 and 25) with no rise or set (Mars still above the horizon) which is illogical. Skyfield 1.45 is the same. Skyfield 1.46 goes a step worse with three days (Feb 24, 25, 26) with no rise or set (Mars still above the horizon).
Please pardon the exhaustive analysis, but it might prove useful in fixing this problem.
Finally I include here a ZIP file that contains my test program that gave me the above results. Please forgive my coding - it was put together in a hurry. I thank all who look into this deeper and I look forward to future versions of Skyfield! Sincere Regards, Andrew
Mars.zip