Positions of Phobos and Deimos

[granthutchison]

So, how about the following:
- Add explicit ecliptical BodyFrames for the solar system bodies like the giant planets that currently don't use CustomRotations
- Modify the commented UniformRotation parameters of each object so that they're appropriate for whatever the object's BodyFrame is

I've now committed a version of solarsys.ssc revised on these terms. It should behave identically to the previous submission in which I fixed the orbits of Phobos and Deimos, but it now contains internally consistent declarations of BodyFrame and UniformRotation. I'll work on some of the other solar system files soon.

Some comments:
1) I've left Venus with its broken CustomRotation at present. If for some reason this proves difficult to fix, uncommenting UniformRotation will restore the correct orientation within the equatorial BodyFrame.
2) I notice Prometheus is a little misaligned since it received its CustomRotation. This seems to be because of a mismatch between the EllipticalOrbit period and the CustomRotation's period of rotation, since the error increases steadily with time. I'll see if I can update the orbit to fix this soon.
3) I wonder if there is a problem with Rhea's CustomRotation (or perhaps CustomOrbit). The moon is permanently tilted slightly out of alignment with Saturn, suggesting some fixed angular offset in one or other of its custom options.

Grant

[t00fri]

Grant,

it would be quite important to know ("for the books"), what kind of precision positional tests you actually did after your changes?

Thanks,
Fridger

[granthutchison]

Fridger:
I edited only rotational parameters.
For each body I still have the MathCAD sheet I used to convert standard IAU parameters to the then-current Celestia parameters.
I checked the original input parameters on the MathCAD sheet with the current IAU parameters, and the derived parameters on the MathCAD sheet with the UniformRotation data in solarsys.ssc (no errors found).
I then did a three-way comparison between the original Celestia UniformRotation parameters that you and I checked carefully, the more recent CustomRotation parameters, and the revised BodyFrame UniformRotation parameters I had just entered.
I did this using a number of Goto Object instructions from fixed locations at fixed times, checking the resulting latitude and longitude of arrival on each occasion.
On each occasion I ensured that my new parameters produced agreement, within the limits of the entered data, between the "old" parameters and my "new" parameters: let's now call these, communally, the "UniformRotation" parameters.
The "UniformRotation" parameters, old and new, were in agreement or I would not have accepted them. In most instances there were small-scale differences between the UniformRotation and CustomRotation parameters, as might be expected. When these differences were large, I investigated farther. I've already reported the CustomRotation problems with Venus, Prometheus and Rhea. There were also large differences with Mimas, but these were predictable because of Mimas' rather complex rotational behaviour, and I've tested the CustomRotation for Mimas in the past, finding that the CustomRotation is much better behaved than any UniformRotation.

Since almost all my changes were immediately commented out in favour of CustomRotations, they are purely for internal consistency and can have no effect on Celestia's behaviour. The exceptions are:
1) Explicit ecliptic BodyFrame declarations for Earth and the gas giants.
2) Explanatory comments on the existing (rather poor) rotational definitions for Janus and Epimetheus, which cannot be improved without first producing CustomOrbits for these bodies.
3) A shift of the rotational parameters for Phoebe and Triton, from body-centred to explicitly equatorial. For these two bodies I not only checked the data entry, mathematical derivation, and final orientation by Goto Object (as described above), I also reproduced the spacecraft encounters (Cassini and Voyager) to check the encounter orientations against published mapping and photographs.

I further checked that all active CustomRotations had been reinstated after my edits, and all inactive UniformRotations had been commented out, by specifically searching the final document for the relevant terms and checking their "comment" status.

Grant

[t00fri]

Grant ,

many thanks for your detailed explanations.

I must confess that after these massive discrepancies for Phobos, Deimos and other bodies were accidentally discovered, I was quite shocked about how few explicit positional tests have actually been done AND documented, despite previous massive code changes (frames etc) . This is certainly NOT a good strategy, given that "accuracy" is supposed to be a main stronghold of Celestia.

After spending decades in scientific research, I have learned ONE lesson: there is NO substitute to an explicit observable test, despite 1001 arguments why "nothing" could have gone wrong...

Fridger

[chris]

So, how about the following:
- Add explicit ecliptical BodyFrames for the solar system bodies like the giant planets that currently don't use CustomRotations
- Modify the commented UniformRotation parameters of each object so that they're appropriate for whatever the object's BodyFrame is

I've now committed a version of solarsys.ssc revised on these terms. It should behave identically to the previous submission in which I fixed the orbits of Phobos and Deimos, but it now contains internally consistent declarations of BodyFrame and UniformRotation. I'll work on some of the other solar system files soon.

Some comments:
1) I've left Venus with its broken CustomRotation at present. If for some reason this proves difficult to fix, uncommenting UniformRotation will restore the correct orientation within the equatorial BodyFrame.
2) I notice Prometheus is a little misaligned since it received its CustomRotation. This seems to be because of a mismatch between the EllipticalOrbit period and the CustomRotation's period of rotation, since the error increases steadily with time. I'll see if I can update the orbit to fix this soon.
3) I wonder if there is a problem with Rhea's CustomRotation (or perhaps CustomOrbit). The moon is permanently tilted slightly out of alignment with Saturn, suggesting some fixed angular offset in one or other of its custom options.

Grant

I found the problem with Rhea. There was a missing sin function. This line:

Code: Select all

return 235.16 + 79.6900478 * t - 1.651 - 3.08 * S7;


should instead be:

Code: Select all

return 235.16 + 79.6900478 * t - 1.651 - 3.08 * sin(S7);


[chris]

I checked the rotational elements for Prometheus here: http://astrogeology.usgs.gov/Projects/W ... able2.html ...and there are no typos in the values used for the CustomRotation. The rotation rate is 587.289000 degrees per day, or 0.612986 days/revolution. This agrees with the orbital period in solarsys.ssc to the four significant figures used in that file. Would extra precision in solarsys.ssc be adequate to fix the problem?

--Chris

[granthutchison]

I can't resolve the rotation parameters for Prometheus with its orbital elements: the prime meridian seems to be offset compared to the HORIZONS elements at epoch. Setting the orbital and rotation periods equal merely preserves the offset (although HORIZONS does now provide a mean orbital period of 0.612986 days, which is a good match). I'll play a little longer, but I'm guessing this is just a fundamental mismatch in the datsets, arising from the fact that both the orbit and rotation state are continuously evolving.
As I recall, this was the reason for the very basic rotational specifications I gave Prometheus, Pandora, Epimetheus and Janus when I first aligned the satellite prime meridians. The best solution seemed to be to ensure a "cosmetic" alignment with the orbital elements, rather than use conflicting snapshot data which produced bad results.

Grant

[chris]

I can't resolve the rotation parameters for Prometheus with its orbital elements: the prime meridian seems to be offset compared to the HORIZONS elements at epoch. Setting the orbital and rotation periods equal merely preserves the offset (although HORIZONS does now provide a mean orbital period of 0.612986 days, which is a good match). I'll play a little longer, but I'm guessing this is just a fundamental mismatch in the datsets, arising from the fact that both the orbit and rotation state are continuously evolving.
As I recall, this was the reason for the very basic rotational specifications I gave Prometheus, Pandora, Epimetheus and Janus when I first aligned the satellite prime meridians. The best solution seemed to be to ensure a "cosmetic" alignment with the orbital elements, rather than use conflicting snapshot data which produced bad results.

It sounds like it may be best to revert to using UniformRotation parameters for the Saturnian satellites without CustomOrbits.

--Chris

[granthutchison]

There's also a slight incongruity in having a CustomRotation for bodies with such as Enceladus and Dione, for which the USGS/IAU parameters merely describe a uniform rotation. The commented-out UniformRotation does exactly the same job as the CustomRotation for these bodies, but more transparently.

Grant

[chris]

There's also a slight incongruity in having a CustomRotation for bodies with such as Enceladus and Dione, for which the USGS/IAU parameters merely describe a uniform rotation. The commented-out UniformRotation does exactly the same job as the CustomRotation for these bodies, but more transparently.

There's still a precession term in the IAU elements for Enceladus and Dione. It's identical to the precession term for Saturn, so it could be omitted if the rotations of these satellites were defined in Saturn's equatorial frame and we used the IAU CustomRotation for Saturn. But, the latter isn't the situation right now because it would mess up the orbits of a bunch of Saturn's moons.

This brings up the question of what to do about the rotation of Saturn. Even though the precession of Saturn's rotational axis is small (0.36 degrees / century), it would be nice to switch to the IAU rotation model. But changing Saturn's rotation model and reference frame affects the orbits of all Saturnian satellites. I think that it makes sense to eventually (as in post-1.6.0) create new CustomOrbits for the satellites Mimas, Enceladus, Dione, Tethys, Rhea, Hyperion, Titan, and Iapetus in the Saturnocentric ecliptic frame. That's what the TASS 1.7 theory (which would be an improvement over the orbital theory currently implemented) appears to use anyway. The EllipticalOrbits for the other satellites would have to be updated for the modified Saturn equatorial frame unless we create versions of the IAU CustomRotations for use in the ecliptic frame. The fact that the orbits would be defined with respect to a moving equatorial plane should be a non-issue, as errors in the elliptical approximation would be much larger than those caused by the slight precession of Saturn's axis. We could also create EllipticalOrbits for use in the ecliptic frame--that might make the most sense if we use that frame for the Saturnian CustomOrbits.

As for Venus, I modified (locally) the IAUPrecessingRotationModel so that it:
1: sets a 'flipped' flag if the rotation rate is negative,
2: always reports a positive period, even if the rotation rate is negative

This 'flipped' flag was already implemented--it was getting set properly for the Uranian satellites, which is why their orientations closely matched the original (and also why I thought I'd handled all retrograde rotators.) I wanted to keep using the negative rotation rate in the code so that the IAU elements can be used directly, reducing the chance for errors.

Using the flipped flag fixes the gross errors, but still leaves about a tenth of a degree discrepancy with the current UniformRotation for Venus. Did you start with the IAU elements from http://astrogeology.usgs.gov/Projects/W ... able1.html ? Since there's no precession listed for Venus, it might make the most sense to stick with the UniformRotation. Either way, my changes to the C++ code should be implemented just in case someone does eventually use the iau-venus, iau-uranus, and iau-pluto CustomRotations.

--Chris

[granthutchison]

Using the flipped flag fixes the gross errors, but still leaves about a tenth of a degree discrepancy with the current UniformRotation for Venus. Did you start with the IAU elements from http://astrogeology.usgs.gov/Projects/W ... able1.html ?

I used the figures from the last Explanatory Supplement to the Astronomical Almanac, which was my source for the original rotation parameters. The web page data are newer, and differ in the second decimal place for Venus.

Grant Hutchison

[granthutchison]

Since there's no precession listed for Venus, it might make the most sense to stick with the UniformRotation.

OK.
If I don't see any objections, I'll restore the UniformRotation for Venus and restore the old "cosmetic" rotation parameters for Prometheus and Pandora (matching the meridian to the defined EllipticalOrbit).
I'll also make another pass to bring all the UniformRotation parameters into alignment with those listed at http://astrogeology.usgs.gov/Projects/WGCCRE/: a small number of bodies are affected by fractional degrees in the update, so it won't take long, and it will give complete consistency with the reference for CustomRotation provided in the solarsys.ssc header.

Code: Select all

# For most bodies, IAU rotational elements are used. These are implemented
# internally by Celestia and selected by using a CustomRotation. The IAU
# rotational elements are given here:
#  http://astrogeology.usgs.gov/Projects/WGCCRE/

Grant

[granthutchison]

Slightly delayed notice that I've now committed the above revision. Mainly small changes to trailing decimals, for the sake of consistency.
The major change is the reversion of Venus to UniformRotation: I've checked the result against JPL Horizons' predicted sub-observer latitude & longitude for a geocentric observer, with a match to the two decimals Horizons gives.
I've also update the position of the GRS on Jupiter, and checked against a suitable current ephemeris of GRS transits.

Grant