Delta T and lunar acceleration

[Victor Reijs]

Hello all of you,

For some reason a full solar eclipse in Athens Greece (Jan 14th, 484 CE around 5:48 UTC while they rise) is not calculated in the same way as several other planetary programs (also using VSOP87/ELP2000:
http://www.iol.ie/~geniet/eng/skyprog.htm#Software )
So I am trying to find out a few things; do people know what Delta T formula (like the newest one of Stephenson, Morrison 2004?) is being used and what lunar acceleration (-25.7 +/- 0.2 "/year^2) has been used?

I get with Stellarium (0.10.4) the max. eclipse around 7:40 UTC (so it is well after rising (2 hours)).

Thanks for the feedback. I am new to Stellarium and can't really yet find my way around the vast amount of info, that is why I ask it in this forum.

All the best,

Victor

[Victor Reijs (appl-victor-reijs)]

It seems that TheSky program has a similar (IMHO not correct) time for the max. eclipse (and uses I think also VSOP87). Is there a relation with code?

[Victor Reijs (appl-victor-reijs)]

I see it is unassigned, is there a way I can help the evaluation of this? I am not a code writer, but I can help debug it. Thanks for the support.

[Victor Reijs (appl-victor-reijs)]

Did some more testing. If looking for Athens at 484 CE, Jan 14th. 06:05:08 GMT (the time of the eclipse in SkyMap). The Sun is quiet close to the location as I see in SkyMap (which uses VSOP87, ELP2000-82B and Stephenson & Houlden (1986)and n-dot =-26 ["/cy2] adapted to ELP2000). Stellarium is using the same ephemeris (but I don't know about the n-dot and DeltaT) .The Moon in Stellarium is at a different location then in SkyMap, so I think that the lunar position is not correctly calculated in Stellarium.
Hope this helps in debugging Stellarium.

[Victor Reijs (appl-victor-reijs)]

Just calculated the the difference with other programs (like SkyMap, JPL, CyberSky, etc.):
. in the mentioned programs the Sun at 6:05:08 UTC is at around azimuth 119deg 57' 34"
. the moon in Stellarium is at that same locations when it is around 6:01:06 UTC.
. so a time difference of 242 seconds
. the n-dot is in this case thus different from SkyMaps's:
n-dot difference = 242/(((1950-484)/100)^2) = 1.1"

So it looks the n-dot in Stellarium is taken to be 26-1.1= 24.9"/cy^2

Let me know your thoughts?

[Victor Reijs (appl-victor-reijs)]

Sorry I, should have added the 1.1 to 26, so in Stellarium is is closer to 27.1"/cy^2.

[Dave Chapman (dave-chapman)]

Voyager III for Mac gives max eclipse at 0556 UT that day. Sun at azimuth 118.5 degrees.

[Victor Reijs (appl-victor-reijs)]

05:56 UTC is indeed about correct (I woukd accept a certain range of times, due to uncertainty of Delta T, see http://www.iol.ie/~geniet/eng/skyprog.htm#Software ), but for Stellarium it is indeed quite out.

[gzotti (georg-zotti)]

Unfortunately, Stellarium currently has no notion of DeltaT in the astronomical sense, so it cannot be used for historical eclipse simulation. It is a wishlist topic.

I don't know about the lunar acceleration value.

Regards,
Georg

[Victor Reijs (appl-victor-reijs)]

If someone needs help to implement this, let me know. All the best,

Victor

[Victor Reijs (appl-victor-reijs)]

Is it possible to work on this? I am willing to help with testing (my programming capabilities are not existing, but testing I can do). It would be great if I can advice this program fro archaeoastronomy work. Thanks for reconsidering this.

[Alexander Wolf (alexwolf)]

DeltaT still not applied to calculations. :(

[Victor Reijs (appl-victor-reijs)]

By the way the time is 7:35 local time (and is still 2 hours after Sun rise), while this eclipse should be around sun rise. By the way how do I minimize the Stellarium window, so I can send an e-mail ill still looking at Stellarium (I seem not to be able to find it, I am using 0.11.4) Thanks for your feedback.

[Victor Reijs (appl-victor-reijs)]

Sorry I found the F11 buttom...
But the 2 hour difference is still there;-)

[Victor Reijs (appl-victor-reijs)]

Hello Alexander or others,

On 1 January 2013 12:55, Alexander Wolf <email address hidden> wrote:

> DeltaT still not applied to calculations. :(
>

This link provide some info (
http://eclipse.gsfc.nasa.gov/SEcat5/deltatpoly.html ), but I can also
provide more general info if someone wants to pick this up.

All the best,

Victor

[Allan Johnson (snofriacus)]

Hi Victor,

I too am very interested in seeing this implemented. I've been using
Stellarium to research astronomical events in the range of about 700BC
to 100AD. It seems to give good results -if- you remember to manually
correct the times with NASA's estimated Delta-T value for the year in
question. But with manual corrections it's easy to get confused about
which details are in need of correction, and what needs to be
subtracted from what. What I really need is for the software to be able
to automate these corrections. I've looked for other open-source
software that might be able to give me what I need, and so far haven't
found anything suitable. The Starry Night program (not open source) does
incorporate Delta T into its calculations. When the Delta T correction
is implemented in Stellarium, one helpful test would be to compare
results for a number of dates with the results from Starry Night.

Allan

On 1/1/2013 7:43 AM, Victor Reijs wrote:
> Is it possible to work on this? I am willing to help with testing (my
> programming capabilities are not existing, but testing I can do). It
> would be great if I can advice this program fro archaeoastronomy work.
> Thanks for reconsidering this.
>

[Victor Reijs (appl-victor-reijs)]

Hello Allan,

Thanks for your support.

I also hope it will be implemented (I think my original request was a few
years ago;-). Perhaps you should also react to my bug report (in support).

Most programs have DeltaT incorporated (although there are many 'old'
formula for DeltaT). I myself use one that I derived myself form latest
Stephenson:
http://www.iol.ie/~geniet/eng/DeltaTeval.htm

See also my ideas on benchmarking and an overview of programs that work
properly (or not):
http://www.iol.ie/~geniet/eng/skyprog.htm#Software

All the best in 2013,

Victor

On 2 January 2013 15:43, Allan Johnson <email address hidden> wrote:

> Hi Victor,
>
> I too am very interested in seeing this implemented. I've been using
> Stellarium to research astronomical events in the range of about 700BC
> to 100AD. It seems to give good results -if- you remember to manually
> correct the times with NASA's estimated Delta-T value for the year in
> question. But with manual corrections it's easy to get confused about
> which details are in need of correction, and what needs to be
> subtracted from what. What I really need is for the software to be able
> to automate these corrections. I've looked for other open-source
> software that might be able to give me what I need, and so far haven't
> found anything suitable. The Starry Night program (not open source) does
> incorporate Delta T into its calculations. When the Delta T correction
> is implemented in Stellarium, one helpful test would be to compare
> results for a number of dates with the results from Starry Night.
>
> Allan
>
>
> On 1/1/2013 7:43 AM, Victor Reijs wrote:
> > Is it possible to work on this? I am willing to help with testing (my
> > programming capabilities are not existing, but testing I can do). It
> > would be great if I can advice this program fro archaeoastronomy work.
> > Thanks for reconsidering this.
> >
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/575621
>
> Title:
> Delta T and lunar acceleration
>
> Status in Stellarium:
> Opinion
>
> Bug description:
> Hello all of you,
>
> For some reason a full solar eclipse in Athens Greece (Jan 14th, 484 CE
> around 5:48 UTC while they rise) is not calculated in the same way as
> several other planetary programs (also using VSOP87/ELP2000:
> http://www.iol.ie/~geniet/eng/skyprog.htm#Software )
> So I am trying to find out a few things; do people know what Delta T
> formula (like the newest one of Stephenson, Morrison 2004?) is being used
> and what lunar acceleration (-25.7 +/- 0.2 "/year^2) has been used?
>
> I get with Stellarium (0.10.4) the max. eclipse around 7:40 UTC (so it
> is well after rising (2 hours)).
>
> Thanks for the feedback. I am new to Stellarium and can't really yet
> find my way around the vast amount of info, that is why I ask it in
> this forum.
>
> All the best,
>
> Victor
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/stellarium/+bug/575621/+subscriptions
>

[Allan Johnson (snofriacus)]

Hi Victor,

Thanks for the link to the list of astronomy programs. I stumbled across
that list once before, maybe a month ago, and it led me to look into
what JPL Ephemeris could do for me. I was disappointed that it didn't
allow me to do what I needed - to examine conjunctions between planets
back in the BC time frame. For the Sun, moon, Mercury, and Venus, it
went back plenty far for my purposes, to 3001BC. But the other planets
were quite limited -

Mars: no ephemeris before 1900
Jupiter: no ephemeris before 1600
Saturn: no ephemeris before 1800
Uranus: no ephemeris before 1900
Neptune: no ephemeris before 1799
Pluto: no ephemeris before 1899

I doubt that this is a technical limitation. They have what they would
need to make at least the best possible guesses on positions of the
planets in the distant past. But for some reason they've chosen to limit
access to this info. Maybe because they can't guarantee accuracy that
far back? But if that were the reason I think they'd be showing more
confidence in Jupiter and Saturn's positions, and less confidence in the
moon's position. So I don't know what the rationale is.

I first ran into this barrier when using the JPL Horizons web interface.
Then I read something about the telnet interface providing the fullest
access, so tried that too. But the barrier was still there. Do you know
of any way to gain full access to JPL Ephemeris data on the positions of
the planets?

I imagine I am getting roughly this same info on planet position when I
use Stellarium for the distant past. But it would be nice to have a
second opinion. And if the JPL ephemeris data accounts for Delta T, that
would be a good check on the manual Delta T corrections that I have to
make with Stellarium.

I was also hoping to devise a way to let the JPL ephemeris data show me
where to look for the closest conjunctions between planets. There's
probably software already in existence somewhere that will do this, but
I haven't found it yet. Are you aware of any software that offers a
function for finding the next conjunction between two selected planets?

Allan

On 1/2/2013 11:53 AM, Victor Reijs wrote:
> Hello Allan,
>
> Thanks for your support.
>
> I also hope it will be implemented (I think my original request was a few
> years ago;-). Perhaps you should also react to my bug report (in support).
>
> Most programs have DeltaT incorporated (although there are many 'old'
> formula for DeltaT). I myself use one that I derived myself form latest
> Stephenson:
> http://www.iol.ie/~geniet/eng/DeltaTeval.htm
>
> See also my ideas on benchmarking and an overview of programs that work
> properly (or not):
> http://www.iol.ie/~geniet/eng/skyprog.htm#Software
>
> All the best in 2013,
>
> Victor
>
>
> On 2 January 2013 15:43, Allan Johnson <email address hidden> wrote:
>
>> Hi Victor,
>>
>> I too am very interested in seeing this implemented. I've been using
>> Stellarium to research astronomical events in the range of about 700BC
>> to 100AD. It seems to give good results -if- you remember to manually
>> correct the times with NASA's estimated Delta-T value for the year in
>> question. But with manual corrections...

[Victor Reijs (appl-victor-reijs)]

Hello Allan,

I did not know that JPL had that restriction.
I use Swiss Ephemeris for my work. I have it integrated in Excel using
Add-In.
http://www.iol.ie/~geniet/eng/archaeocosmoprocedures.htm

I am sure one could program in Excel conjunctions...

On 2 January 2013 22:47, Allan Johnson <email address hidden> wrote:

> Mars: no ephemeris before 1900
> Jupiter: no ephemeris before 1600
> Saturn: no ephemeris before 1800
> Uranus: no ephemeris before 1900
> Neptune: no ephemeris before 1799
> Pluto: no ephemeris before 1899
> ...
> So I don't know what the rationale is.
>

You could ask JPl Horizons for their reasoning...

All the best,

Victor

[Allan Johnson (snofriacus)]

Thanks! This looks very useful. I'll start looking it over.

Allan

On 1/2/2013 6:39 PM, Victor Reijs wrote:
> Hello Allan,
>
> I did not know that JPL had that restriction.
> I use Swiss Ephemeris for my work. I have it integrated in Excel using
> Add-In.
> http://www.iol.ie/~geniet/eng/archaeocosmoprocedures.htm
>
> I am sure one could program in Excel conjunctions...
>
> On 2 January 2013 22:47, Allan Johnson <email address hidden>
> wrote:
>
>> Mars: no ephemeris before 1900
>> Jupiter: no ephemeris before 1600
>> Saturn: no ephemeris before 1800
>> Uranus: no ephemeris before 1900
>> Neptune: no ephemeris before 1799
>> Pluto: no ephemeris before 1899
>> ...
>> So I don't know what the rationale is.
>>
> You could ask JPl Horizons for their reasoning...
>
> All the best,
>
>
> Victor
>

[Alexander Wolf (alexwolf)]

Please build this branch: https://code.launchpad.net/~stellarium/stellarium/delta_t (lp:~stellarium/stellarium/delta_t) and check correct apply Delta T to computation of positions.

[Victor Reijs (appl-victor-reijs)]

Oops, how do I make a build? I am not used to this... Thanks for the help and working on this!
All the best,
Victor

[Alexander Wolf (alexwolf)]

You need read our wiki for get instructions for building Stellarium (I'm broke my Windows building environment :( )

[Allan Johnson (snofriacus)]

Great! I'll look into this too, and see if I can build and test it.

[Victor Reijs (appl-victor-reijs)]

I don;t have the option to build on my system (also no real experience). If someone can build it Then the test to do is the Athens' eclipse of 14 Jan 484 CE (at sun rise around 5.48 UT). Thanks!

[Victor Reijs (appl-victor-reijs)]

This is the wiki page for making a build: http://www.stellarium.org/wiki/index.php/Windows_Build_Instructions

[Allan Johnson (snofriacus)]

Ok, I got it to build. But I'm not seeing any Delta T effect. Not
entirely sure of my build process. I first built the main Stellarium
project, and then built the delta_t branch. I -think- I built the
delta_t branch, but that's what I'm not sure about. Within Qt, it looks
just the same as the main Stellarium project. I'll retry with another
approach later today, downloading only the delta_t branch this time to
avoid confusion.

What I'm seeing on the Athens eclipse:
 From city "Athínai", using time zone 0, date 484/1/14, I'm seeing the
sun most fully eclipsed about 7:38am. I'm not getting a total eclipse
from here. Should it be total from this location? When the Delta T
correction is working, will it affect the completeness of the eclipse
from Athens? Or just the timing of it?

I do get a total eclipse from the city of "Yerushalayim". This allows me
to compare things with more precision. Still using time zone 0, I see
the last sunlight disappear from the left edge of the moon at 7:47:25,
and the first sunlight reappear on the right edge at 7:50:16. This is
-exactly- what I see in Stellarium 0.11.4 on my other computer, with no
Delta T correction.

So it's clear that I'm not yet seeing any Delta T. I'll do another build
and recheck, to see if this might possibly be due to errors on my end.

Allan

[Alexander Wolf (alexwolf)]

I think I'm apply Delta T is wrong :-/

[Victor Reijs (appl-victor-reijs)]

Allan, just to be sure: The eclipse at Athens is sometimes reported by computer programs as full and in some other cases not (see also my web page where sometimes the fullness is mentioned: http://www.iol.ie/~geniet/eng/skyprog.htm#Evaluation ). In the historic text it looks reads as a full eclipse during sunrise...

The DeltaT has influence in where fullness is visible (DeltaT is equivalent with a change in longitude). So if one sees in Stellarium (not full) might be more full when the DeltaT is properly calculated. I think it is wise to first see what the DeltaT does and if there is still something left, lets evaluate that.
By the way DeltaT= TT (or ET) -UT (and around 484 CE DeltaT is around 80 min).

Thanks for all your work.

[Victor Reijs (appl-victor-reijs)]

By the way, the n.dot of the moon is also important. The DeltaT formula only work for a certain n.dot, with another n.dot one needs to adjust the DeltaT. (see my feedback #4).

[Allan Johnson (snofriacus)]

Ok, I redid the build, and still the Delta T isn't showing up. Under "Run configuration" the default value is just "stellarium", but there are also several test configurations, one of which sounds relevant, called "testDeltaT". I tried selecting that for a test run, but it didn't do anything. I have to confess that I'm new to building with Qt, so could still be missing something, but probably it's just what Alexander said, that something in the Delta T programming just isn't working yet.

[Victor Reijs (appl-victor-reijs)]

Thanks Allan for trying, lets hope Alexander can bring clarity in the sky;-)

[Allan Johnson (snofriacus)]

Hi guys - the build environment that I set up gives me the ability to poke around in the Stellarium code and experiment with things. The Delta T calculations at the end of StelUtils.cpp look like they're probably fine, but I think our issue is figuring out where exactly the calculation needs to be linked into the rest of the code. The place it's currently being applied which doesn't seem to be working is "computePositions(JD + StelUtils::getDeltaT(JD))", occuring twice in SolarSystem.cpp.

I don't understand the code well enough to suggest where else to try, but I'm thinking about what Victor said, that "DeltaT is equivalent with a change in longitude". This is consistent with my understanding of Delta T, that it's all about variation over time in the speed of earth's rotation. So it seems that the adjustment needs to be made in a place that won't affect the positions of any of the Solar System bodies, but just change the apparent position (longitude) of the observer on the surface of the earth.

[Victor Reijs (appl-victor-reijs)]

Hello Allan,

On 8 January 2013 13:11, Allan Johnson <email address hidden> wrote:

> I don't understand the code well enough to suggest where else to try,
> but I'm thinking about what Victor said, that "DeltaT is equivalent with
> a change in longitude". This is consistent with my understanding of
> Delta T, that it's all about variation over time in the speed of earth's
> rotation.

At the end DeltaT can be seen in the longitude of where the eclipse will
happen, but DeltaT should only work on the time used in the ephemeris
DeltaT=ET-UT (and the longitude effect is then the reuslt of that)
 Say that ET is used in the formula and this one can then output the UT...

A small point. The DeltaT formula is defined for a certain lunar
acceleration (n.dot, I think it is 26, but that need to be checked) if that
is different in Stellarium, one needs to compensate also for that (I
touched on this in remark 4 and 5).

All the best,

Victor

[R catchpole (catchpol)]

The attached slide may help to check that what you do is correct. I
made the slide, but the important diagram lower right, is from an
article in Astronomy and Geophysics, some years ago (like10) written by
Stephenson Morrsion, who's work is probably what you are using
Best wishes
Robin Catchpole

On Tue, 08 Jan 2013 12:17:16 -0000, Alexander Wolf wrote:
> ** Changed in: stellarium
> Status: Triaged => In Progress
>
> --
> You received this bug notification because you are subscribed to the
> bug
> report.
> https://bugs.launchpad.net/bugs/575621
>
> Title:
> Delta T and lunar acceleration
>
> Status in Stellarium:
> In Progress
>
> Bug description:
> Hello all of you,
>
> For some reason a full solar eclipse in Athens Greece (Jan 14th,
> 484 CE around 5:48 UTC while they rise) is not calculated in the same
> way as several other planetary programs (also using VSOP87/ELP2000:
> http://www.iol.ie/~geniet/eng/skyprog.htm#Software )
> So I am trying to find out a few things; do people know what Delta
> T formula (like the newest one of Stephenson, Morrison 2004?) is
> being
> used and what lunar acceleration (-25.7 +/- 0.2 "/year^2) has been
> used?
>
> I get with Stellarium (0.10.4) the max. eclipse around 7:40 UTC (so
> it
> is well after rising (2 hours)).
>
> Thanks for the feedback. I am new to Stellarium and can't really
> yet
> find my way around the vast amount of info, that is why I ask it in
> this forum.
>
> All the best,
>
> Victor
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/stellarium/+bug/575621/+subscriptions

[Victor Reijs (appl-victor-reijs)]

Hello Robin,

Your data can also be used indeed (it lays further in the distance so that
is better):
http://eclipse.gsfc.nasa.gov/SEsearch/SEsearchmap.php?Ecl=-01350415

I used this historic event: http://www.iol.ie/~geniet/eng/skyprog.htm#484
for many software programs, but perhaps I should change to this 136 BCE
date.

I am using the latest Stepheson and Morrison [2004] DeltaT formula:
http://www.iol.ie/~geniet/eng/skyprog.htm#dT

All the best,

Victor

On 9 January 2013 09:47, R catchpole <email address hidden> wrote:

> The attached slide may help to check that what you do is correct. I
> made the slide, but the important diagram lower right, is from an
> article in Astronomy and Geophysics, some years ago (like10) written by
> Stephenson Morrsion, who's work is probably what you are using
> Best wishes
> Robin Catchpole
>
> On Tue, 08 Jan 2013 12:17:16 -0000, Alexander Wolf wrote:
> > ** Changed in: stellarium
> > Status: Triaged => In Progress
> >
> > --
> > You received this bug notification because you are subscribed to the
> > bug
> > report.
> > https://bugs.launchpad.net/bugs/575621
> >
> > Title:
> > Delta T and lunar acceleration
> >
> > Status in Stellarium:
> > In Progress
> >
> > Bug description:
> > Hello all of you,
> >
> > For some reason a full solar eclipse in Athens Greece (Jan 14th,
> > 484 CE around 5:48 UTC while they rise) is not calculated in the same
> > way as several other planetary programs (also using VSOP87/ELP2000:
> > http://www.iol.ie/~geniet/eng/skyprog.htm#Software )
> > So I am trying to find out a few things; do people know what Delta
> > T formula (like the newest one of Stephenson, Morrison 2004?) is
> > being
> > used and what lunar acceleration (-25.7 +/- 0.2 "/year^2) has been
> > used?
> >
> > I get with Stellarium (0.10.4) the max. eclipse around 7:40 UTC (so
> > it
> > is well after rising (2 hours)).
> >
> > Thanks for the feedback. I am new to Stellarium and can't really
> > yet
> > find my way around the vast amount of info, that is why I ask it in
> > this forum.
> >
> > All the best,
> >
> > Victor
> >
> > To manage notifications about this bug go to:
> > https://bugs.launchpad.net/stellarium/+bug/575621/+subscriptions
>
>
> ** Attachment added: "Solareclipse.png"
>
> https://bugs.launchpad.net/bugs/575621/+attachment/3477803/+files/Solareclipse.png
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/575621
>
> Title:
> Delta T and lunar acceleration
>
> Status in Stellarium:
> In Progress
>
> Bug description:
> Hello all of you,
>
> For some reason a full solar eclipse in Athens Greece (Jan 14th, 484 CE
> around 5:48 UTC while they rise) is not calculated in the same way as
> several other planetary programs (also using VSOP87/ELP2000:
> http://www.iol.ie/~geniet/eng/skyprog.htm#Software )
> So I am trying to find out a few things; do people know what Delta T
> formula (like the newest one of Stephenson, Morrison 2004?) is being used
> and what lunar acceleration (-25.7 +/- 0.2 "/year^2) has been used?
>
> I get with Stellarium (0.10.4) the max. eclipse around 7:...

[R catchpole (catchpol)]

Dear Victor,

It might be worth looking at the paper which I see is by Stephenson and
is a lecture, published in Astronomy and Geophysics vol 44 in April
2003. If I was in my office I could see the whole paper but not from
home. From the paper you will see how the eclipse I sent you matches a
mean delta T fit, which, I am sure he also gives in the paper. At least
it helps you get the Del longitude the right way around.

I have not thought about this deeply but the correction should probably
be treated a bit like precession, where the frame of reference on earth
changes with time with respect to everything else. I guess just changing
the longitude of the observer with time should do it without risking
wrecking some other function. ie if you had chosen the longitude of
babylon as your starting point today by then it would have moved west to
Cadiz if a uniform earth rotation was assumed. I was wondering if
latitude also changed as we know the Earth's rotation axis does migrate
but only by 10s of meters!

Best wishes
Robin

On Wed, 09 Jan 2013 10:49:00 -0000, Victor Reijs wrote:
> Hello Robin,
>
> Your data can also be used indeed (it lays further in the distance so
> that
> is better):
> http://eclipse.gsfc.nasa.gov/SEsearch/SEsearchmap.php?Ecl=-01350415
>
> I used this historic event:
> http://www.iol.ie/~geniet/eng/skyprog.htm#484
> for many software programs, but perhaps I should change to this 136
> BCE
> date.
>
> I am using the latest Stepheson and Morrison [2004] DeltaT formula:
> http://www.iol.ie/~geniet/eng/skyprog.htm#dT
>
>
> All the best,
>
>
> Victor
>
>
> On 9 January 2013 09:47, R catchpole <email address hidden>
> wrote:
>
>> The attached slide may help to check that what you do is correct. I
>> made the slide, but the important diagram lower right, is from an
>> article in Astronomy and Geophysics, some years ago (like10) written
>> by
>> Stephenson Morrsion, who's work is probably what you are using
>> Best wishes
>> Robin Catchpole
>>
>> On Tue, 08 Jan 2013 12:17:16 -0000, Alexander Wolf wrote:
>> > ** Changed in: stellarium
>> > Status: Triaged => In Progress
>> >
>> > --
>> > You received this bug notification because you are subscribed to
>> the
>> > bug
>> > report.
>> > https://bugs.launchpad.net/bugs/575621
>> >
>> > Title:
>> > Delta T and lunar acceleration
>> >
>> > Status in Stellarium:
>> > In Progress
>> >
>> > Bug description:
>> > Hello all of you,
>> >
>> > For some reason a full solar eclipse in Athens Greece (Jan 14th,
>> > 484 CE around 5:48 UTC while they rise) is not calculated in the
>> same
>> > way as several other planetary programs (also using
>> VSOP87/ELP2000:
>> > http://www.iol.ie/~geniet/eng/skyprog.htm#Software )
>> > So I am trying to find out a few things; do people know what
>> Delta
>> > T formula (like the newest one of Stephenson, Morrison 2004?) is
>> > being
>> > used and what lunar acceleration (-25.7 +/- 0.2 "/year^2) has been
>> > used?
>> >
>> > I get with Stellarium (0.10.4) the max. eclipse around 7:40 UTC
>> (so
>> > it
>> > is well after rising (2 hours)).
>> >
>> > Thanks for the feedback. I am new to Stellarium and can't real...

[Victor Reijs (appl-victor-reijs)]

Hello Robin,

Don't do things indirectly, it is very simple just change the time:
DelatT+ET-UT (that at the end will result in some change in longitude, but
it is indeed a little more ellobarate, it is not only longitude).
So change the time (as that is also the definition fo DetaT).

All the best,

Victor

On 9 January 2013 12:54, R catchpole <email address hidden> wrote:

> Dear Victor,
>
> It might be worth looking at the paper which I see is by Stephenson and
> is a lecture, published in Astronomy and Geophysics vol 44 in April
> 2003. If I was in my office I could see the whole paper but not from
> home. From the paper you will see how the eclipse I sent you matches a
> mean delta T fit, which, I am sure he also gives in the paper. At least
> it helps you get the Del longitude the right way around.
>
> I have not thought about this deeply but the correction should probably
> be treated a bit like precession, where the frame of reference on earth
> changes with time with respect to everything else. I guess just changing
> the longitude of the observer with time should do it without risking
> wrecking some other function. ie if you had chosen the longitude of
> babylon as your starting point today by then it would have moved west to
> Cadiz if a uniform earth rotation was assumed. I was wondering if
> latitude also changed as we know the Earth's rotation axis does migrate
> but only by 10s of meters!
>
> Best wishes
> Robin
>
> On Wed, 09 Jan 2013 10:49:00 -0000, Victor Reijs wrote:
> > Hello Robin,
> >
> > Your data can also be used indeed (it lays further in the distance so
> > that
> > is better):
> > http://eclipse.gsfc.nasa.gov/SEsearch/SEsearchmap.php?Ecl=-01350415
> >
> > I used this historic event:
> > http://www.iol.ie/~geniet/eng/skyprog.htm#484
> > for many software programs, but perhaps I should change to this 136
> > BCE
> > date.
> >
> > I am using the latest Stepheson and Morrison [2004] DeltaT formula:
> > http://www.iol.ie/~geniet/eng/skyprog.htm#dT
> >
> >
> > All the best,
> >
> >
> > Victor
> >
> >
> > On 9 January 2013 09:47, R catchpole <email address hidden>
> > wrote:
> >
> >> The attached slide may help to check that what you do is correct. I
> >> made the slide, but the important diagram lower right, is from an
> >> article in Astronomy and Geophysics, some years ago (like10) written
> >> by
> >> Stephenson Morrsion, who's work is probably what you are using
> >> Best wishes
> >> Robin Catchpole
> >>
> >> On Tue, 08 Jan 2013 12:17:16 -0000, Alexander Wolf wrote:
> >> > ** Changed in: stellarium
> >> > Status: Triaged => In Progress
> >> >
> >> > --
> >> > You received this bug notification because you are subscribed to
> >> the
> >> > bug
> >> > report.
> >> > https://bugs.launchpad.net/bugs/575621
> >> >
> >> > Title:
> >> > Delta T and lunar acceleration
> >> >
> >> > Status in Stellarium:
> >> > In Progress
> >> >
> >> > Bug description:
> >> > Hello all of you,
> >> >
> >> > For some reason a full solar eclipse in Athens Greece (Jan 14th,
> >> > 484 CE around 5:48 UTC while they rise) is not calculated in the
> >> same
> >> > way as several other planetary programs (also using
> >> VS...

[R catchpole (catchpol)]

Dear Victor,
You will have thought about this a lot more than I have. But it seems to
me that all planetary phenomena will be calculated in uniform ET. So at a
time ET1, which describes some astronomical event like a conjunction,
delta T (ET1) describes how the orientation of the Earth differs from its
value at ET1 if it had been calculated using a uniform rotation.

When it comes to the Moon I imagine today the ephemeris also uses ET as
the arguement.

The solar system runs on uniform ET, leaving the Earth's period of axial
rotation to increase, while the moon moves away from us and its orbital
period arround us also increases but not as fast as the Earth's. So the
moon appears to accelerate.

I am no expert on all this so dont worry, I expect we are saying the same
thing but in differnt ways.

Best wishes
Robin

----------------------------------------------------------------------------
Robin Catchpole (Dr)

Phone [phone] (Cambridge) Institute of Astronomy
SwitcB 01223 337 548 (Cambridge) Madingley Road
                                              CAMBRIDGE CB3 OHA
mobile [phone] (cellnet) U.K.

email <email address hidden>
web http://www.ast.cam.ac.uk/~catchpol/
----------------------------------------------------------------------------

On Wed, 9 Jan 2013, Victor Reijs wrote:

> Hello Robin,
>
> Don't do things indirectly, it is very simple just change the time:
> DelatT+ET-UT (that at the end will result in some change in longitude, but
> it is indeed a little more ellobarate, it is not only longitude).
> So change the time (as that is also the definition fo DetaT).
>
> All the best,
>
>
> Victor
>
> On 9 January 2013 12:54, R catchpole <email address hidden> wrote:
>
>> Dear Victor,
>>
>> It might be worth looking at the paper which I see is by Stephenson and
>> is a lecture, published in Astronomy and Geophysics vol 44 in April
>> 2003. If I was in my office I could see the whole paper but not from
>> home. From the paper you will see how the eclipse I sent you matches a
>> mean delta T fit, which, I am sure he also gives in the paper. At least
>> it helps you get the Del longitude the right way around.
>>
>> I have not thought about this deeply but the correction should probably
>> be treated a bit like precession, where the frame of reference on earth
>> changes with time with respect to everything else. I guess just changing
>> the longitude of the observer with time should do it without risking
>> wrecking some other function. ie if you had chosen the longitude of
>> babylon as your starting point today by then it would have moved west to
>> Cadiz if a uniform earth rotation was assumed. I was wondering if
>> latitude also changed as we know the Earth's rotation axis does migrate
>> but only by 10s of meters!
>>
>> Best wishes
>> Robin
>>
>> On Wed, 09 Jan 2013 10:49:00 -0000, Victor Reijs wrote:
>>> Hello Robin,
>>>
>>> Your data can also be used indeed (it lays further in the distance so
>>> that
>>> is better):
>>> http://eclipse.gsfc.nasa.gov/SEsearch/SEsearchmap.php?Ecl=-01350415
>>>
>>> I used this historic event:
>>> http://www.iol.ie/~geniet/eng/skypr...

[Victor Reijs (appl-victor-reijs)]

Hello Robin,

On 9 January 2013 15:32, R catchpole <email address hidden> wrote:

> I am no expert on all this so dont worry, I expect we are saying the same
> thing but in differnt ways.
>

Indeed it is similar, as we are now both talking about time (and not
longitude). The DeltaT formula is by the way defined for a certain lunar
accentuation (n.dot). For Stephexon|&Morrison this is -26 "/cy2). If the
ephemeris of the Moon used in Stellarium has a different n.dot, one also
needs to compensate for that in changing tthe DeltaT slightly:
http://eclipse.gsfc.nasa.gov/SEcat5/secular.html

All the best,

Victor

[Victor Reijs (appl-victor-reijs)]

Hello Alexander,

Can I help in some way? Let me know.

All the best,

Victor

On 8 January 2013 12:17, Alexander Wolf <email address hidden> wrote:

> ** Changed in: stellarium
> Status: Triaged => In Progress
>

[Alexander Wolf (alexwolf)]

Thanks for feedback, I'm apply your patch at revision 5775 (http://bazaar.launchpad.net/~stellarium/stellarium/trunk/revision/5775) + I set limit using DeltaT only for Earth at revision 5774 (http://bazaar.launchpad.net/~stellarium/stellarium/trunk/revision/5774)

[Allan Johnson (snofriacus)]

Ok, thanks. Did these changes make it into the RC3 version? If so I'll
check it out and see how the dates before -500 are looking now.

Allan

On 1/28/2013 12:09 AM, Alexander Wolf wrote:
> Thanks for feedback, I'm apply your patch at revision 5775
> (http://bazaar.launchpad.net/~stellarium/stellarium/trunk/revision/5775)
> + I set limit using DeltaT only for Earth at revision 5774
> (http://bazaar.launchpad.net/~stellarium/stellarium/trunk/revision/5774)
>

[Alexander Wolf (alexwolf)]

Sorry, no, those changes not included in RC3 - you need build Stellarium from source code for testing.

[Allan Johnson (snofriacus)]

Ok, I built and ran it, and it looks good now. I'm now seeing no
discontinuity in DeltaT values before and after the year -500.

I like the DeltaT display. I didn't see it at first, but it shows up
when I hover the mouse over the time and date on the bottom bar.

One other check I did was for an exceptionally close conjunction of
Venus with Jupiter in -553, and I'm seeing results that are fairly close
to what Solex gives me. For Latitude -105d, Longitude -47d, elevation
0m, Date -553/01/27, Solex is showing the closest conjunction of Venus
with Jupiter at 18:03 UT, and Stellarium at 18:01 UT.

[Alexander Wolf (alexwolf)]

Thanks for feedback, Allan!

Allan and Victor, I hope you can help us with next task for DeltaT computations - maybe you have articles with equations for DeltaT? I think (and Georg agreed IMHO) that we can give users choose from few different algorithms for DeltaT computation ( https://bugs.launchpad.net/stellarium/+bug/1106658 ). I hope this feature can be very usable for archaeoastronomers.

[Victor Reijs (appl-victor-reijs)]

Allan, Can I download somewhere a windowsexecutable? I really hop to try
also. Thanks.

All the best,

Victor

On 28 January 2013 17:48, Allan Johnson <email address hidden> wrote:

> Ok, I built and ran it, and it looks good now. I'm now seeing no
> discontinuity in DeltaT values before and after the year -500.
>

[Allan Johnson (snofriacus)]

Ok, I'm attaching a copy of the installer I built this morning. I've called it "postRC3". It seems that I've gotten my build process adjusted now to where the resulting installer works without need for the additional hand-copying of dll's that I reported earlier. It's over twice the size of the official installers, but it does seem to work. It's about 160MB.

I imagine there will soon be another official RC version that will supersede this, but this should give you something you can test today.

You won't see the attachment on the email note. Just click the link to go to the online launchpad bug site, bug number 575621, and you should be able to download the attachment from there.

[Victor Reijs (appl-victor-reijs)]

Thanks Allan, I am now downloading it. You did a great job in helping to
make this available. Will do some testing when the download is finished
(will take some time).

THANKS.

All the best,

Victor

On 28 January 2013 19:27, Allan Johnson <email address hidden> wrote:

> Ok, I'm attaching a copy of the installer I built this morning. I've
> called it "postRC3". It seems that I've gotten my build process adjusted
> now to where the resulting installer works without need for the
> additional hand-copying of dll's that I reported earlier. It's over
> twice the size of the official installers, but it does seem to work.
> It's about 160MB.
>
> I imagine there will soon be another official RC version that will
> supersede this, but this should give you something you can test today.
>
> You won't see the attachment on the email note. Just click the link to
> go to the online launchpad bug site, bug number 575621, and you should
> be able to download the attachment from there.
>
>
> ** Attachment added: "stellarium-0.12.0-postRC3-win32.exe"
>
> https://bugs.launchpad.net/stellarium/+bug/575621/+attachment/3504744/+files/stellarium-0.12.0-postRC3-win32.exe
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/575621
>
> Title:
> Delta T and lunar acceleration
>
> Status in Stellarium:
> Fix Committed
>
> Bug description:
> Hello all of you,
>
> For some reason a full solar eclipse in Athens Greece (Jan 14th, 484 CE
> around 5:48 UTC while they rise) is not calculated in the same way as
> several other planetary programs (also using VSOP87/ELP2000:
> http://www.iol.ie/~geniet/eng/skyprog.htm#Software )
> So I am trying to find out a few things; do people know what Delta T
> formula (like the newest one of Stephenson, Morrison 2004?) is being used
> and what lunar acceleration (-25.7 +/- 0.2 "/year^2) has been used?
>
> I get with Stellarium (0.10.4) the max. eclipse around 7:40 UTC (so it
> is well after rising (2 hours)).
>
> Thanks for the feedback. I am new to Stellarium and can't really yet
> find my way around the vast amount of info, that is why I ask it in
> this forum.
>
> All the best,
>
> Victor
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/stellarium/+bug/575621/+subscriptions
>

[Victor Reijs (appl-victor-reijs)]

Hello Allan,

Just tried indeed Athens (484CE) and I also see 05:38 UT (so within the
error range I have). Which DeltaT formula was used at the end
(Stephenson&Morrison 2004)?

The -135 April 15 at 6:09 UT (Babylon) can also be recreated (although it
is not a full eclipse, but almost).

All the best,

Victor

On 28 January 2013 20:06, Victor Reijs <email address hidden> wrote:

> Thanks Allan, I am now downloading it. You did a great job in helping to
> make this available. Will do some testing when the download is finished
> (will take some time).
>
> THANKS.
>
> All the best,
>
> Victor
>
>
> On 28 January 2013 19:27, Allan Johnson <email address hidden> wrote:
>
>> Ok, I'm attaching a copy of the installer I built this morning. I've
>> called it "postRC3". It seems that I've gotten my build process adjusted
>> now to where the resulting installer works without need for the
>> additional hand-copying of dll's that I reported earlier. It's over
>> twice the size of the official installers, but it does seem to work.
>> It's about 160MB.
>>
>> I imagine there will soon be another official RC version that will
>> supersede this, but this should give you something you can test today.
>>
>> You won't see the attachment on the email note. Just click the link to
>> go to the online launchpad bug site, bug number 575621, and you should
>> be able to download the attachment from there.
>>
>>
>> ** Attachment added: "stellarium-0.12.0-postRC3-win32.exe"
>>
>> https://bugs.launchpad.net/stellarium/+bug/575621/+attachment/3504744/+files/stellarium-0.12.0-postRC3-win32.exe
>>
>> --
>> You received this bug notification because you are subscribed to the bug
>> report.
>> https://bugs.launchpad.net/bugs/575621
>>
>> Title:
>> Delta T and lunar acceleration
>>
>> Status in Stellarium:
>> Fix Committed
>>
>> Bug description:
>> Hello all of you,
>>
>> For some reason a full solar eclipse in Athens Greece (Jan 14th, 484 CE
>> around 5:48 UTC while they rise) is not calculated in the same way as
>> several other planetary programs (also using VSOP87/ELP2000:
>> http://www.iol.ie/~geniet/eng/skyprog.htm#Software )
>> So I am trying to find out a few things; do people know what Delta T
>> formula (like the newest one of Stephenson, Morrison 2004?) is being used
>> and what lunar acceleration (-25.7 +/- 0.2 "/year^2) has been used?
>>
>> I get with Stellarium (0.10.4) the max. eclipse around 7:40 UTC (so it
>> is well after rising (2 hours)).
>>
>> Thanks for the feedback. I am new to Stellarium and can't really yet
>> find my way around the vast amount of info, that is why I ask it in
>> this forum.
>>
>> All the best,
>>
>> Victor
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/stellarium/+bug/575621/+subscriptions
>>
>
>

[Allan Johnson (snofriacus)]

Yes, it's the Morrison and Stephenson 2004 Delta T calculations, with
the correction to compensate for being based on a slightly different
acceleration of the moon than the ELP-2000/82 lunar ephemeris data. It
turns out to be exactly the same situation described at
http://eclipse.gsfc.nasa.gov/SEcat5/deltatpoly.html, so all we had to do
was make the same correction that was made for the NASA eclipse pages.

I'm pretty sure it's exactly the same anyway. There is one detail I'm
uncertain about. The lunar ephemeris data used by Stellarium is labeled
as "ELP2000-82B". I don't know what the significance of the "B" is.

But I'm guessing that it doesn't reflect a change in the lunar
acceleration value used, since "ELP2000-82" was already using the newer
and more precise value of -25.858.

Allan

On 1/28/2013 3:51 PM, Victor Reijs wrote:
> Hello Allan,
>
> Just tried indeed Athens (484CE) and I also see 05:38 UT (so within the
> error range I have). Which DeltaT formula was used at the end
> (Stephenson&Morrison 2004)?
>
> The -135 April 15 at 6:09 UT (Babylon) can also be recreated (although it
> is not a full eclipse, but almost).
>
> All the best,
>
>
> Victor
>
> On 28 January 2013 20:06, Victor Reijs <email address hidden>
> wrote:
>
>> Thanks Allan, I am now downloading it. You did a great job in helping to
>> make this available. Will do some testing when the download is finished
>> (will take some time).
>>
>> THANKS.
>>
>> All the best,
>>
>> Victor
>>
>>
>> On 28 January 2013 19:27, Allan Johnson <email address hidden> wrote:
>>
>>> Ok, I'm attaching a copy of the installer I built this morning. I've
>>> called it "postRC3". It seems that I've gotten my build process adjusted
>>> now to where the resulting installer works without need for the
>>> additional hand-copying of dll's that I reported earlier. It's over
>>> twice the size of the official installers, but it does seem to work.
>>> It's about 160MB.
>>>
>>> I imagine there will soon be another official RC version that will
>>> supersede this, but this should give you something you can test today.
>>>
>>> You won't see the attachment on the email note. Just click the link to
>>> go to the online launchpad bug site, bug number 575621, and you should
>>> be able to download the attachment from there.
>>>
>>>
>>> ** Attachment added: "stellarium-0.12.0-postRC3-win32.exe"
>>>
>>> https://bugs.launchpad.net/stellarium/+bug/575621/+attachment/3504744/+files/stellarium-0.12.0-postRC3-win32.exe
>>>
>>> --
>>> You received this bug notification because you are subscribed to the bug
>>> report.
>>> https://bugs.launchpad.net/bugs/575621
>>>
>>> Title:
>>> Delta T and lunar acceleration
>>>
>>> Status in Stellarium:
>>> Fix Committed
>>>
>>> Bug description:
>>> Hello all of you,
>>>
>>> For some reason a full solar eclipse in Athens Greece (Jan 14th, 484 CE
>>> around 5:48 UTC while they rise) is not calculated in the same way as
>>> several other planetary programs (also using VSOP87/ELP2000:
>>> http://www.iol.ie/~geniet/eng/skyprog.htm#Software )
>>> So I am trying to find out a few things; do people know what Delta T
>>> formula (like the newest one ...

[Victor Reijs (appl-victor-reijs)]

Thanks Alan,

Indeed the acceleration compensation and DeltaT are thus implemented as I
proposed. I am very glad about that.
Looking at other eclipse times, it looks that Stellarium is significantly
earlier than other programs (but still within my range). I will try to
check if indeed the lunar acceleration of ELP-2000-82B is correctly
assumed. I think I will ask Meeus in the coming day.

All the best,

Victor

On 28 January 2013 22:34, Allan Johnson <email address hidden> wrote:

> But I'm guessing that it doesn't reflect a change in the lunar
> acceleration value used, since "ELP2000-82" was already using the newer
> and more precise value of -25.858.
>

[Allan Johnson (snofriacus)]

Looking again at the data point that I compared with Solex, maybe I'm
seeing the same thing. Rounded to the nearest minute, Stellarium was 2
minutes earlier. That's probably enough time to be significant for a
solar eclipse.

Solex says it uses "DE421". I wonder if that might account for the
difference

On 1/28/2013 6:37 PM, Victor Reijs wrote:
> Looking at other eclipse times, it looks that Stellarium is significantly
> earlier than other programs (but still within my range).

[Victor Reijs (appl-victor-reijs)]

Hello Allan,

I got feedback from the author of Solex and he has the following data:
"I have no direct knowledge of ELP2000-82B. However, according to what I can
read in Internet about it, and consistently with the epoch it was issued
(years 82-90), it was fitted on the JPL DE200 ephemerides, in which the
lunar tidal acceleration was -23.895 arcsecs/cy^2 (*).
Therefore this value should hold for the ELP2000-82B as well."

So it looks to be slightly different... I will ask another person to cross
reference?

All the best,

Victor

On 28 January 2013 23:37, Victor Reijs <email address hidden> wrote:

> Thanks Alan,
>
> Indeed the acceleration compensation and DeltaT are thus implemented as I
> proposed. I am very glad about that.
> Looking at other eclipse times, it looks that Stellarium is significantly
> earlier than other programs (but still within my range). I will try to
> check if indeed the lunar acceleration of ELP-2000-82B is correctly
> assumed. I think I will ask Meeus in the coming day.
>
> All the best,
>
> Victor
>
>
>
> On 28 January 2013 22:34, Allan Johnson <email address hidden> wrote:
>
>> But I'm guessing that it doesn't reflect a change in the lunar
>> acceleration value used, since "ELP2000-82" was already using the newer
>> and more precise value of -25.858.
>>
>

[Alexander Wolf (alexwolf)]

Hello Victor,

you can read description of ELP2000-82B here - ftp://ftp.imcce.fr/pub/ephem/moon/elp82b/elp82b.ps

[Victor Reijs (appl-victor-reijs)]

Hello Alexander,

I asked someone else, but he had not idea on this. I don't know if it is in
your file (I tried to scan it, but my ps viewer has a terrible resolution,
so I could not find somewhere a number close to an expected acceleration
value.

I though got the request if there could be a manual input for the DeltaT,
as that can be quiet handy for archaeoastronomical work (and I agree;-) I
wish I could help in implemented this... Sorry.

All the best,

Victor

On 30 January 2013 15:23, Alexander Wolf <email address hidden> wrote:

> Hello Victor,
>
> you can read description of ELP2000-82B here -
> ftp://ftp.imcce.fr/pub/ephem/moon/elp82b/elp82b.ps
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/575621
>
> Title:
> Delta T and lunar acceleration
>
> Status in Stellarium:
> Fix Committed
>
> Bug description:
> Hello all of you,
>
> For some reason a full solar eclipse in Athens Greece (Jan 14th, 484 CE
> around 5:48 UTC while they rise) is not calculated in the same way as
> several other planetary programs (also using VSOP87/ELP2000:
> http://www.iol.ie/~geniet/eng/skyprog.htm#Software )
> So I am trying to find out a few things; do people know what Delta T
> formula (like the newest one of Stephenson, Morrison 2004?) is being used
> and what lunar acceleration (-25.7 +/- 0.2 "/year^2) has been used?
>
> I get with Stellarium (0.10.4) the max. eclipse around 7:40 UTC (so it
> is well after rising (2 hours)).
>
> Thanks for the feedback. I am new to Stellarium and can't really yet
> find my way around the vast amount of info, that is why I ask it in
> this forum.
>
> All the best,
>
> Victor
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/stellarium/+bug/575621/+subscriptions
>

[Alexander Wolf (alexwolf)]

If I correctly understand ELP2000-82B use -23".895/cy^2 for value of the tidal secular acceleration.

Do you really need opportunity for a manual input of the DeltaT value?

[Allan Johnson (snofriacus)]

Ok, that's an interesting piece of info. We used the equation "c =
-0.000012932 * (y - 1955)^2" to make a correction from -26 to -25.858
for lunar acceleration. If we're correcting instead to -23.895, a larger
correction in the same direction would be needed. It looks like the
correction will always be negative, so with the larger correction, the
resulting Delta T will be smaller. The Delta T correction for ancient
dates makes the events occur earlier. So less Delta T means placing the
events a little bit later than we now have them. Victor, your
observation was "it looks that Stellarium is significantly earlier than
other programs". So something to place the events a bit later is just
what we're looking for.

For the specific event I was looking at in -553, c = -0.000012932 *
(-553 - 1955)^2 = -81.3 seconds
If this correction were increased by roughly 2 minutes (120 seconds),
that would have aligned it with the Solex result.

Anybody know how to derive the needed equation to correct from -26 to
-23.895?

Allan

On 1/30/2013 2:15 PM, Alexander Wolf wrote:
> If I correctly understand ELP2000-82B use -23".895/cy^2 for value of the
> tidal secular acceleration.

[Victor Reijs (appl-victor-reijs)]

Hello Allan and Alexander,

So author of Solex and the ps file of Alexander say the same.

See this link for the compensation formula:
http://eclipse.gsfc.nasa.gov/SEcat5/secular.html

Does that help?

All the best,

Victor

On 30 January 2013 20:06, Allan Johnson <email address hidden> wrote:

> Ok, that's an interesting piece of info. We used the equation "c =
> -0.000012932 * (y - 1955)^2" to make a correction from -26 to -25.858
> for lunar acceleration. If we're correcting instead to -23.895, a larger
> correction in the same direction would be needed. It looks like the
> correction will always be negative, so with the larger correction, the
> resulting Delta T will be smaller. The Delta T correction for ancient
> dates makes the events occur earlier. So less Delta T means placing the
> events a little bit later than we now have them. Victor, your
> observation was "it looks that Stellarium is significantly earlier than
> other programs". So something to place the events a bit later is just
> what we're looking for.
>
> For the specific event I was looking at in -553, c = -0.000012932 *
> (-553 - 1955)^2 = -81.3 seconds
> If this correction were increased by roughly 2 minutes (120 seconds),
> that would have aligned it with the Solex result.
>
> Anybody know how to derive the needed equation to correct from -26 to
> -23.895?
>
> Allan
>
>
> On 1/30/2013 2:15 PM, Alexander Wolf wrote:
> > If I correctly understand ELP2000-82B use -23".895/cy^2 for value of the
> > tidal secular acceleration.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/575621
>
> Title:
> Delta T and lunar acceleration
>
> Status in Stellarium:
> Fix Committed
>
> Bug description:
> Hello all of you,
>
> For some reason a full solar eclipse in Athens Greece (Jan 14th, 484 CE
> around 5:48 UTC while they rise) is not calculated in the same way as
> several other planetary programs (also using VSOP87/ELP2000:
> http://www.iol.ie/~geniet/eng/skyprog.htm#Software )
> So I am trying to find out a few things; do people know what Delta T
> formula (like the newest one of Stephenson, Morrison 2004?) is being used
> and what lunar acceleration (-25.7 +/- 0.2 "/year^2) has been used?
>
> I get with Stellarium (0.10.4) the max. eclipse around 7:40 UTC (so it
> is well after rising (2 hours)).
>
> Thanks for the feedback. I am new to Stellarium and can't really yet
> find my way around the vast amount of info, that is why I ask it in
> this forum.
>
> All the best,
>
> Victor
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/stellarium/+bug/575621/+subscriptions
>

[Victor Reijs (appl-victor-reijs)]

Hello Alexander,

On 30 January 2013 19:15, Alexander Wolf <email address hidden> wrote:

> Do you really need opportunity for a manual input of the DeltaT value?
>

Just some other feedback from the archaeoastronomy group I am on:
"*Stellarium* software was mentioned in this thread, and I can not resist a
comment:

I don't use *Stellarium* to extrapolate too far into the past
<added by VR: due to this DeltaT>
, but for some years now I've used this free "shareware" as a wonderful
teaching tool. It
can be used easily even by very young students, but it's powerful and
rigorous. It's praised by whole families after I recommend it to parents.
I can't imagine a greater recent contribution to astronomy education than
this amazing software, and the astronomer-programmers who created it as
free shareware are heroes as far as I'm concerned. They deserve an award!"

Indeed this manual input would be great, being able to change the DeltaT
can provide us with a sensitivity analysis...! Thanks for considering, but
I appreciate your decision.

All the best,

Victor

[Allan Johnson (snofriacus)]

Ok, now I'm questioning whether the lunar acceleration inherent in our ELP2000-82B data can really be -23.895. Using the equation Victor linked us to and computing the new correction for the year -553, the correction changes from -81.3 seconds to -1205.8 seconds, which would reduce the Delta T by 1124.5 seconds or about 19 minutes. I was hoping for a change in that direction, but just 2.5 minutes is what would have aligned it with Solex. With the new correction, it would be 16.5 minutes later than Solex rather than 2.5 minutes earlier. This doesn't seem likely to be correct.

Have I goofed up somewhere in my math?

Allan

[Alexander Wolf (alexwolf)]

Did you consider a case where we do not make correction for the secular acceleration of the moon?

P.S. Right now I can't check it.

[Alexander Wolf (alexwolf)]

Just a comment: I mean we do not make correction, which introduced by getSecularAccelerationMoon() method.

[Allan Johnson (snofriacus)]

Without the correction of getSecularAccelerationMoon(), the conjunction I'm looking at would be 3min 52 seconds earlier than in Solex.

With the current correction for 26 to 25.858, it's 2min 31 seconds earlier than in Solex

With the proposed correction for 26 to 23.895, it would be 16min 30 seconds later

So for this data point anyway, the current correction seems to be giving the best result.

Maybe we shouldn't change anything until some more testing can clarify things

[Alexander Wolf (alexwolf)]

I think we should be publish new version today for getting wide testing by community and fixed possible errors to version 0.12.1.

[Victor Reijs (appl-victor-reijs)]

Hello Allan,

I would go with the lunar accelaration that we now. Comparing with Solex
might not be always good (did they implement it well?). If you use the
-23.895, what will be the Athens eclipse time?

There are more programmes that use the same ephemerii as Stellarium (see my
overview: http://www.iol.ie/~geniet/eng/skyprog.htm#Evaluation ) and most
have a time of the eclipse closer to a quarter to the hour.

All the best,

Victor

On 31 January 2013 03:52, Allan Johnson <email address hidden> wrote:

> Without the correction of getSecularAccelerationMoon(), the conjunction
> I'm looking at would be 3min 52 seconds earlier than in Solex.
>
> With the current correction for 26 to 25.858, it's 2min 31 seconds
> earlier than in Solex
>
> With the proposed correction for 26 to 23.895, it would be 16min 30
> seconds later
>

[Victor Reijs (appl-victor-reijs)]

Sorry a type (now -> know) that might confuse. So I think we need to use
the lunar accelaration that is according to theory correct, which is the
-23.895.

On 31 January 2013 09:49, Victor Reijs <email address hidden> wrote:

> Hello Allan,
>
> I would go with the lunar accelaration that we now. Comparing with Solex
> might not be always good (did they implement it well?). If you use the
> -23.895, what will be the Athens eclipse time?
>
> There are more programmes that use the same ephemerii as Stellarium (see
> my overview: http://www.iol.ie/~geniet/eng/skyprog.htm#Evaluation ) and
> most have a time of the eclipse closer to a quarter to the hour.
>

[Allan Johnson (snofriacus)]

I've looked around in the source code some more, and found a reference to the same .ps file that Alexander pointed us to. This clearly is referring to the data that is in use by Stellarium. The data originated from ftp://ftp.imcce.fr/pub/ephem/moon/elp82b/. Nothing on my computer is able to read the ps file, but I found an online converter that made it into a pdf for me. I'm attaching the pdf version to this post. Maybe we'll all be able to read it in this form.

One other collection of data in the source code that looks important is called VSOP87, and originated from ftp://ftp.imcce.fr/pub/ephem/planets/vsop87/.

In elp82b.pdf I'm not seeing any mention of a particular lunar acceleration. Maybe section 7, entitled "Constants fitted to DE200/LE200", would be useful to look at. Some of the numbers there look like maybe they could give us a clue about the lunar acceleration value. But I don't understand these details well enough to evaluate them myself.

Allan

[Victor Reijs (appl-victor-reijs)]

Hello Allan,

I had a similar problem, but my PSP did a very low resolution ps
conversion;-) But also your pdf does not say anything about the lunar
acceleration. So we have only the Solex person stating the number. I have
an article that states the ELP2000-85 lunar acceleration, which is -23.895 (
http://adsabs.harvard.edu/full/1988A%26A...190..342C )
But this is not ELP2000-82B...

What lunar eclipse time do you get for Athens, if it is 16 minutes later,
it comes much closer to what most porgram provide...

All the best,

Victor

On 31 January 2013 15:18, Allan Johnson <email address hidden> wrote:

> I've looked around in the source code some more, and found a reference
> to the same .ps file that Alexander pointed us to. This clearly is
> referring to the data that is in use by Stellarium. The data originated
> from ftp://ftp.imcce.fr/pub/ephem/moon/elp82b/. Nothing on my computer
> is able to read the ps file, but I found an online converter that made
> it into a pdf for me. I'm attaching the pdf version to this post. Maybe
> we'll all be able to read it in this form.
>
> One other collection of data in the source code that looks important is
> called VSOP87, and originated from
> ftp://ftp.imcce.fr/pub/ephem/planets/vsop87/.
>
> In elp82b.pdf I'm not seeing any mention of a particular lunar
> acceleration. Maybe section 7, entitled "Constants fitted to
> DE200/LE200", would be useful to look at. Some of the numbers there look
> like maybe they could give us a clue about the lunar acceleration value.
> But I don't understand these details well enough to evaluate them
> myself.
>
> Allan
>
>
> ** Attachment added: "elp82b.pdf"
>
> https://bugs.launchpad.net/stellarium/+bug/575621/+attachment/3509067/+files/elp82b.pdf
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/575621
>
> Title:
> Delta T and lunar acceleration
>
> Status in Stellarium:
> Fix Released
>
> Bug description:
> Hello all of you,
>
> For some reason a full solar eclipse in Athens Greece (Jan 14th, 484 CE
> around 5:48 UTC while they rise) is not calculated in the same way as
> several other planetary programs (also using VSOP87/ELP2000:
> http://www.iol.ie/~geniet/eng/skyprog.htm#Software )
> So I am trying to find out a few things; do people know what Delta T
> formula (like the newest one of Stephenson, Morrison 2004?) is being used
> and what lunar acceleration (-25.7 +/- 0.2 "/year^2) has been used?
>
> I get with Stellarium (0.10.4) the max. eclipse around 7:40 UTC (so it
> is well after rising (2 hours)).
>
> Thanks for the feedback. I am new to Stellarium and can't really yet
> find my way around the vast amount of info, that is why I ask it in
> this forum.
>
> All the best,
>
> Victor
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/stellarium/+bug/575621/+subscriptions
>

[Allan Johnson (snofriacus)]

To help evaluate whether we should be correcting the lunar acceleration to -25.858 or -23.895, I'm building an installer for which this adjustment has been made. I'll attach it here.

In the process of making the adjustment I noticed a typo in the previous code. In the equation for correcting from -26 to -25.858 acceleration, we had (year - 1995) where it should have been (year - 1955). It may not make a large difference, but the results we get from testing version 0.12 won't be as meaningful as I would have liked. The typo is corrected in the new test installer.

Here's the test installer for the -23.895 acceleration correction.

I need to work on other things so probably won't have much time for Stellarium in the next several days, but in the meantime hopefully this will provide a good tool for testing, comparing results against those of other programs and against known historical data points.

Allan

[Victor Reijs (appl-victor-reijs)]

Thanks Allan, will do some testing. I don't think these 40 years will give
a large difference, But I will test your version. I also hope that I get a
more definite idea of this lunar acceleration of ELP2000-82B (I asked now a
300 person large forum interested in history of astronomy). Thanks for all
your help.

All the best,

Victor.

On 31 January 2013 19:03, Allan Johnson <email address hidden> wrote:

> To help evaluate whether we should be correcting the lunar acceleration
> to -25.858 or -23.895, I'm building an installer for which this
> adjustment has been made. I'll attach it here.
>
> In the process of making the adjustment I noticed a typo in the previous
> code. In the equation for correcting from -26 to -25.858 acceleration,
> we had (year - 1995) where it should have been (year - 1955). It may not
> make a large difference, but the results we get from testing version
> 0.12 won't be as meaningful as I would have liked. The typo is corrected
> in the new test installer.
>
> Here's the test installer for the -23.895 acceleration correction.
>
> I need to work on other things so probably won't have much time for
> Stellarium in the next several days, but in the meantime hopefully this
> will provide a good tool for testing, comparing results against those of
> other programs and against known historical data points.
>
> Allan
>
> ** Attachment added: "stellarium-0.12.1-test-win32.exe"
>
> https://bugs.launchpad.net/stellarium/+bug/575621/+attachment/3509412/+files/stellarium-0.12.1-test-win32.exe
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/575621
>
> Title:
> Delta T and lunar acceleration
>
> Status in Stellarium:
> Fix Released
>
> Bug description:
> Hello all of you,
>
> For some reason a full solar eclipse in Athens Greece (Jan 14th, 484 CE
> around 5:48 UTC while they rise) is not calculated in the same way as
> several other planetary programs (also using VSOP87/ELP2000:
> http://www.iol.ie/~geniet/eng/skyprog.htm#Software )
> So I am trying to find out a few things; do people know what Delta T
> formula (like the newest one of Stephenson, Morrison 2004?) is being used
> and what lunar acceleration (-25.7 +/- 0.2 "/year^2) has been used?
>
> I get with Stellarium (0.10.4) the max. eclipse around 7:40 UTC (so it
> is well after rising (2 hours)).
>
> Thanks for the feedback. I am new to Stellarium and can't really yet
> find my way around the vast amount of info, that is why I ask it in
> this forum.
>
> All the best,
>
> Victor
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/stellarium/+bug/575621/+subscriptions
>

[Victor Reijs (appl-victor-reijs)]

Hello Allan,

This one give 5:43UT for the eclipse. Which is close to the average of
eclipse of other programs (5:48UT). So I think we need to include these two
changes: 1955 and the lunar accelaration given by Solex author and
mentioned for ELP2000-85.
But lets see if users have other feedback on the 12.0 version.
<like manual input;-)>

Thanks Allan for providing this version.

All the best,

Victor

On 31 January 2013 19:31, Victor Reijs <email address hidden> wrote:

> Thanks Allan, will do some testing. I don't think these 40 years will give
> a large difference, But I will test your version. I also hope that I get a
> more definite idea of this lunar acceleration of ELP2000-82B (I asked now a
> 300 person large forum interested in history of astronomy). Thanks for all
> your help.
>
> All the best,
>
>
> Victor.
>
>
>
> On 31 January 2013 19:03, Allan Johnson <email address hidden> wrote:
>
>> To help evaluate whether we should be correcting the lunar acceleration
>> to -25.858 or -23.895, I'm building an installer for which this
>> adjustment has been made. I'll attach it here.
>>
>> In the process of making the adjustment I noticed a typo in the previous
>> code. In the equation for correcting from -26 to -25.858 acceleration,
>> we had (year - 1995) where it should have been (year - 1955). It may not
>> make a large difference, but the results we get from testing version
>> 0.12 won't be as meaningful as I would have liked. The typo is corrected
>> in the new test installer.
>>
>> Here's the test installer for the -23.895 acceleration correction.
>>
>> I need to work on other things so probably won't have much time for
>> Stellarium in the next several days, but in the meantime hopefully this
>> will provide a good tool for testing, comparing results against those of
>> other programs and against known historical data points.
>>
>> Allan
>>
>> ** Attachment added: "stellarium-0.12.1-test-win32.exe"
>>
>> https://bugs.launchpad.net/stellarium/+bug/575621/+attachment/3509412/+files/stellarium-0.12.1-test-win32.exe
>>
>> --
>> You received this bug notification because you are subscribed to the bug
>> report.
>> https://bugs.launchpad.net/bugs/575621
>>
>> Title:
>> Delta T and lunar acceleration
>>
>> Status in Stellarium:
>> Fix Released
>>
>> Bug description:
>> Hello all of you,
>>
>> For some reason a full solar eclipse in Athens Greece (Jan 14th, 484 CE
>> around 5:48 UTC while they rise) is not calculated in the same way as
>> several other planetary programs (also using VSOP87/ELP2000:
>> http://www.iol.ie/~geniet/eng/skyprog.htm#Software )
>> So I am trying to find out a few things; do people know what Delta T
>> formula (like the newest one of Stephenson, Morrison 2004?) is being used
>> and what lunar acceleration (-25.7 +/- 0.2 "/year^2) has been used?
>>
>> I get with Stellarium (0.10.4) the max. eclipse around 7:40 UTC (so it
>> is well after rising (2 hours)).
>>
>> Thanks for the feedback. I am new to Stellarium and can't really yet
>> find my way around the vast amount of info, that is why I ask it in
>> this forum.
>>
>> All the best,
>>
>> Victor
>>
>> To manage notifications abou...

[Allan Johnson (snofriacus)]

Ok, so actually the adjustment didn't take us too far at all in the direction it took us, if Stellarium is still on the early side compared to the others. Definitely getting closer to what would have been a noticeable event in Athens. For the Latitude & Longitude that Stellarium provides as "Athinai" I'm still finding no total eclipse, and the fullest eclipse happening beneath the horizon just before sunrise. But if I add just 1 degree East to the longitude, now I do get a total eclipse, and it happens just as the sun is rising.

So I think you're right that these latest adjustments are needed. For my own use, I'll go ahead and start depending on the 12.1 test version as probably providing the better reconstructions of historical events.

[Victor Reijs (appl-victor-reijs)]

Hello Allan and Alexander,

I not got several links that ELP2000-82B should be close to -23.8946 (I
don't want to copy them to this thread as they were send to me
personally). If wanted Alexander, provide me your e-mail address, so I can
forward them (I already send them to Allan).
So I think an 0.12.1 is indeed needed;-)

All the best,

Victor

On 31 January 2013 23:59, Allan Johnson <email address hidden> wrote:

> Ok, so actually the adjustment didn't take us too far at all in the
> direction it took us, if Stellarium is still on the early side compared
> to the others. Definitely getting closer to what would have been a
> noticeable event in Athens. For the Latitude & Longitude that Stellarium
> provides as "Athinai" I'm still finding no total eclipse, and the
> fullest eclipse happening beneath the horizon just before sunrise. But
> if I add just 1 degree East to the longitude, now I do get a total
> eclipse, and it happens just as the sun is rising.
>
> So I think you're right that these latest adjustments are needed. For my
> own use, I'll go ahead and start depending on the 12.1 test version as
> probably providing the better reconstructions of historical events.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/575621
>
> Title:
> Delta T and lunar acceleration
>
> Status in Stellarium:
> Fix Released
>
> Bug description:
> Hello all of you,
>
> For some reason a full solar eclipse in Athens Greece (Jan 14th, 484 CE
> around 5:48 UTC while they rise) is not calculated in the same way as
> several other planetary programs (also using VSOP87/ELP2000:
> http://www.iol.ie/~geniet/eng/skyprog.htm#Software )
> So I am trying to find out a few things; do people know what Delta T
> formula (like the newest one of Stephenson, Morrison 2004?) is being used
> and what lunar acceleration (-25.7 +/- 0.2 "/year^2) has been used?
>
> I get with Stellarium (0.10.4) the max. eclipse around 7:40 UTC (so it
> is well after rising (2 hours)).
>
> Thanks for the feedback. I am new to Stellarium and can't really yet
> find my way around the vast amount of info, that is why I ask it in
> this forum.
>
> All the best,
>
> Victor
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/stellarium/+bug/575621/+subscriptions
>

[Alexander Wolf (alexwolf)]

Hi Victor,

my email is <email address hidden>

[Victor Reijs (appl-victor-reijs)]

Just send you three e-mail of people mentioned this -23.8946

On 1 February 2013 16:30, Alexander Wolf <email address hidden> wrote:

> Hi Victor,
>

[Allan Johnson (snofriacus)]

Hi Alexander,

It sounds like we probably do need to implement the Delta T adjustments
that are in the test version Victor has been trying out. Here are the
adjustments, to be applied to StelUtils.cpp:

      // Method described is here:
http://eclipse.gsfc.nasa.gov/SEcat5/secular.html
+ // For adapting from -26 to -25.858, use -0.91072 * (-25.858 +
26.0) = -0.12932224
+ // For adapting from -26 to -23.895, use -0.91072 * (-23.895 +
26.0) = -1.9170656

- double t = (year-1995)/100;
+ double t = (year-1955)/100;

- return -0.12932224 * t * t;
+ return -1.9170656 * t * t;

Only two lines actually adjusted, but maybe good to add in the comments
as well, to help keep track of where our numbers have come from. I'd
appreciate it if you'd double check my math before implementing. It's
easy to slip up on the small details.

Allan

[Alexander Wolf (alexwolf)]

Hmm...

Just a fact: we use Espenak & Meeus (2006) algorithm for computation of ΔT, which based on Morrison and Stephenson (2004) equations. The revised value used for the Moon's secular acceleration, which originally used in this algorithm, is n-dot = -25.858 arc-sec/cy*cy (-0.12932224). For solar eclipse on 484/1/14 original algorithm give a value of ΔT = 5838.3 s (http://eclipse.gsfc.nasa.gov/SEsearch/SEsearchmap.php?Ecl=04840114). Stellarium with double t = (year-1955)/100; and return -0.12932224 * t * t; give a value of ΔT = 5840.95 s. Stellarium with double t = (year-1955)/100; and return -1.9170656 * t * t; (latest fix) give a value of ΔT = 5490.55 s.

If http://eclipse.gsfc.nasa.gov/ use as etalon then better values Stellarium given with n-dot = -25.858 arc-sec/cy*cy (-0.12932224). If we use SOLEX as etalon then I need know, which exactly algorithm was used for ΔT computation.

P.S. Some info about SOLEX and ΔT algorithms I found on this page: http://www.staff.science.uu.nl/~gent0113/deltat/deltat_old.htm

[Victor Reijs (appl-victor-reijs)]

Hmmm...

On 1 February 2013 18:42, Alexander Wolf <email address hidden> wrote:

> Hmm...
>
> Just a fact: we use Espenak & Meeus (2006) algorithm for computation of
> ΔT, which based on Morrison and Stephenson (2004) equations. The revised
> value used for the Moon's secular acceleration, which originally used
> in this algorithm, is n-dot = -25.858 arc-sec/cy*cy (-0.12932224).

Stephenson&Morrison uses -26. Do you use Stephenson&Morrison (2004&2005, as
I proposed) or do you use Espernak&Meeus? I don't know which n.dot that one
is based, I though it resulted in the same values as Stephenson, but I
never checked (Espernak could have included a compensation to -25.858, but
that is easy to check).

> For
> solar eclipse on 484/1/14 original algorithm give a value of ΔT = 5838.3
> s (http://eclipse.gsfc.nasa.gov/SEsearch/SEsearchmap.php?Ecl=04840114).
> Stellarium with double t = (year-1955)/100; and return -0.12932224 * t *
> t; give a value of ΔT = 5840.95 s. Stellarium with double t =
> (year-1955)/100; and return -1.9170656 * t * t; (latest fix) give a
> value of ΔT = 5490.55 s.
>

I assume one is the almost uncompensated (5841, using -58.858), while the
5491 is compensated to different ephemeris' n.dot (-23.895)? Correct?
As Stellarium uses a different lunar ephemeris (ELP2000-85 with n.dot of
-23.895) the compensated DeltaT is indeed different! But I might
misunderstand what you are meaning.

P.S. Some info about SOLEX and ΔT algorithms I found on this page:
> http://www.staff.science.uu.nl/~gent0113/deltat/deltat_old.htm
>

I have simpler formula (not so many polynomials) for DeltaT;-) I derived a
sinus function which is quite closely following Stephenson&Morrison
(2004,2005): http://www.iol.ie/~geniet/eng/DeltaTeval.htm#formula

All the best,

Victor

[Allan Johnson (snofriacus)]

Ok, let me see if I'm following you correctly -

On 2/1/2013 1:42 PM, Alexander Wolf wrote:
> Hmm...
>
> Just a fact: we use Espenak & Meeus (2006) algorithm for computation of
> ΔT, which based on Morrison and Stephenson (2004) equations. The revised
> value used for the Moon's secular acceleration, which originally used
> in this algorithm, is n-dot = -25.858 arc-sec/cy*cy (-0.12932224). For
> solar eclipse on 484/1/14 original algorithm give a value of ΔT = 5838.3
> s (http://eclipse.gsfc.nasa.gov/SEsearch/SEsearchmap.php?Ecl=04840114).

Yes, I see that now. Below the map it says "These eclipse predictions
were generated for the Moon's center of mass using the VSOP87/ELP2000-82
ephemerides <http://eclipse.gsfc.nasa.gov/SEcat5/ephemeris.html> and a
value of ΔT = *5838.3 s*". So what you're saying is that if our
implementation is correct, it should result in a similar ΔT value, close
to 5838.3 seconds.

> Stellarium with double t = (year-1955)/100; and return -0.12932224 * t *
> t; give a value of ΔT = 5840.95 s.

So this is the value actually produced by the Stellarium code after
correcting 1995 to 1955? This looks pretty good, only differing by about
3 seconds.

> Stellarium with double t =
> (year-1955)/100; and return -1.9170656 * t * t; (latest fix) give a
> value of ΔT = 5490.55 s.

And this is the result of the latest fix I suggested. Stellarium is
giving me this same number on my computer. Not such a good match. It
differs by about 348 seconds, or close to 6 minutes, from what the NASA
site reports.

>
> If http://eclipse.gsfc.nasa.gov/ use as etalon then better values
> Stellarium given with n-dot = -25.858 arc-sec/cy*cy (-0.12932224). If we
> use SOLEX as etalon then I need know, which exactly algorithm was used
> for ΔT computation.

I think a good initial goal would be just to correctly implement the
DeltaT polynomials used by the NASA eclipse pages. And from what you're
showing us here, it seems that the -26 to -25.858 correction is the one
that comes closest to doing that.

Still there's an empirical concern, that perhaps these polynomials don't
do an adequate job of matching the 484/1/14 eclipse. I haven't actually
seen an account of what was seen and recorded and at what exact
location, but with the -26 to -23.895 correction I find a total eclipse
in progress right at sunrise just 1 degree east of Athens, while with
the -26 to -25.858 correction I don't think there is a total eclipse
within one degree of Athens, and the fullest eclipse that does occur
happens below the horizon before sunrise.

So... correcting from -26 to -23.895 does seem to give a nicer result
for that particular eclipse, but from what you've shown us it appears to
be the wrong way to fix it. If that eclipse isn't being correctly
reproduced, we probably need to find another set of equations that's
designed to place this eclipse a bit later, and introduce that as an
alternative DeltaT approach that a user can choose. The equation that
Victor derived would probably do a good job with this.

Allan

[Victor Reijs (appl-victor-reijs)]

Hello all of you,

On 1 February 2013 22:36, Allan Johnson <email address hidden> wrote:

> I think a good initial goal would be just to correctly implement the
> DeltaT polynomials used by the NASA eclipse pages. And from what you're
> showing us here, it seems that the -26 to -25.858 correction is the one
> that comes closest to doing that.
>

I don;t think. The DeltaT we have is correct. But that needs to be
corrected (that is not called anymore DeltaT, I would think, but correct
DeltaT.
ELP2000-82B needs correction...

All the best,

Victor