Calendar on ecliptic

[rayw000]

Description

Fixes #2175

Screenshots (if appropriate):

Help wanted:

Is there any function which I could use to get the ecliptic longitude of the sun on a specific Julian day? I didn't find it, so I divided the ecliptic equally into 365 (366 if leap year) pieces. As we known that the earth moves at different angular velocities in different seasons on ecliptic, equally dividing would cause bad precision. Sometimes there would be up to 2 days deviation.

Many thanks!

I've tried to use earth->getEclipticPos(<JDE>) to get the Vec3d position of earth, and calculate the differences of each adjacent days, and use them as the steps to split the ecliptic, but the differences are widely variable. I possibly misunderstand something.

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: macOS Monterey 12.0.1

• Operating system: macOS Monterey 12.0.1
• Graphics Card: Apple M1 Max built-in

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

[gzotti]

Rather use earth->getEclipticPos(JDE); for each consecutive day of the year (or use "today -182" to "today+183" or so)? This may become slow, though. Probably it will be needed to compute earth's position without the rest of the solar system.

The ecliptic otherwise can be just marked in 360 regular degrees which allow a good estimate of motion.

[rayw000]

Rather use earth->getEclipticPos(JDE); for each consecutive day of the year (or use "today -182" to "today+183" or so)? This may become slow, though. Probably it will be needed to compute earth's position without the rest of the solar system.

The ecliptic otherwise can be just marked in 360 regular degrees which allow a good estimate of motion.

Thank you @gzotti

Marking the ecliptic in 360 regular degrees starting from Jan 1st is my current implementation. But due to variable angular velocity the earth moves at, there may be up to 2 days deviation from the position the sun should be in on the ecliptic.

How would you think if we mark the solstices and the equinoxes with dates, and divide each three months between them? This would give better precision than just equally dividing the whole ecliptic.

[rayw000]

I pushed a new commit. I divided the half year from autumnal equinox to spring equinox into 178 (179 if leap year) pieces, while spring equinox to autumnal equinox into 187 pieces. Now we have a better approximation, with deviations no more than 1 day.

[rayw000]

Feature is done. Commits are squashed.

This PR decreases the code coverage of file GridLinesMgr.cpp from 11.458% to 11.452% (60 new lines). I didn't see the function void SkyLine::draw(StelCore*) const called in any unit tests. Should we ignore this failing check?

[alex-w]

Should we ignore this failing check?

Yes

[alex-w]

A quick check: today 10 February, 19:00 UTC+7 - on the screenshot you may see end of 9 February:

[rayw000]

A quick check: today 10 February, 19:00 UTC+7 - on the screenshot you may see end of 9 February:

The right span of 10 is Feb 10. The date label is at the end of the day, for example Feb 1 starts at the Feb mark and ends at the first short mark. It is the expected behavior.

The biggest two deviations are around the end of May and Nov. You could check if they are acceptable.

[alex-w]

OK, the solution is acceptable for me.

@gzotti?

[gzotti]

I have not checked yet and can do that only later: What about GravityLabels, and what about long-time errors from assuming the perihel is always near (north) winter solstice? What happens in 1582 ;-) ? The optimal solution would of course draw strict day (0h) marks in observer local time (as suggested, -182...+183 from "now" (maybe with a cache of JD/values), but at what cost?

[rayw000]

I have not checked yet and can do that only later: What about GravityLabels, and what about long-time errors from assuming the perihel is always near (north) winter solstice? What happens in 1582 ;-) ? The optimal solution would of course draw strict day (0h) marks in observer local time (as suggested, -182...+183 from "now" (maybe with a cache of JD/values), but at what cost?

Great points!

GravityLabels could be a good idea. I'll do it if we consider it a better choice.
Perhaps drawing strict day marks from "now" would cause larger deviations at the other side of the ecliptic?

[alex-w]

@gzotti you are right, I see strange results in the past!

[rayw000]

Splitting into 178+187 pieces is not precise, but just cheap.

[rayw000]

I've tried to get the Vec3d position p of earth and calculate the differences between each two consequent acos(p[0]). It has bad precision near 0 and Pi.

[gzotti]

Perhaps drawing strict day marks from "now" would cause larger deviations at the other side of the ecliptic?

The opposite side of the ecliptic is of course where the open ends will fail to connect visually smoothly. There will be two marks 1/4 or 5/4 degree apart, and the pair will run in-sync with the sun. However, it is the least-interesting point to look at on this scale.

Older installations, like the optomechanical planetarium, of course have to use some "average" scale, usually showing days 2 years past leap years to keep the error minimized. But computers can do better :-)

To create the lines accurately, the solar position should be computed not by setting StelCore->setJD(), doing all the heavy computations for all objects, but with the underlying functions. If this is left as exercise to myself, we can accept this now and improve it later. However, are GravityLabels solved?

[rayw000]

However, are GravityLabels solved?

If I read correct, do you mean we should make the ecliptic labels behave like constellation names?

[gzotti]

I've tried to get the Vec3d position p of earth and calculate the differences between each two consequent acos(p[0]). It has bad precision near 0 and Pi.

Not sure what you mean. You would need earth's position, and derive Solar position as -earth. But 365 times on 365 dates per full circle. Therefore I recommend caching the results, so as long as you don't simulate millennia at a time, the step coordinates will mostly be re-used.

[gzotti]

However, are GravityLabels solved?

If I read correct, do you mean we should make the ecliptic labels behave like constellation names?

Yes. Switch on the planetarium distortion mode in the settings menu and see how all texts are now oriented so that they would be readable when projected onto a planetarium dome.

[rayw000]

Not sure what you mean. You would need earth's position, and derive Solar position as -earth.

Yes, that's what I've tried. This should give us only 365 positions for each 0h, e.g. [-0.999935, y, z]. The first element could range from -0.999xxx to 1.03xxx. I think their (normalized) acos value could be used as the coordinates on the ecliptic.

[rayw000]

Yes. Switch on the planetarium distortion mode in the settings menu and see how all texts are now oriented so that they would be readable when projected onto a planetarium dome.

It could be done by passing fixed values to StelPainter::drawText. Am I right?

[rayw000]

Yes. Switch on the planetarium distortion mode in the settings menu and see how all texts are now oriented so that they would be readable when projected onto a planetarium dome.

It could be done by passing fixed values to StelPainter::drawText. Am I right?

Oh, you mean it should be responsive to the settings menu. I'll do some research.

[rayw000]

Yes. Switch on the planetarium distortion mode in the settings menu and see how all texts are now oriented so that they would be readable when projected onto a planetarium dome.

I know what you mean.lol

[gzotti]

Not sure what you mean. You would need earth's position, and derive Solar position as -earth.

Yes, that's what I've tried. This should give us only 365 positions for each 0h, e.g. [-0.999935, y, z]. The first element could range from -0.999xxx to 1.03xxx. I think their (normalized) acos value could be used as the coordinates on the ecliptic.

Not so fast... These are J2000 rectangular (Cartesian) ecliptical coordinates. We have to apply precession/nutation/aberration to current date to make them usable for the "ecliptic of date".

[alex-w]

The right span of 10 is Feb 10. The date label is at the end of the day, for example Feb 1 starts at the Feb mark and ends at the first short mark. It is the expected behavior.

This is a little weird. I’m checked hard copies of celestial maps and I didn’t find similar markings. This behaviour will confusing users.

[rayw000]

The right span of 10 is Feb 10. The date label is at the end of the day, for example Feb 1 starts at the Feb mark and ends at the first short mark. It is the expected behavior.

This is a little weird. I’m checked hard copies of celestial maps and I didn’t find similar markings. This behaviour will confusing users.

Or, we can put the label on the top middle of each span, something like

      3           2          1      Feb
|-----------|-----------|-----------|

[rayw000]

This is a little weird. I’m checked hard copies of celestial maps and I didn’t find similar markings. This behaviour will confusing users.

@alex-w Done.

[gzotti]

We have found an accurate solution (#3057), but thank you for your interest!