cosinekitty / astronomy

Astronomy Engine: multi-language calculation of Sun, Moon, and planet positions. Predicts lunar phases, eclipses, transits, oppositions, conjunctions, equinoxes, solstices, rise/set times, and other events. Provides vector and angular coordinate transforms among equatorial, ecliptic, horizontal, and galactic orientations.
MIT License
488 stars 63 forks source link

Lunar eclipse (and phase) prediction has a timelag of 1-2 minutes #290

Closed alex-the-coder closed 1 year ago

alex-the-coder commented 1 year ago

Hi and thanks for the great library!

When I tested the calculated data in the "node lunar_eclipse" demo, I found that the calculated data has a 1-2 minute timelag from NASA's official lunar eclipse data: https://eclipse.gsfc.nasa.gov/LEdecade/LEdecade2021.html ( You also use this data for testing in issue #52 ). The calculation of the lunar phases has the same timelag.

node lunar_eclipse NASA diff
2023-10-28 20:13:57 UTC - Peak of partial eclipse 2023 Oct 28 20:15:18 Partial 1 min 21 sec
2029-06-26 03:22:07 UTC - Peak of total eclipse 2029 Jun 26 03:23:22 Total 1 min 15 sec

What is this? Should there be a timelag of 1-2 minutes, because the accuracy of your library is 1 arcminute? Or some error is found and waiting for a fix?

astronomy-engine_demo_nodejs_lunar_eclipse_fail

cosinekitty commented 1 year ago

Hi @alex-the-coder, and welcome to the project! Your timing error measurements are consistent with my own testing and theoretical predictions.

Here is how to look at it from a theoretical point of view. The formulas I use for the geocentric position of the Moon are accurate to within 2 arcseconds. The Earth's angular error as seen from the Sun will be within 6 arcseconds.

So let's think about how each of those would contribute to timing errors. I'm going to assume the Earth's heliocentric angle error would affect timing based on the Earth's orbital speed around the Sun. So that would be 360 degrees for each 365.25 days = 0.9856 degrees/day. Converting units, that is an angular change rate of 2.464 arcsec/minute. If I divide the expected maximum error of 6 arcsec by the angular rate 2.464 arcsec/minute, we get an expected worst case timing error contribution of 2.435 minutes.

With similar analysis for the Moon, we determine its geocentric orbital rate to be 360 degrees in 29.5 days (the synodic period, which is the mean interval between full moons), or 12.2 degrees/day = 30.5 arcsec/minute. Dividing 2 arcsec error by 30.5 arcsec/minute = 0.066 minutes.

I conclude from this that the Earth's heliocentric position error dominates the lunar eclipse timing error, and the worst case should be about 2.435 + 0.066 minutes, or approximately 2.5 minutes.

And in fact, one of my unit tests checks lunar eclipse timings over the years 1701 to 2200, and finds a maximum error of almost exactly 2 minutes:

$ ./ctest -v lunar_eclipse
C LunarEclipseTest: PASS - (verified 1210, skipped 9, 111635 CalcMoons, max_diff_minutes = 2.000, avg_diff_minutes = 0.187)

The data I use for this test come from Fred Espenak's Five Millennium Catalog of Lunar Eclipses.

From a backyard observer's point of view, an error of a few minutes while observing a lunar eclipse is negligible, because in practice it is impossible to judge exactly when lunar eclipses begin, peak, or end. In addition to the inherent blurriness of the Earth's shadow, variations in the Earth's atmospheric conditions will make actual prediction accuracy unattainable. However, I don't know what application you have in mind, and it might be that Astronomy Engine isn't going to be accurate enough for your needs.

I hope this helps!

alex-the-coder commented 1 year ago

Don Cross, thanks a lot for the detailed and clear answer Now I understand that the calculation accuracy in your engine is less than 2 minutes and this is not a bug.

In my searches, I found several well-known Windows tools: Moontool for Windows, Home Planet and other astronomy tools by John Walker This tools has open source code writen on C, so anyone can download it and see used alghoritms. But, unfortunately, nothing is known about their accuracy.

I have one more question for you as an astronomer: is your engine more accurate than John Walker's instruments, or less? Can you take a look at its source code and infer the accuracy of the algorithms? Primarily interested in the accuracy of calculating the time of the lunar phases.

cosinekitty commented 1 year ago

I think the only way to know the accuracy would be to test the code and compare its results with the output of a reliable tool like JPL Horizons. You might also want to look at Stellarium, which I believe will be much more accurate than Astronomy Engine, but also much more complicated and slower.

alex-the-coder commented 1 year ago
NASA node lunar_eclipse diff stellarium-web.org diff
2023 Oct 28 20:15:18 Partial 2023-10-28 20:13:57 UTC - Peak of partial eclipse -1m 21s 2023-10-28 20:25:10 UTC +9m 52s

Stellarium, at least the web version, has a tilemag of about 10 minutes...

Perhaps you know where to find reliable data on the phases of the moon in the form of a table?

cosinekitty commented 1 year ago

Can you tell me more about why you need such accuracy for lunar eclipses? I feel like there is something I'm missing in trying to help you. When I think about observing a lunar eclipse, in practice, it is not possible to tell exactly when they begin, peak, or end. If you have a hundred people outdoors watching an eclipse together, and you ask them to tell you when the eclipse has started, they will look at each other and say, I'm not sure, maybe? They certainly will not agree to within 10 minutes. And nobody will have any clue exactly when the peak of the eclipse is.

One of the reasons different computer programs disagree about when lunar eclipses begin or end, is that there are centuries of unresolved disagreement where different people can't agree on what they are seeing. There is a long-standing controversy about how thick we should assume the Earth's atmosphere is, and thus how large the Earth's shadow is when it reaches the Moon. Something like a volcanic eruption a week before an eclipse can change the opacity of the Earth's stratosphere, and thus affect eclipse timing by 10 or 20 minutes. Nobody can predict volcanic eruptions years in advance, or other such atmospheric effects. I could bore you to tears just with this one unresolved problem, LOL.

I guess what I'm saying is, there really isn't a definite answer to exactly when lunar eclipses start or finish, because nobody can prove that they are definitely right and other people are definitely wrong. There are also important factors that nobody can predict. So when you feel like you need to get an answer exactly to the minute, I wonder why you think that is important, especially because it's not possible in reality. From a practical point of view, people just want to know when they should be outdoors to watch the eclipse begin, peak, and end, and if you are within 10 minutes or so, everybody is happy.

It's entirely possible I'm not aware of some reason you are doing these calculations. There is a common issue where someone asks how to do something, but doesn't say why they want it, so the resulting answer they receive isn't as helpful as it could be. So please be patient with me because I could easily be missing the point due to my lack of context.

Regarding lunar phases, it's important to understand that a lunar eclipse peak occurs near the full moon, but generally not at the exact same time. Full moon is generally defined as the moment when the Moon's ecliptic longitude is 180 degrees away from the Sun's, as measured from the center of the Earth. However, the Moon can be a little north or south of the ecliptic plane when this happens, yet still pass through the Earth's shadow. Also, the Moon passes through the Earth's shadow at some angle to the ecliptic plane, meaning the moment of deepest shadow can be 15 to 30 minutes away from the moment of full moon. This eclipse diagram shows a good example of how the moment of greatest eclipse is not the same as the moment of full moon.

It is also possible to use different definitions of lunar phases. Instead of using ecliptic longitude, someone could use the elongation angle of the Moon from the Sun as seen from the center of the Earth, or even from a given observer's location on the surface of the Earth. And even more than for eclipses, it is very difficult for a human being looking at the Moon to judge the exact moment it's full, at first quarter, etc.

So please let me know more about the reasons behind your concerns for timing accuracy. My best guess is, you probably don't need as much accuracy as you think, but I could be wrong since I don't know what your goal is. I hope this is helpful.

alex-the-coder commented 1 year ago

I completely agree with you on everything related to eclipses. Here I only used them to check the accuracy, because I could find reliable information about eclipses on the NASA website.

What I need is high accuracy in calculating the time of the lunar phases. The data published on the Internet are accurate to the minute with incomprehensible rounding (i.e., the real error is 2 minutes). Therefore, it is not possible to me to understand which of the calculation algorithms is the most accurate and to find actual data on the time of the lunar phases for testing.

In total, high accuracy is needed in calculating the time of the lunar phases and the moments of the solstices and equinoxes for compiling a calendar of lunar events.

cosinekitty commented 1 year ago

I still don't understand why a 2-minute uncertainty in lunar phases is intolerable. I suppose I'm failing to think of a use case where that uncertainty window would bother anyone. There are a variety of confounding factors that make lunar phases inherently vague, including libration and tides of the Moon's nonspherical shape, craters, and the earthbound observer's topocentric parallax.

But assuming that's the case, I think your best bet would be to use data generated by JPL Horizons or NOVAS, both of which use the most accurate models possible. JPL Horizons is an online-only tool, and NOVAS is a combination of code and very large ephemeris files that takes a while to understand and apply correctly.