Add Lunar Eclipses to Astronomical calculations

[worachate001]

Description

This PR partially addresses #407 by adding the method to search for lunar eclipses during user-input time span.

It shows:

• Date of time of greatest eclipse.
• Saros series
• Type of eclipses
• Penumbral and umbral magnitudes at greatest eclipse

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?

Test Configuration:

• Operating system: Ubuntu 20.04
• Graphics Card: NVidia Geforce RTX

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 (header file)
• I have updated the respective chapter in the Stellarium User Guide
• 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]

Great PR! Please pay attention to the following items before merging:

Files matching src/**/*.cpp:

• Are possibly unused includes removed?

This is an automatically generated QA checklist based on modified files

[alex-w]

I think the main tab should be named "Eclipses" and it should contains at least 2 "inner" tabs (similar to Graphs) - "Lunar eclipses" and "Solar eclipses". Probably "Solar eclipses" subtab in future may be splitted on 2 subtabs.

[worachate001]

I got the idea, it will take some time to add solar eclipse calculations in the second tab. I think I should make it to be draft for now.

[alex-w]

I got the idea, it will take some time to add solar eclipse calculations in the second tab. I think I should make it to be draft for now.

No need implement computation of solar eclipses right now in this branch, but prepared to compute it will be good step.

[alex-w]

Apparently the shortest way to preparation the support of both types of eclipses will be renaming the main tab to "Eclipses" at this step.

[alex-w]

I'm checked the work of tool with Astronomical Calendars and results is very good. Thank you!

So, the cosmetic fixes:

1. The phases data should be aligned to right side for improve readability and no need 4 digits for accuracy - 3 digits is enough (we use 1 digit after dot for percentage info about phases in infostring also)
2. The phase cannot be negative, so, all negative values should replaced by "dash" char (QChar(0x2014))

[alex-w]

Thank you very much!

[alex-w]

@gzotti I think it's ready to merge

[alex-w]

@gzotti please review the changes. I got accuracy around 1 second for my location.

@worachate001 is it possible to add a Gamma column also?

1.2.6. Gamma
The quantity gamma is the minimum distance from the center of the Moon to the axis of Earth’s umbral shadow cone, in units of Earth’s equatorial radius. This distance is positive or negative, depending on whether the Moon passes north or south of the shadow cone axis.

Source: https://eclipse.gsfc.nasa.gov/5MCLE/5MCLE-Text10.pdf

[worachate001]

Thanks for suggestions. While waiting for the reviews, I have been preparing the solar eclipse calculations and almost finish, it would be ready in a few days.

[gzotti]

Something is still weird. Please look here and compare with the list above.

What am I doing wrong? ΔT algorithm is set to default.

[alex-w]

@gzotti please share your config.ini file

ΔT algorithm is set to default and ΔT = 71.96 seconds (72 seconds on the NASA website). See for Barnaul location (UTC+00:00 and UTC+07:00 respectively):

[gzotti]

config.ini.txt
(renamed for github)

[alex-w]

config.ini.txt
(renamed for github)

ΔT = 72.73 seconds with your config.ini file... WTF?!? And n-dot value is -23.8000 - why?

[Atque]

@gzotti your config says that aberration is off. Could that be the reason?

[alex-w]

@gzotti your config says that aberration is off. Could that be the reason?

Yes, of course! After enabling aberration:

[gzotti]

@Atque, many thanks! Indeed. On one of my other tasks I had switched that off and was able to overlook it...

I also just checked with WSL. (Its default config.ini). It shows your values. So I welcome this addition, @worachate001 many thanks!

[alex-w]

@worachate001 I'll merge it now and I'll add changes from my comments in the master after merge.

[worachate001]

I just woke up in the morning here, so I missed everything. Thanks for additional improvements.

[github-actions]

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

[worachate001]

I have noticed that the time of greatest eclipse magnitude is always 1-2 seconds ahead of official time for every eclipses!. So it must be systematic errors -- the Moon is a little ahead of the location where it should be.

Is it possible that this may caused by the fact that aberration is not currently applied to the Moon?

[Atque]

@worachate001 It could be that Stellarium currently does not support diurnal aberration. I have noticed that lunar occultations are also off by 1 or 2 seconds when comparing to e.g. Cartes du Ciel (which takes diurnal aberration into account).

[alex-w]

Please see issue #2050

[worachate001]

In this window, no change of coordinates for the Moon when checked and uncheck. But for the Sun and planets, they changes. Is it normal?

[gzotti]

We have discussed that in summer. See #1626 . It seems that for the Moon aberration may be included in the ephemeris already.

I have modified the lunar position somewhat to reflect the difference between center of figure and center of gravity.
See EphemWrapper.cpp line 418. This explains exactly those 1-2 seconds, but should improve accuracy.

If diurnal aberration is noticeable in stellar occultations by the moon by more than 1 second or so, it may be worth considering. But it is not in my priority list.

[worachate001]

@gzotti Thank you for explanation. Modifying the Moon's position that way is really explain the differences. I have read that Astronomical Almanac is using this method but Fred Espenak decided to ignore it in his Catalog of Lunar Eclipses.

[gzotti]

Usually a difference of 2 seconds should not pose a problem in long-time eclipse canons, given uncertainties in ΔT. We would need a couple of (or rather a few thousand) securely timed (observed, not precomputed!) lunar occultations (intros and exits) to understand the limits of the current solution in Stellarium. I do not know the real figure offset between a perfect sphere and our tessellated (triangulated) polygonal Moon. See also discussion in #1959. Again, occultations are not my primary interest, but if somebody finds a solution for #1959, this would also be welcome of course. Anybody in IOTA reading this and and want to help? Of course, we have no model for the Lunar rim, so a difference with real-world conditions will likely persist. (I don't know if the (normal vector) displacement map can be interpreted and rendered in terms of real geometry to make the lunar rim appear jagged with the correct mountain silhouette. Or whether we can add a third texture with actual altitudes and let the GPU do geometrical displacement calculations (if this is at all possible in a fragment shader? Then a GPU could render highly accurate spherical primitives with displacement, even without any tessellation! But I expect overlapping results in some areas.))