Planet RTS

[gzotti]

Description

This should solve the inaccurate rise/set times given for planets, esp. the Moon. It is based on the method given by Meeus but with some optimisations.

Fixes #554

Screenshots (if appropriate):

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• This change requires a documentation update

How Has This Been Tested?

Observe Moon (or Sun, or planet) on screen, see behaviour and times.
I have still to make tests around reaching circumpolarity and other funny things.

There is still the problem that sometimes rise time for the next day or setting time for the previous day is found.

Still not fully tested: behaviour on other planets.

The fine corrections are also applied to StelObject.

Test Configuration:

• Operating system: Win10 21H1
• Graphics Card: Nvidia 960M (irrelevant)

Checklist:

• My code follows the code style of this project.
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[github-actions]

Hello @gzotti! Thank you for this enhancement.

[alex-w]

By the fact getRTSTime and computeRTSTime methods have same behavior and I think we can move code from computeRTSTime into getRTSTime method and removed first one. The second problem: to compute RTS time of the Sun for twilight we need change the height of celestial body (+ users ask this feature for AstroCalc functions) - so, maybe add new one parameter for getRTSTime method with default value?

[alex-w]

Maybe exclude DebugAid flags from Release builds?

DebugAid should be available in Debug mode only

[alex-w]

A quick test: RTS time for planets give very strange results - like a double application of the time zone shift

[gzotti]

re1: One is public, the other is not. But that's easy to decide...
re2: Yes, target altitude should be possible. An advanced solution (possible around 0.14, maybe 2022...) would be taking the landscape horizon into account. This may be possible with some binary search in hour angle. But not in this branch.
re3: DebugAid: this comment is old, just the bot found it... I could exclude it from real STELLARIUM_RELEASE_BUILDs, but not Qt's "release" mode. However, these in-screen data displays are targeted for developing particular features, so they have to be commented away (or deleted) at end of branch development.
re4: (strange) I had hoped the interpolation wraparound zone fix would remedy that. Need another look.

I tried the "goto next setting" etc. functions on hotkey which are really nice in principle. While this version is usually much better (esp. Moon), the case where the solution provides times for the previous or next day needs to be discovered and solved. There are however 2 special cases: Sidereal day is 23h56m, so a star may rise twice on a single calendar day. And with moonrise/-set ~25 hours apart, the Moon may not rise/set on some particular date. If anybody has a worked-out solution or a better algorithm than Meeus (how dare you!), this could really help. We actually need to "find nearest event" (maybe with a way to flag it "will occur on next day only") and "goto next moonrise" (not "find moonrise date from algorithm, then set current date with that time").

[alex-w]

Still untested: behaviour on other planets.

Well, the calendars and duration of the day on extraterrestrial locations is separate big problem. :(

[alex-w]

I tried the "goto next setting" etc. functions on hotkey which are really nice in principle. While this version is usually much better (esp. Moon), the case where the solution provides times for the previous or next day needs to be discovered and solved. There are however 2 special cases: Sidereal day is 23h56m, so a star may rise twice on a single calendar day. And with moonrise/-set ~25 hours apart, the Moon may not rise/set on some particular date. If anybody has a worked-out solution or a better algorithm than Meeus (how dare you!), this could really help. We actually need to "find nearest event" (maybe with a way to flag it "will occur on next day only") and "goto next moonrise" (not "find moonrise date from algorithm, then set current date with that time").

Well, the special cases for the Sun on high latitudes also need to remember. :)

[gzotti]

Yes, indeed. This PR is currently only a partial fix. I think I should invent a different algorithm that starts with the current hour angle, find nearest transit, then estimates for rise/set from semidiurnal arc, with final solutions from binary search or those correction terms given by Meeus. And if sun rises above horizon in Polar summer, it will have a rise and transit time, but no more setting this day. The "next setting" call would switch to 24 o'clock of that day.

Not sure, do we accept this (maybe some more fixes?) for 0.21.2 and see to devise sth more complete ~ end of year?

[alex-w]

I think we may postpone implementing the special cases to other release.

[gzotti]

@alex-w How shall we report circumpolarity to the InfoMap? Return transit time (or lower culmination), or use a verbal annotation?

[alex-w]

Probably verbal annotation will be enough here

[lgtm-com]

This pull request introduces 1 alert when merging c3bf117 into 0647452 - view on LGTM.com

new alerts:

• 1 for FIXME comment

[github-actions]

Hello @gzotti! Please check the fresh version (development snapshot) of Stellarium:
https://github.com/Stellarium/stellarium-data/releases/tag/weekly-snapshot

[Atque]

Uh, I'm not sure if I'm missing something here, but selecting the Moon will give different rise/transit/set values over different times of the same day. Is that intentional?

[alex-w]

Uh, I'm not sure if I'm missing something here, but selecting the Moon will give different rise/transit/set values over different times of the same day. Is that intentional?

No, this is wrong

[gzotti]

There is a slight change in time by a few minutes if you are using topographic correction. For geocentric computation is should be stable. Given atmospheric vagaries the difference should be negligible. We accept better-working solutions in code :-)

[github-actions]

Hello @gzotti! Please check the latest stable version of Stellarium:
https://github.com/Stellarium/stellarium/releases/latest