ancient solar eclipses are incorrect

[Ilan Tal]

I started to use your software and found it delightful. I put my telescope on the path of a solar eclipse of 2011 and I saw a beautiful eclipse. Since I live in Haifa, Israel I was interested to see if I could see some ancient eclipses of the area. Egypt at the time of Ramses was interesting to see.

The first problem was the calender. The ancient dates use the Julian calendar instead of the Gregorian one. The Gregorian calendar was created in 1582 and Britain finally switched to it in 1752, dropping 11 days in the process. The error extrapolated back to -1375 caused me to add 11 days to get the moon and sun lined up properly.

Still it was clear that things were not properly lined up for a total eclipse. First of all the time of day was incorrect with the sun and moon lining up best at sunrise (or sunset, I forget).

I found a document
www.egiptomania.com/EEF/Blindness.pdf

which shows on page 14 that the time was off by 9 hours. There may well be other problems resulting from such a long extrapolation, but these are the ones I'm aware of.

It would be really nice if you could switch to a Julian calendar for dates before either 1752 or 1582 and fix the time of day and see if perhaps the simulation in fact works for ancient times. There are several places and dates mentioned in the paper. Thebes is 25N, 32E. Urgarit is 35N, 35E.

Thanks,
Ilan

[treaves (treaves)]

Yes, we are all aware of what a calendar is, and how it works. What you seem to be unaware of is what astronomers use: http://en.wikipedia.org/wiki/Astronomical_year_numbering .

[Ilan Tal (ilan-tal)]

Since I didn't look at the code, all I could see was that it didn't work correctly. I started playing to see where I could find a partial overlap and found it 11 days later. That just happened to roughly fit the calendar difference. All what was clear was that the extrapolation 3000 years back didn't seem to be working.

I tried the -(n-1) correction, so that at least the day looks correct. Still the extrapolation isn't accurate and the greatest overlap time is about sunset. So it could be that the above time correction of about 9 hours isn't being included. It is difficult to eyeball it to know if the moon will cover the sun, or if additional corrections are required.

I'm happy at least to know that the Julian calendar is indeed in use.

I think you should change the status from "won't fix" to something else. In any case, it is very nice software.

Ilan

[Bogdan Marinov (daggerstab)]

The cause is either the way Stellarium models the position of the Moon, or the way it calculates time. The calendar system hasn't got anything to do with it.

See also:
https://bugs.launchpad.net/stellarium/+bug/575621
https://blueprints.launchpad.net/stellarium/+spec/stellarium-deltat

[masegand (masegand)]

No i think besides deltaT the biggest problem is the linear precession model in Planet::computeTransMatrix
causing also wrong obliquity of earth axis
The other inaccuracies (Vsop87 instead of JPL DE406, Moon model) are much smaller

[Ilan Tal (ilan-tal)]

There is nothing quite like doing an experiment. I said to myself: suppose the delta T isn't implemented in the code, what would that imply? The time should be off by roughly 9 hours. 9 hours means 135 degrees. So instead of appearing at 35E, I should look at 100W. So I tried the date May 3 1375BCE at 35N, 100W and guess what? I found a total eclipse, just like it says in the literature.

I'm not an expert, but it seems to be saying that delta T isn't working or isn't implemented. It would be nice if someone could look at the code.

Thanks,
Ilan

[xjubier (xjubier)]

I haven't looked at the source code but ∆T is likely the culprit. Precession may also need to be looked into, but probably not the main cause of the problem.

You can find an interactive eclipse map of this TSE at:
http://xjubier.free.fr/en/site_pages/solar_eclipses/xSE_GoogleMapFull.php?Ecl=-13740503&Acc=2&Umb=1&Lmt=1&Mag=0&Max=0

A ∆T value of 32474.3 seconds has been used and the interval of confidence is of 1523 seconds.

The map is interactive, which means that if you click anywhere on the map you'll be shown the local circumstances at the location.
You can clearly see the eclipse occurred t sunrise and that it couldn't be total over Egypt.

Any other solar eclipses over the -2000 to +3000 time period can be looked into there:
http://xjubier.free.fr/en/site_pages/solar_eclipses/5MCSE/xSE_Five_Millennium_Canon.html

The same tool is also available for lunar eclipses:
http://xjubier.free.fr/en/site_pages/lunar_eclipses/5MCLE/xLE_Five_Millennium_Canon.html

Xavier

[Ilan Tal (ilan-tal)]

Thanks Xavier, that map is very nice.

Whereas I started to look at what took place over Egypt at the time of Ramses, that particular one was for Ugarit which is northern Syria of today. I chose it because it was a total eclipse, documented in the literature. The Ramses one was shorter which gave me a greater chance to miss it.

Your map shows it going over northern Syria, and indeed the eclipse showed up close to sunset. I didn't look exactly because my 9 hours was only a rough estimate.

What I was interested in was some sort of confirmation that the delta T was the main cause (if the experiment succeeded, which in fact it did).

I hope someone will include the fix into Stellarium because it is a delightful program. If so, I would ask the Ubuntu repository to be updated so the fix will propagate to the Linux world automatically.

Ilan

[Fabien Chéreau (xalioth)]

Hi,
I confirm that Delta T is currently not yet implemented (and indeed introduce a big error): we are in the process of doing it, any help is welcome.
For the rest, quoting Georg Zotti:
>> There are still open problems in long-term astronomical computations, esp.
>> the constant obliquity of the ecliptic (I added a function to
>> planetsephems/sideral_time.[hc], but it is not used outside. It is not
>> meaningful to deal with nutation if changes in ecliptic obliquity are
>> ignored!), deltaT (what happened?), lunar axis rotation. Given the
>> theoretical +/-100000 years time frame, a palaeo-astronomer asked me if I
>> would use it for things like Lascaux caves. I think, rather not at this
>> time. The VSOP is certainly unusable for 17000BC, but it would be
>> fascinating to really have that. But if we keep to the VSOP range (about
>> 5000BC onward?) for now and combine all elements correctly, it's better
>> than ad-hoc partial solutions.