search

cosinekitty / astronomy

Astronomy Engine: multi-language calculation of Sun, Moon, and planet positions. Predicts lunar phases, eclipses, transits, oppositions, conjunctions, equinoxes, solstices, rise/set times, and other events. Provides vector and angular coordinate transforms among equatorial, ecliptic, horizontal, and galactic orientations.
MIT License
496 stars 63 forks source link

Calculate the movement of Jupiter's moons #67

Closed cosinekitty closed 3 years ago

cosinekitty commented 4 years ago

It would be nice to calculate Jupiter's moons enough to predict how they appear in a telescope.

cosinekitty commented 3 years ago

Note for later research: @gerben-b suggested looking at Stellarium source code for ideas about how to calculate this.

cosinekitty commented 3 years ago

@meshula reported these Go implementations:

https://github.com/soniakeys/meeus/tree/master/v3/jupitermoons

https://github.com/soniakeys/meeus/tree/master/v3/saturnmoons

cosinekitty commented 3 years ago

Stellarium calculates the movement of Jupiter's moons in the following source file: https://github.com/Stellarium/stellarium/blob/master/src/core/planetsephems/l12.c

This is a port of Fortran code from the L1.2 theory by Valery LAINEY, Alain VIENNE and Luc DURIEZ: https://ftp.imcce.fr/pub/ephem/satel/galilean/L1/L1.2/

cosinekitty commented 3 years ago

I have finished the first pass of calculating the position and velocity vectors of Jupiter's moons in the jupiter_moons branch. See ef4284159274ba9ff7b643746c5b40efc30e8abe. Before merging into the master branch, I'm considering whether I should provide additional features that would be useful to programmers in this area:

matheo commented 3 years ago

(Awesome stuff Don! I admire your skills :clap:)

meshula commented 3 years ago

Awesome!

The light travel delay is interesting, although I'm not a fan of Meeus' method of baking it into the ephemeris calculation directly. I feel like the "gravity well" effect is interesting and important, but rather an orthogonal aspect, in the imaging realm, rather than the astromechanical realm. My use case for astronomical calculations is for arbitrary points of view, not just for terrestrial observations. So personally, if there are to be relativistic computations, I'd rather have a routine to which can be provided a computed ray, and receive an intersection point and gravity-refracted ray as a result. I suppose most rays would trivially return the supplied ray. So my preference is to omit the feature, as in my opinion, it's implemented in an unnecessarily restricted place in Meeus.

With regards to the pole, coordinate system computations for Jupiter are extremely useful, especially for people working with Juno data. https://lasp.colorado.edu/home/mop/files/2015/02/CoOrd_systems7.pdf System III and VIP4 are both interesting. The other coordinate systems are derivable from computations already in your library, I think. If the astronomy library has a System III computation available, the north pole vector for TA is computable from it...

cosinekitty commented 3 years ago

@meshula Thank you for the perspective and information. They are helpful. I agree that I don't want to make too many assumptions about how the calculations are going to be used. With regard to light travel time, I would not force this on anyone. One way or another, it will be an option, because the intent is to provide the actual "instantaneous" state of objects.

Also, the light travel corrections I'm talking about will be strictly about backdating positions for the amount of time it takes light to travel from the Jupiter system to the Earth. My existing code also can optionally correct for aberration. However, I won't address relativistic effects of spacetime curvature or time dilation, because those effects are far smaller than my existing 1-arcminute error tolerances.

Currently, the GeoVector functions do correct for light travel time, which seemed reasonable at the time. The idea was, if you are asking for vectors from the Earth, you are probably wanting to know how things appear from the Earth's point of view. I am pondering expanding the aberration enumeration parameter for these functions. Currently aberration either enables or disables aberration, but I could provide a third option to eliminate light travel time backdating as well. It's not clear to me whether this would be more helpful than confusing for most people.

I'm thinking GeoVector should probably provide an additional output for the amount of backdating time, not just the final vector. That way, someone could call GeoVector for Jupiter, then use the delta-time value to backdate the call to JupiterMoons. Even though Jupiter and its moons are all at slightly different distances from the Earth, this would probably be good enough for creating an accurate picture of the whole Jupiter system from the Earth's point of view. This additional return value would be a breaking change, at least for C and C# developers, because I would have to change the function's return type. I suspect the impact would be minimal, and there is a strong case for doing so.

About Jupiter's pole: I will take a look at the document you linked later, but for now... I don't know anything about Jupiter's spin behavior. Does it precess/nutate appreciably over time? I wonder if I can just use the fixed pole model from the L1.2 model. They treat Jupiter's equator as fixed with provided inclination and ascending node angles.

Any thoughts are most welcome!

meshula commented 3 years ago

A GeoVector that corrects for travel time makes sense to me; as I mentioned I'm biased to thinking in instantaneous extraterrestrial frames :)

The precession/nutation of Jupiter's spin is I think an ongoing discovery process. FWIW my personal interest is in being to able to translate into the 1965 model in the linked paper, because I very occasionally help de-warp Juno images, which involves WAY too many coordinate embeddings :)

The last thing I've seen is that Juno was meant to measure precession, but I haven't heard how it turned out. https://ui.adsabs.harvard.edu/abs/2016P%26SS..126...78L/abstract

cosinekitty commented 3 years ago

I think I solved my dilemma about how GeoVector can return the amount of light travel time, without harming backward compatibility. I will add an additional field to the time data structure (e.g. astro_time_t in the C version) that I will call lt for light-travel, which will be the fractional number of days into the past the light-travel solver converged on.

The nice thing about this approach is that the vector value returned by GeoVector contains a time object, and the lt will be right there: vector.t.lt. The function's return type will not change, nor will its parameters. In other functions where I don't solve for light travel time, I will always set lt to zero.

Then software wanting to draw a picture of Jupiter and its moons as seen from Earth can call GeoVector to get the light-travel corrected position of Jupiter as seen from Earth, then use lt to backdate the time passed into JupiterMoons.

cosinekitty commented 3 years ago

Hmm... or even simpler... Maybe the caller can just take the length of the light-travel-corrected geocentric vector (in AU) and divide by the speed of light (173.1446326846693 AU/day) to get the time it took for the light to reach the Earth. I will write a demo program to illustrate this. I think this is even better than changing the time object.

cosinekitty commented 3 years ago

I have split out calculating Jupiter's rotation axis into a new issue: #106 . I found formulas for calculating the north pole vectors for all of the major planets and moons of the Solar System.