[Kstars-devel] [kstars] kstars/skyobjects: Fix the issue with rise / set / transit times of Jupiter's Moons

[Akarsh Simha]

Git commit 246bbaf948b6533b5730913ebb0ef5c89e5829c4 by Akarsh Simha.
Committed on 01/02/2015 at 10:22.
Pushed by asimha into branch 'master'.

Fix the issue with rise / set / transit times of Jupiter's Moons

Jupiters Moons are TrailObjects, and so riseSetTimeUT() calls
SkyPoint::updateCoords() -- the "vanilla" update of coordinates that
doesn't account for the motion of the planets.

Thus, one would have expected at least approximate rise/set times for
Jupiter moons to be displayed -- treating them as if they were objects
with fixed catalog RA0 / Dec0. However, we were displaying something
way off.

This is because we were setting current (RA, Dec) of the moons from
JupiterMoons::findPosition(), but we were not setting the "catalog"
(RA0, Dec0). Thereafter, SkyPoint::updateCoords() would happily call
precess() when it detected a sufficient change in JD, overwriting the
calculated (RA, Dec) with some junk that comes from precessing a junk
values of (RA0, Dec0) to the current epoch.

This patch calls SkyPoint::deprecess() to convert that (RA, Dec)
calculated in JupiterMoons::findPosition() to (RA0, Dec0) and resets
it appropriately, so that when SkyPoint::updateCoords() is called, it
writes out the (RA, Dec) computed back from this (RA0, Dec0), and not
some junk.

However, this is not perfectly accurate. For one, it seems like we
don't de-nutate. Besides, it looks like we never aberrate (is
aberration even relevant to planets?). So assuming that the nutation
and aberration are small enough, this yields a solution that's not
terribly off from what it should actually be.

Besides, we should actually be updating Jupiters' moons' rise / set
times as though they were planets, not as though they were generic
sky-points with fixed (RA0, Dec0). They would certainly move quite a
bit in the order of hours, so we should ideally implement a PlanetMoon
and JupiterMoon class and have a PlanetMoon::updateCoords(), even if
all it does is call JupiterMoons::findPosition().

CCMAIL: kstars-devel at kde.org

BUG: 340946

M  +4    -0    kstars/skyobjects/jupitermoons.cpp

http://commits.kde.org/kstars/246bbaf948b6533b5730913ebb0ef5c89e5829c4

diff --git a/kstars/skyobjects/jupitermoons.cpp b/kstars/skyobjects/jupitermoons.cpp
index 25a10d3..3e90503 100644
--- a/kstars/skyobjects/jupitermoons.cpp
+++ b/kstars/skyobjects/jupitermoons.cpp
@@ -482,6 +482,10 @@ void JupiterMoons::findPosition( const KSNumbers *num, const KSPlanetBase *Jupit
         Moon[i]->setRA( Jupiter->ra().Hours() - 0.011*( XP[i] * cos( pa ) - YP[i] * sin( pa ) )/15.0 );
         Moon[i]->setDec( Jupiter->dec().Degrees() - 0.011*( XP[i] * sin( pa ) + YP[i] * cos( pa ) ) );
 
+        SkyPoint p = Moon[i]->deprecess( num ); // FIXME: Really, we should also denutate. Actually, we should also be aberrating these above, right?
+        Moon[i]->setRA0( p.ra() ); // Just to be sure, in case deprecess doesn't set it already because RA0 was not NaN or something.
+        Moon[i]->setDec0( p.dec() );
+
         if ( ZP[i] < 0.0 ) InFront[i] = true;
         else InFront[i] = false;