Added geographic coordinates of center line for total and annular solar eclipse

[worachate001]

Description

This added method for calculation of geographic coordinates where we can see total or annular eclipse. Predicted coordinates may not be very accurate because changing value of deltaT (TT-UT1).

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: Windows 10

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

[worachate001]

It looks like I should use the command git rebase master before sending a pull request, right?

[alex-w]

Please see lines 901-916, which already using for solar eclipses. I think your code can be moved into separate private method with return Vec3d(lat, lon, dratio) value and used within block if (onEarth && obj==ssystem->getMoon()) to reduce calculations and avoid possible slowing work of the Stellarium (on powerless PC), when the Sun is selected.

[alex-w]

It looks like I should use the command git rebase master before sending a pull request, right?

It's not needed in this case

[gzotti]

Thank you for writing these functions. But please take into account that Stellarium still has no complete aberration correction. I did some trickery to match local contact times in the simulation, but would have solved aberration before tackling these high-accuracy problems. In any case make sure to document your code (have not checked now), so that it can be understood and maintained.

On the other hand, the built-in default DeltaT should be perfectly usable. A perfect solution should agree to the second with some expert reference, of course, and divergences can be helpful to identify errors still hidden somewhere.

[alex-w]

@worachate001 I've reviewed your code again and I have a question: are you wanting to show an eclipse info since the moment of eclipse startup anywhere on Earth or for current location? If you planned to show an eclipse info not dependent on the current location then my proposal about call calculations within the block if (onEarth && obj==ssystem->getMoon()) was wrong.

[worachate001]

@worachate001 I've reviewed your code again and I have a question: are you wanting to show an eclipse info since the moment of eclipse startup anywhere on Earth or for current location? If you planned to show an eclipse info not dependent on the current location then my proposal about call calculations within the block if (onEarth && obj==ssystem->getMoon()) was wrong.

Yes. My intention at first is not depend on location. If you think moving out of that block is okay (not too much calculations going on when selecting the Sun), I'm happy to move them again.

[alex-w]

Oops... sorry for my bad suggestion, please move them again.

I have a new one question now. You are creating a special class for calculating the central point of the eclipse, but some part of calculation is outside the method of the new class. What reasons did you not move all required code into one method?

[worachate001]

I see what you mean. I will do some testing and will send the updated code again when ready. Thanks for suggestions.

[worachate001]

I carefully compared Stellarium's results with some solar eclipses in the past, present, and future (in NASA web site - https://eclipse.gsfc.nasa.gov/SEcat5/SEcatalog.html) by using the same DeltaT for each dates.

Despite incomplete implementation of aberration, the results are very close except a few minutes near the beginning and end of central eclipse (when the Sun is very close to the horizon) and eclipses that occur near the poles.

Main things that affect accuracy of center line prediction:

• different values of true vs predicted DeltaT
• positions of the Sun and Moon
• aberration, nutation and obliquity of ecliptic - they have small values but can cause large shift of shadow on Earth

My observation:

• gradually disabled of nutation before the year 1500 in Stellarium makes noticeable differences in position of the Sun and Moon compared with JPL HORIZONS, fully activate nutation may be better
• I will try to further investigate and find ways to improve Sun & Moon positions

[gzotti]

Hi! Thank you for these observations. TSE are certainly cases where computational models and their correct application, or errors of doing so, are most obvious. I am just a bit conservative w.r.t. effects of nutation as I could not find indications of a time frame of validity for the model. If the model is safe for +/- 2000.0 or even 10.000 years or more, we can change that of course, but I'd like to have some confirmation on this.

A few weeks ago somebody remarked our nutation matrix is wrong. See Planet::computeTransMatrix(). I followed one paper, that reporter mentioned a different source. Without a critical case, I cannot decide it, given the other small errors. You could play with the sign of the deltaPsi rotation to see if one is better.

See also StelObserver::getTopographicOffsetFromCenter(). Any error here will also shift things.

See also SolarSystem::computePositions() about the TSE hack which hides the aberration error for TSE. Another critical case to test is Venus occultation on June 19th, 2020.

[alex-w]

I checked 2 solar eclipses for this year and found small difference for coordinates of central point, but not for time and magnitude.

[alex-w]

@gzotti please review the patch

[gzotti]

You could add great-circle distance to observer. I thought we had it implemented already, but now I see only StelLocation::distanceDegrees(). We could add double StelLocation::distanceKm(long1, lat1, long2, lat2), following Meeus, Astron. Algorithms (2nd ed 1998) ch.11, p.85. If you don't have the book, I can do it.

[gzotti]

I just added such a function to StelLocation. It may even be interesting to say: "Shadow centerpoint is 45km towards azimuth 63°". The azimuth function can be taken from ArchaeoLines::getAzimuthForLocation().

[alex-w]

@gzotti ArchaeoLines may be not loaded ;) Maybe move getAzimuthForLocation() into StelLocation class?

[gzotti]

Yes, I meant not "use Archaeoline's function", but "grab code". Indeed, when used elsewhere, this function should be moved, e.g. to StelLocation or StelUtils.
@worachate001 I am sorry I also implemented the missing bit, now we have a conflict. My implementation is more general, so I'd prefer to keep this. You can move the static functions Archaeolines::getAzimuthForLocation() as Alexander suggested to StelLocation, adapt ArchaeoLines accordingly, and maybe add the non-static function StelLocation::AzimuthForLocation(). I think these make interesting additions!

[worachate001]

Thanks for suggestions. I'm not sure that the "Resolve conversation" button is for me or for you. I think I have done all of your suggestions. Feel free to suggest more, Visual C++ Programming is new for me.

[gzotti]

@worachate001 Great new feature, many Thanks!