search

Stellarium / stellarium

Stellarium is a free GPL software which renders realistic skies in real time with OpenGL. It is available for Linux/Unix, Windows and macOS. With Stellarium, you really see what you can see with your eyes, binoculars or a small telescope.
https://stellarium.org
GNU General Public License v2.0
7.75k stars 821 forks source link

Astronomical calculations - Ephemeris: values for Date and Time column #717

Closed wlaun closed 5 years ago

wlaun commented 5 years ago

Expected Behaviour

The "Date and Time" column of the results for "Astronomical algorithms"->"Ephemeris" should show a regular progress according to the selected increment, from 10m up.

Actual Behaviour

ephemeris.xlsx 1) Spurious first line, with time 2014-10-23 00:00:00 2) Increments in 9 or 11 minutes. 3) Line 2014-10-24 00:00:00 is missing

Steps to reproduce

Cel.body: Moon, Time step: 10 min., From: 2014-10-23 23:00 (UTC+2), To: 2014-10-24 1:00

System

Related issue?

StelUtils, function jdFractionToQTime looks suspicious. In fact, running s.th. like double jd = 2446470.5; // 1986-02-09 double m10 = 1.0/(2460)10; // 10 minutes for( int i = 0; i < 24; ++i ){ for( int j = 0; j < 6; ++j ){ jdFractionToQTime( jd + (i6+j)m10 ); } printf( "\n"); } produces: 0:00 0:10 0:20 0:30 0:40 0:49 0:59 1:09 1:19 1:30 1:40 1:50 2:00 2:10 2:19 2:29 2:39 2:49 3:00 3:10 3:20 3:30 3:40 3:49 3:59 4:09 4:19 4:30 4:40 4:50 5:00 5:10 5:19 5:29 5:39 5:49 6:00 6:10 6:20 6:30 6:40 6:49 6:59 7:09 7:19 7:30 7:40 7:50 8:00 8:10 8:19 8:29 8:39 8:49 9:00 9:10 9:20 9:30 9:40 9:49 9:59 10:09 10:19 10:30 10:40 10:50 11:00 11:10 11:19 11:29 11:39 11:49 12:00 12:10 12:20 12:30 12:40 12:49 12:59 13:09 13:19 13:30 13:40 13:50 etc. etc.

A better implementation might be: QTime jdFractionToQTime(const double jd){ const double sec30 = 1.0/(24602); double decHours = fmod(jd+0.5+sec30, 1.0); int hours = (int)(decHours24); int mins = (int)((decHours24-hours)*60); // printf(" %d:%02d", hours, mins ); return QTime::fromString(QString("%1.%2").arg(hours).arg(mins), "h.m"); } which results in equal spacing.

alex-w commented 5 years ago

Cannot reproduce the issue in version 0.19.1

wlaun commented 5 years ago

Great - I'll upgrade ASAP. The code of jdFractionToQTime convertinga JD to hh:mm can be found on branch master, but I haven't seen the equivalent for hh:mm:ss. Maybe jdFractionToQTime isn't used anywhere.

On Tue, 16 Jul 2019 at 15:20, Alexander Wolf notifications@github.com wrote:

Cannot reproduce the issue in version 0.19.1

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Stellarium/stellarium/issues/717?email_source=notifications&email_token=AMUBM4LV3RD7SMHY6R4IBNTP7XDIXA5CNFSM4IEATR22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2A2HBY#issuecomment-511812487, or mute the thread https://github.com/notifications/unsubscribe-auth/AMUBM4OHO7W3ZQ6SJUVAFJLP7XDIXANCNFSM4IEATR2Q .

alex-w commented 5 years ago

Yes, jdFractionToQTime isn't used anywhere at the moment. I guess it's time to refactoring the code.

wlaun commented 5 years ago

OK! 0.19.1 produces all the expected lines but still has hh:a9:99 where it should have hh:b0:00. If you point me to the code creating the Ephemerides list, I can probably suggest an improvement.

On Wed, 17 Jul 2019 at 07:08, Alexander Wolf notifications@github.com wrote:

Yes, jdFractionToQTime isn't used anywhere at the moment. I guess it's time to refactoring the code.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Stellarium/stellarium/issues/717?email_source=notifications&email_token=AMUBM4NVSXGWWRAT7QJKI3TP72SLRA5CNFSM4IEATR22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2DBLBY#issuecomment-512103815, or mute the thread https://github.com/notifications/unsubscribe-auth/AMUBM4NM2JVGIYLGQWOLJELP72SLRANCNFSM4IEATR2Q .

alex-w commented 5 years ago

See https://github.com/Stellarium/stellarium/blob/d2cf1c58b0fe1b4e5975f272cabb4ef54451d907/src/gui/AstroCalcDialog.cpp#L1631

Please give test data for reproduce issue

wlaun commented 5 years ago

Body: Moon Step: 10 minutes From: 2014-10-23 23:00 -- probably any value From: 2014-10-24 01:00 -- probably any value

In the location window: Location: Toronto or Vienna -- probably doesn't matter Timezone: UTC+02:00 (same as my system clock)

It is OK when you use Timezone: UTC

(Why don't you let me help - I have long experience reading other people's code. Please point me to the Ephemerides function.)

On Wed, 17 Jul 2019 at 09:58, Alexander Wolf notifications@github.com wrote:

See https://github.com/Stellarium/stellarium/blob/d2cf1c58b0fe1b4e5975f272cabb4ef54451d907/src/gui/AstroCalcDialog.cpp#L1631

Please give test data for reproduce issue

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Stellarium/stellarium/issues/717?email_source=notifications&email_token=AMUBM4KOWYPUAYFX3GYHD3DP73GLRA5CNFSM4IEATR22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2DL3GI#issuecomment-512146841, or mute the thread https://github.com/notifications/unsubscribe-auth/AMUBM4MFN74CS672H473ZD3P73GLRANCNFSM4IEATR2Q .

alex-w commented 5 years ago

See method generateEphemeris(): https://github.com/Stellarium/stellarium/blob/master/src/gui/AstroCalcDialog.cpp#L1363

I can confirm issue on some time zone settings

wlaun commented 5 years ago

Line AstroCalc.cpp:1508: double firstJD = StelUtils::qDateTimeToJd(ui->dateFromDateTimeEdit->dateTime ()); firstJD = firstJD - core->getUTCOffset(firstJD) / 24;

Sample values for various offsets, full precision but not with code from Stellarium - note the up and down around 2m00s: offset 0: 2019-07-17T12:01:59.999992847 offset 1: 2019-07-17T13:01:59.999979436 offset 2: 2019-07-17T14:02:00.000006258 offset 3: 2019-07-17T15:01:59.999992847 offset 4: 2019-07-17T16:01:59.999979436 offset 5: 2019-07-17T17:02:00.000006258 offset 6: 2019-07-17T18:01:59.999992847 offset 7: 2019-07-17T19:01:59.999979436 offset 8: 2019-07-17T20:02:00.000006258 offset 9: 2019-07-17T21:01:59.999992847 offset 10: 2019-07-17T22:01:59.999979436 offset 11: 2019-07-17T23:02:00.000006258

Next, we have line 1609: item.objDate = QString("%1 %2").arg(localeMgr->getPrintableDateLocal(JD), localeMgr->getPrintableTimeLocal(JD)); with JD being firstJD plus the increment. In StelUtils.cpp:771 : double secs = frac 24.0 60.0 * 60.0 + 0.0001; // add constant to fix floating-point truncation error

According to the above sample values, 0.0001 (0.1 ms) should be enough to avoid getting below the full minute - but I'm not sure about the quality of the Julian Day values actually occurring during the Ephemerides calculation. 0.00001 is not enough, even with the above sample values!

If getPrintableTimeLocal is never used to get milliseconds, it might be worth trying 0.5 (for rounding to seconds) and see whether the "-1 second effect" goes away.

I'll check some more, but it's not likely that the problem is elsewhere.

On Wed, 17 Jul 2019 at 11:10, Alexander Wolf notifications@github.com wrote:

See method generateEphemeris(): https://github.com/Stellarium/stellarium/blob/master/src/gui/AstroCalcDialog.cpp#L1363

I can confirm issue on some time zone settings

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Stellarium/stellarium/issues/717?email_source=notifications&email_token=AMUBM4ONPTSFXH4GALYDBULP73OW3A5CNFSM4IEATR22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2DRYLI#issuecomment-512171053, or mute the thread https://github.com/notifications/unsubscribe-auth/AMUBM4NUGIB24BDCHCPKTHLP73OW3ANCNFSM4IEATR2Q .

wlaun commented 5 years ago

InStelUtils there is: double qDateTimeToJd(const QDateTime& dateTime){ return (double)(dateTime.date().toJulianDay())+(double)1./(2460601000)QTime(0, 0, 0, 0).msecsTo(dateTime.time())-0.5; } The resulting Julian Day has only millisecond precision. This is probably sufficient in most contexts, but I think it is a strong indication for using 0.1 or 0.5 in getPrintableTimeLocal.

QTime stops at milliseconds. This is a bit outdated.

On Wed, 17 Jul 2019 at 18:42, Wolfgang Laun wolfgang.laun@gmail.com wrote:

Line AstroCalc.cpp:1508: double firstJD = StelUtils::qDateTimeToJd(ui->dateFromDateTimeEdit-> dateTime()); firstJD = firstJD - core->getUTCOffset(firstJD) / 24;

Sample values for various offsets, full precision but not with code from Stellarium - note the up and down around 2m00s: offset 0: 2019-07-17T12:01:59.999992847 offset 1: 2019-07-17T13:01:59.999979436 offset 2: 2019-07-17T14:02:00.000006258 offset 3: 2019-07-17T15:01:59.999992847 offset 4: 2019-07-17T16:01:59.999979436 offset 5: 2019-07-17T17:02:00.000006258 offset 6: 2019-07-17T18:01:59.999992847 offset 7: 2019-07-17T19:01:59.999979436 offset 8: 2019-07-17T20:02:00.000006258 offset 9: 2019-07-17T21:01:59.999992847 offset 10: 2019-07-17T22:01:59.999979436 offset 11: 2019-07-17T23:02:00.000006258

Next, we have line 1609: item.objDate = QString("%1 %2").arg(localeMgr->getPrintableDateLocal(JD), localeMgr->getPrintableTimeLocal(JD)); with JD being firstJD plus the increment. In StelUtils.cpp:771 : double secs = frac 24.0 60.0 * 60.0 + 0.0001; // add constant to fix floating-point truncation error

According to the above sample values, 0.0001 (0.1 ms) should be enough to avoid getting below the full minute - but I'm not sure about the quality of the Julian Day values actually occurring during the Ephemerides calculation. 0.00001 is not enough, even with the above sample values!

If getPrintableTimeLocal is never used to get milliseconds, it might be worth trying 0.5 (for rounding to seconds) and see whether the "-1 second effect" goes away.

I'll check some more, but it's not likely that the problem is elsewhere.

On Wed, 17 Jul 2019 at 11:10, Alexander Wolf notifications@github.com wrote:

See method generateEphemeris(): https://github.com/Stellarium/stellarium/blob/master/src/gui/AstroCalcDialog.cpp#L1363

I can confirm issue on some time zone settings

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Stellarium/stellarium/issues/717?email_source=notifications&email_token=AMUBM4ONPTSFXH4GALYDBULP73OW3A5CNFSM4IEATR22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2DRYLI#issuecomment-512171053, or mute the thread https://github.com/notifications/unsubscribe-auth/AMUBM4NUGIB24BDCHCPKTHLP73OW3ANCNFSM4IEATR2Q .

alex-w commented 5 years ago

Seems the issue is not fixed yet!

alex-w commented 5 years ago

OK, it's rounding effect for compute duration of solar day.