Calculation of Delta T is incorrectly applied

Hell fbilki,
You say that DeltaT has nothing to do with the rotation of the earth. That is not true. DeltaT is the accumulative difference between the rotation of the earth (close to 24 hours, not not fully) and a 'day' of precisely 24*60*60 SI seconds. see also https://en.wikipedia.org/wiki/%CE%94T Any modern ephemeris uses a 24*60*6o SI seconds per day, and thus one needs to adjust the time to map real time.
But I don't think your point is only that, so let me know, perhaps I can help.
All the best,

Victor

Hi Victor,

Yes, you’re right – my point is about much more than the simple difference
defined by Delta T.

Firstly, Delta T is the difference between two very important time-scales:
TT (was called TDT), which is based on the SI second, and UT1, which is
based on the Earth’s rotation.We use UT1 because it corresponds to the
Earth’s rotation. But because it’s irregular it can’t be represented on a
clock, which is why we use UTC (and insert occasional leap seconds like
just happened today).

But if we aren’t worried these 1-second adjustments we can use UTC as if it
were UT1.

We need TT because it corresponds to the clockwork of the universe and,
more importantly, can be measured using the SI seconds of atomic time
(using another timescale called TAI).

It’s easier to understand my issue if we work backwards through the
standard positional calculation and just concentrate on stars. We’ll ignore
precession, nutation, proper motion, aberration, refraction, and so on. To
calculate the azimuth and altitude of a star with a known Right Ascension
and Declination, we apply Formulae 13.5 and 13.6 from Meeus (1998), or
Equations 11.43-3 and 11.43-4 from Seidelmann (1992).

These formulae take the following arguments:

- The local hour angle

- The observer’s latitude and longitude

- The star’s declination

To calculate the local hour angle we need:

 - Greenwich sidereal time

- The star’s right ascension

And lastly, to calculate Greenwich sidereal time we need:

 - The time in UT

But we have already decided that we can substitute UTC for UT1 with < 1 sec
error.

So, thinking about the way the sky view changes in Stellarium when you
switch to different Delta T models, it’s pretty clear that:

- The observer’s location didn’t change

- The RA and Dec of the stars didn’t change, and

- The UTC time didn’t change.

- Therefore the position of the stars in the sky should NOT change

And that’s my point:

TO CALCULATE THE ALTITUDE AND AZIMUTH OF A CELESTIAL BODY WITH KNOWN RA AND
DEC DOES NOT REQUIRE THE USE OF DELTA T.

(Apologies for the capitalisation; plain text doesn’t give me much scope
for highlighting this important fact.)

 The many corrections that *do* use Delta T (precession, nutation, proper
motion, aberration, etc.), which we ignored, are too small to see.

Here is a summary of the full star position algorithm from Seidelmann,
showing those corrections and their time arguments:

1a: Calculate date in TDT

1b: Convert to centuries

1c: Calculate mean anomaly of Earth (timescale = TDT centuries)

1e: Convert to centuries since Julian Date 2000.0

2: Determine position and velocity of Earth, and position of Sun (timescale
= TDT)

3: Calculate star’s space motion (timescale = TDT)

4: Calculate star’s barycentric position (timescale = TDT)

5: Calculate star’s geocentric position (timescale = TDT)

6: Apply relativistic deflection of light (timescale = TDT)

7: Apply aberration of light

8: Apply precession (timescale = TDT)

9: Apply nutation (timescale = TDT)

10: Calculate apparent RA and Dec (timescale = TDT)

11. Convert to altitude and azimuth (timescale = UT1)

12. Apply refraction

Steps 1 to 10 are all about converting...

Just to check: If one changes the DeltaT formula in Stellarium, it looks Stellarium uses the TT as its basis. So it calculates UT (using TT-DeltaT). So the presented (UT) time changes in the time window of Stellarium.
If I go back to the same UT (after changing the DeltaT formula) I see the same sky (I did not compare it dot for dot, but they look quite the same). But lets first see if you see the same as me.

It took me also some time to understand the changing of the view. I don't know what is better keeping TT the same or UT. I think for the average user; keeping UT the same sound better (keeping TT the same is more for the expert). But not sure: Stellarium is the only programme that has this diversity of DeltaT formula, so comparing with other programmes is difficult.

All the best,

Victor

Hi Victor,

Thanks for looking into this. I'm glad you've figured out the situation.
I'll take another look at it when I get home and will reproduce your
readjustment of UTC so I can see it for myself. But I can picture it in my
mind's eye (and should have thought of it myself), so I don't expect to
have any problems doing so.

For what it's worth, I volunteer at an observatory that until recently was
staffed by professional astronomers. I once asked them what time argument
they used and they told me it was UTC, not UT1 or TT. If you look at the
astronomical almanac, virtually every phenomenon is listed using UT or UTC.

I think the answer is clear: *everyone* understands and uses UTC, even
average users who might not be aware of the intricacies of such a hybrid
time scale.

It's also worth remembering that Delta T will have a major effect on the
observed location of an eclipse: although the Sun-Moon-Earth geometry is
defined using TT, the position of the Moon's shadow on the surface of the
Earth is controlled by UT1 and hence UTC. A one-minute error could make the
difference between being in the line of totality and not being there.

Cheers,

Frank

On Tue, Jul 7, 2015 at 3:56 AM, Victor Reijs <email address hidden>
wrote:

> Just to check: If one changes the DeltaT formula in Stellarium, it looks
> Stellarium uses the TT as its basis. So it calculates UT (using TT-DeltaT).
> So the presented (UT) time changes in the time window of Stellarium.
> If I go back to the same UT (after changing the DeltaT formula) I see the
> same sky (I did not compare it dot for dot, but they look quite the same).
> But lets first see if you see the same as me.
>
> It took me also some time to understand the changing of the view. I
> don't know what is better keeping TT the same or UT. I think for the
> average user; keeping UT the same sound better (keeping TT the same is
> more for the expert). But not sure: Stellarium is the only programme
> that has this diversity of DeltaT formula, so comparing with other
> programmes is difficult.
>
>
> All the best,
>
>
> Victor
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1380242
>
> Title:
> Calculation of Delta T is incorrectly applied
>
> Status in Stellarium:
> New
>
> Bug description:
> I think you are incorrectly applying the calculation of Delta T.
>
> Delta T is defined as the difference between TT and UT (Terrestrial
> time and Universal Time). UT can be treated as Greenwich time in this
> context, and TT applies solely to the clockwork of objects within our
> solar system, relative to the solar system barycentre. Delta T has
> nothing to do with the rotation of the earth, and therefore nothing to
> do with the observed locations of objects in the sky.
>
> However, when I change Delta T options in 0.12.4 I see *everything* in
> the sky wheel around slightly. This is wrong.
>
> Delta T should only be applied to the calculation of the positions of
> solar system objects with respect to its barycentre. It should not
> affect stellar and deep sky objects at all, and in fact even changes
> solar syst...

Did you verify Frank? Let me know. In some way I think keeping the UT the same after a change in DeltaT formula is more intuitive then keeping the TT the same. So perhaps we should propose that (when you agree that the implementation itself is correct).
Let me know.

Indeed DeltaT and location are bounded: as a DeltaT means a more (or less) turned-earth and thus a different location of the band of visibility. On my web pages I gave some ideas on the influence: http://www.archaeocosmology.org/eng/skyprog.htm#events

All the best,

Victor

Hi Victor,

Yes, I have verified the result. The same instant as displayed in the
Date/Time window produces the same sky no matter which Delta T model is
used (but I didn't try them all).

And, yes, I definitely believe we should propose that Stellarium should
use UT as its user timescale.

Cheers,

Frank

On 17/07/15 05:33, Victor Reijs wrote:
> Did you verify Frank? Let me know. In some way I think keeping the UT the same after a change in DeltaT formula is more intuitive then keeping the TT the same. So perhaps we should propose that (when you agree that the implementation itself is correct).
> Let me know.
>
> Indeed DeltaT and location are bounded: as a DeltaT means a more (or
> less) turned-earth and thus a different location of the band of
> visibility. On my web pages I gave some ideas on the influence:
> http://www.archaeocosmology.org/eng/skyprog.htm#events
>
> All the best,
>
>
> Victor
>

Ok, I will make that a feature request...

I am afraid I have to agree that we must change something to (1) make code understandable and (2) application more intuitive.

Only now I have seen that the "JDay" in Stelcore is apparently now to be understood as TT, while for example sidereal time has then to be corrected by deltaT. This should be the other way round, and it should please always be clearly notified in source code which type of JD (I propose canonical variable names JD=UT, JDE=TT with the E from the old name "Ephemeris time"; I also leave aside details like UT1) has to be used. Sidereal time does not contain DeltaT.

Maybe https://bugs.launchpad.net/stellarium/+bug/1275092 is then related, this would be a dramatic demonstration.

I think the easiest would be to add a variable JDE to StelCore, and every kind of "setJD(date)" should set both, JDay and JDE, so that then functions can be called with whichever flavour of JD is required, without in-code adjustments which can be easily forgotten, and are pretty awkward in the current solution.

This should be done after https://code.launchpad.net/~georg-zotti/stellarium/gz_fix-ecliptic-obliquity is finished (which is a pretty big change, with accurate precession at last), but then quite soon.

On Sun, Jul 26, 2015 at 1:04 AM, gzotti <email address hidden> wrote:
> I am afraid I have to agree that we must change something to (1) make
> code understandable and (2) application more intuitive.
>
> Only now I have seen that the "JDay" in Stelcore is apparently now to be
> understood as TT, while for example sidereal time has then to be
> corrected by deltaT. This should be the other way round, and it should
> please always be clearly notified in source code which type of JD (I
> propose canonical variable names JD=UT, JDE=TT with the E from the old
> name "Ephemeris time"; I also leave aside details like UT1) has to be
> used. Sidereal time does not contain DeltaT.
>
> Maybe https://bugs.launchpad.net/stellarium/+bug/1275092 is then
> related, this would be a dramatic demonstration.
>
> I think the easiest would be to add a variable JDE to StelCore, and
> every kind of "setJD(date)" should set both, JDay and JDE, so that then
> functions can be called with whichever flavour of JD is required,
> without in-code adjustments which can be easily forgotten, and are
> pretty awkward in the current solution.
>
> This should be done after https://code.launchpad.net/~georg-
> zotti/stellarium/gz_fix-ecliptic-obliquity is finished (which is a
> pretty big change, with accurate precession at last), but then quite
> soon.

I started doing something like that long time ago in my time zone
branch, but I don't remember if I finished the delta-T cleanup. My old
work is probably useless, though, since the code has changed a lot
since then.

Bogdan

Bordan, your enforcement not finished yet and delta-T cleanup not completed.

Huh? IMHO time zones related stuff should not even touch deltaT.

Time on earth=UT and timezone offsets or True Time =UT+longitudinal_offset. Traditionally linked to Mean Solar Day and the Solar transit called Noon.

Time in the solar system algorithms =TT, with a clockwork decoupled from the early-20ct earth-rotation-based definition of "second", but linked to Atomic time TAI.

Fix committed in r7760.

Unfortunately the mentioned https://bugs.launchpad.net/stellarium/+bug/1275092 is not fixed by this. Maybe something wrong about the moon?