Solar total eclipse (2017) calculations error

[Gilmer Allen Gary]

Since the 2017 Aug 21 solar total eclipse is coming across the US, and particular the southeast of the US . I was using Stellarium to view the eclipse from the location of the Pisgah Astronomical Research Institute with Long,Lat location of -82.8753, 35.1986 (which is near Rosman, NC, USA) around 1800UT and Stellarium does not show it as a "total" eclipse. Stellarium does show the event as an ALMOST total eclipse but not a total. If you look at the NASA/GSFC website
http://eclipse.gsfc.nasa.gov/SEgoogle/SEgoogle2001/SE2017Aug21Tgoogle.html , and zoom in toward Rosman (PARI) location,
the website map shows that the location will be in a total eclipse. Hence the Stellarium calculations are a little off. I pass this along to you incase there is a desire for someone to be notified of this error.

I enclose a script that shows that the solar total eclipse is not total:
//
// Name: 2017 solar eclipse
// Description: Shows the solar eclipse in 2017 as seen
// from Pisgah Astronomical Research Institute, NC.
//
txt1 = LabelMgr.labelScreen("Place: PARI, Rosman, North Carolina", 30, 80, false, 20, "#0080FF");
txt2 = LabelMgr.labelScreen("Date: 2017-08-21.", 30, 55, false, 20, "#0080FF");
txt3 = LabelMgr.labelScreen("A solar eclipse...", 30, 30, false, 20, "#0080FF");
LabelMgr.setLabelShow(txt1, true);
LabelMgr.setLabelShow(txt2, true);
LabelMgr.setLabelShow(txt3, true);
core.clear("natural");
core.setDate("2017:08:21T17:00:00");
core.setObserverLocation(-82.8753, 35.1986, 672, 1, "PARI, Rosman, North Carolina", "");
core.selectObjectByName("Moon", false);
StelMovementMgr.setFlagTracking(true);
core.wait(2);
StelMovementMgr.autoZoomIn(2);
core.setTimeRate(76);

LabelMgr.deleteAllLabels();
core.wait(125);
core.setTimeRate(8);
StelMovementMgr.autoZoomOut(2);
core.selectObjectByName("");
core.clear("natural");
core.setTimeRate(1);
core.setDate("now");
StelMovementMgr.autoZoomOut(2, true);

[Gilmer Allen Gary (gag0002)]

Here's the log file:

2014-01-31T15:55:37
Windows 7
Compiled using MinGW GCC 4.6.1
Qt runtime version: 4.8.4
Qt compilation version: 4.8.4
Addressing mode: 64-bit
Total memory: 8086 MB (unreliable)
Total virtual memory: 8388607 MB (unreliable)
Physical memory in use: 23%
Processor speed: 2294 MHz
Processor name: Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz
Processor speed: 2294 MHz
Processor name: Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz
Processor speed: 2294 MHz
Processor name: Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz
Processor speed: 2294 MHz
Processor name: Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz
C:\Program Files\Stellarium\stellarium.exe
 -------------------------------------------------------
[ This is Stellarium 0.12.4 - http://www.stellarium.org ]
[ Copyright (C) 2000-2013 Fabien Chereau et al ]
 -------------------------------------------------------
Writing log file to: "C:\Users\Allen\AppData\Roaming\Stellarium\log.txt"
File search paths:
  0 . "C:\Users\Allen\AppData\Roaming\Stellarium"
  1 . "."
Attempting to use an existing older config file.
Config file is: "C:\Users\Allen\AppData\Roaming\Stellarium\config.ini"
Going to initialize the OpenGL 2 renderer
OpenGL supported version: "3.1.0 - Build 9.17.10.3223"
Qt GL paint engine is: "OpenGL2"
GL vendor is "Intel"
GL renderer is "Intel(R) HD Graphics 3000"
QGLShader::link: "No errors.
"
Log of the compilation of builtin shader " plainShader " : "Built successfullyNo errors.
"
QGLShader::link: "No errors.
"
Log of the compilation of builtin shader " colorShader " : "Built successfullyNo errors.
"
QGLShader::link: "No errors.
"
Log of the compilation of builtin shader " textureShader " : "Built successfullyNo errors.
"
QGLShader::link: "No errors.
"
Log of the compilation of builtin shader " colorTextureShader " : "Built successfullyNo errors.
"
QGLShader::link: "No errors.
"
QGLShader::link: "No errors.
"
Cache directory is: "C:\Users\Allen\AppData\Local\stellarium\stellarium\cache"
Sky language is "en_US"
Application language is "en_US"
Loading Solar System data ...
Loaded 75 / 75 planet orbits from "C:\Users\Allen\AppData\Roaming\Stellarium\data\ssystem.ini"
Found an old starsConfig.json file, upgrade..
Creates file "C:\Users\Allen\AppData\Roaming\Stellarium\stars\default\starsConfig.json"
Loading star data ...
"Loading ".\stars\default\stars_0_0v0_3.cat": 0_0v0_2; 4963"
"Loading ".\stars\default\stars_1_0v0_3.cat": 1_0v0_2; 21598"
"Loading ".\stars\default\stars_2_0v0_3.cat": 2_0v0_2; 150090"
"Loading ".\stars\default\stars_3_1v0_2.cat": 3_1v0_1; 423540"
Finished loading star catalogue data, max_geodesic_level: 3
navigation/preset_sky_time is a double - treating as jday: 2.45151e+06
Loaded 10051 NGC records
Loading NGC name data ...
Loaded 412 / 412 NGC name records successfully
Loading star names from ".\skycultures\western\star_names.fab"
Loaded 236 / 236 common star names
Loading star names from ".\stars\default\name.fab"
Loaded 4359 / 4359 scientific star names
Loading variable stars from ".\stars\default\gcvs_hip_part.dat"
Loaded 6886 / 6886 variable stars
Loaded 88 / 88 constellation records successfully for ...

[Alexander Wolf (alexwolf)]

Just for note: Stellarium has error of calculation for northern border of eclipse. For location from report total eclipse should be between 1836UT - 1839UT and Stellarium doesn't show total eclipse near 1800UT correctly.

[Victor Reijs (web-victor-reijs)]

Is 0.14.0 already using DE431? If so then the n.dot mentioned when hovering over the time is wrong (it is VSOP's one). So you need to change this into the DE431. For DE431 it is close to: -25,80
Now you will just have wrong eclipse results by definition (and this could rectify the issue of the eclipse this or next year.)

I don't know if the relativistic issues in TDB will provide large error (aka in seconds, I understand TBD-TT is more in micosec for 2000 CE). Don't know how big the different of TDB and TT is for say 500o BCE, but can't imagine it is seconds (and still very small compared to DeltaT).
I agree you need to get the systematic error as small as possible, but it might be the n.dot could remove a large systematic error.

All the best,

Victor

[Victor Reijs (web-victor-reijs)]

Ok did a test with 0.15.0:

Just downloaded 0.15.0 on my home laptop. I see the DeltaT presentation when hovering over the time. I see a n.dot mentioned the same the one of 0.14.0 (which should be VSOP I understand) (-23.8946). So it seems that DeltaT is compensated to the wrong n.dot (of VSOP). This needs to be changed to n.dot of DE431 (-25.8).
I think at the end of your DeltaT function you have this compensation function, something like:

'###################################################################
Public Function DeltaTndot(JDNDays, DeltaTfrom, ndotfrom, ndot)
' JDNDays [Days]
' DeltaTfrom [sec]
' ndotfrom ["/cy^2]
' ndot ["/cy^2]
' DeltaTndot [sec]

J1955 = 2435107.5
diff = -0.000091 * (ndot - ndotfrom) * (JDNDays - J1955) * (JDNDays - J1955) / 365.25 / 365.25
DeltaTndot = DeltaTfrom + diff
' DeltaTndot = swe_get_tid_acc()
End Function

And a call like Deltandot (date, deltaTvalue, ndotofdeltatformula, ndotofephemeris)
ndot of Espernak Meeus's ndtdeltaformula=-26
n.dot of DE413 is ndotephemeris=-25.8
so the call should be: Deltandot (date, deltaTvalue, -26, -25.8)
and not: Deltandot (date, deltaTvalue, -26, -23.8946)

<The above code is just for illustration (it is from my ARCHAECOSMO package, but I know Stellarium also has something like this (as I provide that formula;-).

Does this help?

Still the question: why is 0.14.0 (which used VSOP, I understand from Georg) giving the same results as DE431 (0.15.0)???

Both give the same wrong eclipse for my benchmark at 14 Jan 484 CE at Athens (which should be a total eclipse just after sun rise, around 8:58 GMT)

All the best,

Victor

[Alexander Wolf (alexwolf)]

Where is source for coefficient -0.000091?

[Alexander Wolf (alexwolf)]

Gilmer Allen Gary, please check version 0.90.0.8784 - I see total eclipse in Pisgah Astronomical Research Institute (available in locations list).

[Victor Reijs (web-victor-reijs)]

Ok, I now tested also 0.90.0.8784. It looks the n.dot of VSOP is replaced with the n.dot of DE431 in the DeltaT procedure. So that is indeed mathematical correct.

Thanks for adjusting the n.dot! I also understand this aligned now the other eclipse people wanted to be correct. Great.

All the best,

Victor

[Alexander Wolf (alexwolf)]

Can anybody re-check this issue?

[Alexander Wolf (alexwolf)]

OK, I can see issue on FOV lesser than 2 degrees

[gzotti (georg-zotti)]

It's still open.
It seems there is also a problem with topographic correction on the ellipsoid. The current solution from 0.14 was not completely correct.
r9554 provides a tentative fix of topographic correction.

However, lunar position still seems about 1 minute late. Not sure if something is still principally flawed with the moon (see also https://bugs.launchpad.net/stellarium/+bug/1509659)

[gzotti (georg-zotti)]

Next factor we had not dealt with properly: light time correction with the sun. This shifts the sun by about 20", just enough to cater for most of the error. (It should be handled by dealing with aberration, but Stellarium does currently not include aberration in general.)

r9572: I shift the sun's position by earth's movement during light time travel.

This brings us to within a few seconds of what other sources like NASA https://eclipse2017.nasa.gov/sites/default/files/interactive_map/index.html say, checked for 2017 and my records from 1999!