Hi
Gilmer Allen Gary reported this Bug #1275092 on 2014-01-31: at the location of the Pisgah Astronomical Research Institute (82.8753 W, 35.1986 N) Stellarium does not show a "total" eclipse.
The USNO (U.S. Naval Observatory) provides the following results at PARI : total eclipse, magnitude 1.004, maximum eclipse 18:37:37 UT.
This bug was investigated by Alexander, Georg and Victor Reijs.
Using Stellarium v0.16.0RC1, v0.90.0.9529, the maximum eclipse occurs at 18:45 UT (VSOP87 or DE430): a large 8 minutes discrepancy and the eclipse is not total.
Using Stellarium v0.16.0RC2, v0.90.0.9567, with fix 9554 Improvement of topographic correction, the maximum eclipse still occurs at 18:45 UT (VSOP87 or DE430) without any improvement.
I agree it doesn't seem easy to find the cause of this discrepancy.
All the best
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I know the time is off, but only by ONE minute as it had been before, not eight. I compare to the NASA site https://eclipse2017.nasa.gov/sites/default/files/interactive_map/index.html?zoom=1 at
Lat.: 35.1986° N, Long.: 82.8754° W
Still no complete solution. But the duration is better. I am afraid we have two problems mixed here, and disentangling partially legacy code is not easy. Don't hold your breath for a solution built in 0.16.0, but I do hope we will make it before D Day.
Last edit: gzotti 2017-06-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you very much for investigating.
Just in case I try with another location : Thermopilis (Wyoming) 43 38 44 N, 108 12 53 W.
USNO result: magnitude 1.001, maximum eclipse 17:40:24 UT.
Fred Espenak NASA result: magnitude 1.000, maximum eclipse 17:40:24
Stellarium result: no total eclipse, maximum eclipse 17:48 UT (same discrepancy 8 minutes).
I wonder why the difference is 8 minutes instead of 1 minute !
Anyway, you have done again a great job with so much improvements regarding version 0.16.
All the best.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not sure what you are doing.
NASA: start 17:40:00, end 17:40:53
Stellarium result: start 17:40:44, end 17:41:47.
Again, we are roughly one minute late and somewhat off in duration. Of course, I assume NASA takes moon figure and other small details into account, which we cannot do. Still, we should aim for 5-10 seconds or so.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I confirm the option for light speed correction is checked.
If this information can help (location Thermopilis) : at 17:48 UT Stellarium eclipse factor is 99.709, at 17:40:44 UT the eclipse factor is 91.6011. Maybe there is a wrong parameter in my configuration but I can't find which one.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hehe, it seems really have to do with unhandled light time or dealing properly with aberration. I still don't know how you get to 8 minutes offset. However, I have just added a hackish fix for light time handling for the solar position, and now I am within a few seconds of what NASA says. (trunk r9572 :-)
To compare with above:
NASA: start 17:40:00, end 17:40:53
Stellarium previous result: start 17:40:44, end 17:41:47.
Stellarium r9572: start 17:39:54, end 17:40:53
I can live with that for now.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi
At last, I find why there is a 8 minutes discrepancy : regarding PARI, if I use Stephenson, Morrison & Hohenkerk (2016) algorithm for delta T there is a 8 minutes difference, if I use Morrison & Stephenson (2004, 2005) algorithm I find the correct time. So maybe there is something wrong with the 2016 algorithm. Any idea ?
All the best.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous, there is nothing wrong with the implementation of the SMH2016 algorithm, just in your application outside its valid range. Actually it covers -720...2015, and beyond these years, their approximation parabola is in action, as stated in the DeltaT settings panel.
The authors give their parabolic fit ("good fit overall") in their expression 4.1, and show a comparison of their more accurate spline fit vs. parabola in their fig. 15. For J2000, you can estimate a difference between spline and parabola of somewhere near -250s. I.e., while 2015 has a value near +68s, 2016/17 has around -200s.
--> Don't use this algorithm outside -720..2015.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
They have a collection of data values and present both a classical approximative parabola and a spline formulation to model them. The spline ends in 2015.
Of course we could also implement DeltaT(y>=2016)=DeltaT(y==2015). We did not. If you set this formula for 2017, you get values from the parabola as documented. If we do something else, I feel it's not "an implementation of SMH2016".
Thanks for the graph, but it also stops pretty soon. You can always set some particular value with the custom formula.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Are you using the parabolic formula mentioned by SMH2016 in option (a)?
To make such that the large inaccuracies of (a) are overcome thet porpose option (b): spline for past dates and option (c) smoothing for more recent dates. Of course we don't know what the DeltaT does in the future, but hopefully the smoothing curve in (c) (period 2013-2016) is not that far off for the near future (otherwise one could use the near term prediction from IERS)...
All the best,
Victor
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Maybe we should add another custom solution using an extendable table in the user data directory. But not in 0.16.0.
BTW, my recent corrections "ruined" your Athens eclipse slightly. I don't have the original report. Is it clear where exactly totality would have been observed? Esp, is the current result acceptable compared to other simulations?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
View and moderate all "Feedback" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Hi
Gilmer Allen Gary reported this Bug #1275092 on 2014-01-31: at the location of the Pisgah Astronomical Research Institute (82.8753 W, 35.1986 N) Stellarium does not show a "total" eclipse.
The USNO (U.S. Naval Observatory) provides the following results at PARI : total eclipse, magnitude 1.004, maximum eclipse 18:37:37 UT.
This bug was investigated by Alexander, Georg and Victor Reijs.
Using Stellarium v0.16.0RC1, v0.90.0.9529, the maximum eclipse occurs at 18:45 UT (VSOP87 or DE430): a large 8 minutes discrepancy and the eclipse is not total.
Using Stellarium v0.16.0RC2, v0.90.0.9567, with fix 9554 Improvement of topographic correction, the maximum eclipse still occurs at 18:45 UT (VSOP87 or DE430) without any improvement.
I agree it doesn't seem easy to find the cause of this discrepancy.
All the best
Please select Pisgah Astronomical Research Institute from locations list and check it again.
View and moderate all "Feedback" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
I select PARI in the location list but I get the same results : maximum eclipse 18:45 UT (version Windows 64 bits).
I know the time is off, but only by ONE minute as it had been before, not eight. I compare to the NASA site https://eclipse2017.nasa.gov/sites/default/files/interactive_map/index.html?zoom=1 at
Lat.: 35.1986° N, Long.: 82.8754° W
Still no complete solution. But the duration is better. I am afraid we have two problems mixed here, and disentangling partially legacy code is not easy. Don't hold your breath for a solution built in 0.16.0, but I do hope we will make it before D Day.
Last edit: gzotti 2017-06-18
View and moderate all "Feedback" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Thank you very much for investigating.
Just in case I try with another location : Thermopilis (Wyoming) 43 38 44 N, 108 12 53 W.
USNO result: magnitude 1.001, maximum eclipse 17:40:24 UT.
Fred Espenak NASA result: magnitude 1.000, maximum eclipse 17:40:24
Stellarium result: no total eclipse, maximum eclipse 17:48 UT (same discrepancy 8 minutes).
I wonder why the difference is 8 minutes instead of 1 minute !
Anyway, you have done again a great job with so much improvements regarding version 0.16.
All the best.
Wait! Please check status of the light speed correction option - she is enabled?
I've got around 1 min error for maximum eclipse - how you get 8 minutes of error?
Not sure what you are doing.
NASA: start 17:40:00, end 17:40:53
Stellarium result: start 17:40:44, end 17:41:47.
Again, we are roughly one minute late and somewhat off in duration. Of course, I assume NASA takes moon figure and other small details into account, which we cannot do. Still, we should aim for 5-10 seconds or so.
View and moderate all "Feedback" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
I confirm the option for light speed correction is checked.
If this information can help (location Thermopilis) : at 17:48 UT Stellarium eclipse factor is 99.709, at 17:40:44 UT the eclipse factor is 91.6011. Maybe there is a wrong parameter in my configuration but I can't find which one.
Hehe, it seems really have to do with unhandled light time or dealing properly with aberration. I still don't know how you get to 8 minutes offset. However, I have just added a hackish fix for light time handling for the solar position, and now I am within a few seconds of what NASA says. (trunk r9572 :-)
To compare with above:
NASA: start 17:40:00, end 17:40:53
Stellarium previous result: start 17:40:44, end 17:41:47.
Stellarium r9572: start 17:39:54, end 17:40:53
I can live with that for now.
View and moderate all "Feedback" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Hi
At last, I find why there is a 8 minutes discrepancy : regarding PARI, if I use Stephenson, Morrison & Hohenkerk (2016) algorithm for delta T there is a 8 minutes difference, if I use Morrison & Stephenson (2004, 2005) algorithm I find the correct time. So maybe there is something wrong with the 2016 algorithm. Any idea ?
All the best.
Ouch!
I must check that, thanks for this hint. (I usually work with the default solution. There are so many parameters to mess up things...)
Anonymous, there is nothing wrong with the implementation of the SMH2016 algorithm, just in your application outside its valid range. Actually it covers -720...2015, and beyond these years, their approximation parabola is in action, as stated in the DeltaT settings panel.
The authors give their parabolic fit ("good fit overall") in their expression 4.1, and show a comparison of their more accurate spline fit vs. parabola in their fig. 15. For J2000, you can estimate a difference between spline and parabola of somewhere near -250s. I.e., while 2015 has a value near +68s, 2016/17 has around -200s.
--> Don't use this algorithm outside -720..2015.
View and moderate all "Feedback" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Thank you for your comment : I did'nt notice 2017 was outside the valid range.
Georg, are you sure that SMH2016 does not use DeltaT table? I can't imagine that they would use this (too generic) formula for recent times. I would have thought they used (would allow) something more modern, like this past and pediction graph: http://astro.ukho.gov.uk/nao/miscellanea/DeltaT/dt_current.pdf
or
http://maia.usno.navy.mil/ser7/deltat.data
JPL uses a table for recent dates.
All the best,
Victor
Last edit: VReijs 2017-06-19
They have a collection of data values and present both a classical approximative parabola and a spline formulation to model them. The spline ends in 2015.
Of course we could also implement DeltaT(y>=2016)=DeltaT(y==2015). We did not. If you set this formula for 2017, you get values from the parabola as documented. If we do something else, I feel it's not "an implementation of SMH2016".
Thanks for the graph, but it also stops pretty soon. You can always set some particular value with the custom formula.
Another source (or recent): http://maia.usno.navy.mil/ser7/deltat.data
Although not predictions...
View and moderate all "Feedback" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
My version does not show any eclipse from my location at all.
Possible reasons:
Are you using the parabolic formula mentioned by SMH2016 in option (a)?
To make such that the large inaccuracies of (a) are overcome thet porpose option (b): spline for past dates and option (c) smoothing for more recent dates. Of course we don't know what the DeltaT does in the future, but hopefully the smoothing curve in (c) (period 2013-2016) is not that far off for the near future (otherwise one could use the near term prediction from IERS)...
All the best,
Victor
Maybe we should add another custom solution using an extendable table in the user data directory. But not in 0.16.0.
BTW, my recent corrections "ruined" your Athens eclipse slightly. I don't have the original report. Is it clear where exactly totality would have been observed? Esp, is the current result acceptable compared to other simulations?