Positions of Phobos and Deimos

[BobHegwood]

Thanks for your help, just call me Brain Dead Bob #2

[Vincent]

Vincent:

I was reporting what I thought may be another orbital problem,
not a Lua tools problem. I know that mixing the two may have
caused confusion, but I was more concerned about the reported
position than the Lua tools themselves.

I have installed the Lua tools 1.2 Beta and of course it doesn't show
your position so that point is moot.

Thanks for your help, just call me Brain Dead Bob #2

AstroNut

AstroNut,

No problem. I just want things to be clear between the Celestia standard distribution
and addons like the Lua Tools. This to avoid any confusion we could have in the past...

[chris]

Now, the puzzling thing to me is that the CustomRotations are all very close to the old UniformRotations. The positions of Phobos and Deimos will be different, but not dramatically so. The CustomRotations are producing correct correct results, but it seems that equatorial plane for the CustomRotation different than it is for the nearly equivalent UniformRotation.

Chris, the equatorial plane seems to be pretty much the same, as we'd expect since CustomRotation is a good match for UniformRotation at this epoch.

Pardon my carelessness--I actually meant the equatorial transformation, not the plane. You're correct that the plane has not changed.

What has changed is the zero point for orbital longitude within the equatorial plane. As I said above, Celestia used to use the ascending node of the planet's equatorial plane on the celestial equator. Since Horizons provided body-centred elements using the ascending node of the planet's equatorial plane on the ecliptic, we needed to use a planet-specific offset in the longitude of the ascending node to convert from Horizons to Celestia.
The need for this offset has vanished with the introduction of CustomRotation, if Mars is anything to judge by: I now need to use standard Horizons data to position Phobos and Deimos correctly.

OK, this all makes sense now. Except, I think that HORIZONS gives body-centered elements using the ascending node of the planet's equatorial plane on the Earth equator of J2000. From the HORIZONS docs:

Body mean equator and node of date

Reference epoch: "of date"
Reference plane: ICRF/J2000.0 or FK4/B1950.0
xy-plane: central-body mean equator plane at reference epoch
x-axis : out along the ascending node of the central-body mean equator
plane on the reference plane at the reference epoch
z-axis : along the central-body mean north pole at the reference epoch

I think that the reference plane refers to the Earth mean-equator of J2000 (or B1950 if you chosen that frame.) This is consistent with the fact that the HORIZONS generated elements don't need adjustment with the CustomRotations: because the CustomRotations defined in the EquatorJ2000 frame, the zero point should be the ascending node of the body equator on the Earth mean-equator of J2000.

My first check above was just done by eyeball, but I've now confirmed with some precision. Below is an ssc containing dual definitions for Phobos and Deimos. Those suffixed "Body" use pure Horizons data in EllipticalOrbits tied to the new CustomRotation. Those suffixed "Ecliptic" use pure Horizons data in an Ecliptic2000 OrbitFrame. The positions of the bodies match almost exactly using these definitions, indicating that the loss of our old nodal offset is the origin of the displacement in orbital position when UniformRotation is replaced with CustomRotation.

So I'm guessing you need to be looking at a difference in equatorial node definitions between UniformRotation and CustomRotation.

Thanks for verifying this. It seems like we completely understand the source of the differences. If we want to the new CustomRotations to behave more like the old UniformRotations, I could redefine them to include the transformation from the EquatorJ2000 to EclipticJ2000 frames. Then, we could remove the "BodyFrame { EquatorJ2000 {} }" lines from solarsys.ssc. However, this is more work than just modifying the orbital elements of Phobos and Deimos in solarsys.ssc, and doesn't seem to do anything. Indeed, it seems advantageous that using the CustomOrbits as-is means that less work is required in adapting HORIZONS results for Celestia.

--Chris

[granthutchison]

OK, this all makes sense now. Except, I think that HORIZONS gives body-centered elements using the ascending node of the planet's equatorial plane on the Earth equator of J2000. From the HORIZONS docs:

Yes, you're right, I got it backwards. It's been a few years ...

Grant

[granthutchison]

I do share Andrew's concern about the inconsistency arising from the commented-out UniformRotations.
For instance, at present we have the following to define Mars' rotation state:

Code: Select all

   BodyFrame { EquatorJ2000 {} }
   CustomRotation "iau-mars"

   # Overriden by CustomRotation
   # UniformRotation
   # {
   #    Period                24.622962
   #    Inclination         26.72
   #    AscendingNode    82.91
   #    MeridianAngle       136.005
   # }

But if we remove the CustomRotation and restore the UniformRotation, we see a very marked change in appearance, both of Mars and its satellites. If we remove BodyFrame and CustomRotation and restore UniformRotation, Mars looks pretty much the same, but its satellites shift position as we've been discussing.
It seems to me that what is properly overriden by CustomRotation is code of this form:

Code: Select all

   UniformRotation
    {
       Period                24.622962
       Inclination         37.114
       AscendingNode   47.681
       MeridianAngle       176.868
    }

That is, a UniformRotation set up in the same equatorial BodyFrame as the CustomRotation, so that the two can be interchanged with no effect on the satellites, and minimal effect on the rotation state and orientation of Mars.

At present, CustomRotations are formally setting some of the planets to an equatorial BodyFrame, while other bodies retain a (non-obvious) ecliptic frame. It strikes me that a completely consistent solution requires us to propagate an "equatorial standard" throughout the solar system, with formal declarations of that BodyFrame for each object, appropriate revisions of the rotation parameters, and revisions of the satellite orbits.
It's a big job, but it would give a much more consistent and transparent final product.

Grant

[chris]

I do share Andrew's concern about the inconsistency arising from the commented-out UniformRotations.

At present, CustomRotations are formally setting some of the planets to an equatorial BodyFrame, while other bodies retain a (non-obvious) ecliptic frame. It strikes me that a completely consistent solution requires us to propagate an "equatorial standard" throughout the solar system, with formal declarations of that BodyFrame for each object, appropriate revisions of the rotation parameters, and revisions of the satellite orbits.
It's a big job, but it would give a much more consistent and transparent final product.

I agree that it would be good to improve the consistency of the definitions in solarsys.ssc. However, one thing that I'd really rather not do at this point is to change the code in customorbit.cpp so that the orbits of the Galilean, Saturnian, and Uranian satellites are a different coordinate system. I'd rather save such changes for *after* 1.6.0 rather than risk messing something up.

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
- Modify the EllipticalOrbits for Phobos and Deimos so that they work with Mars's CustomRotation

After 1.6.0 release, we can investigate implementing improved theories for the orbits of the Solar System's major natural satellites, or simply adapting a single, inertial frame for the existing ones.

--Chris

[ajtribick]

Sounds like a good idea until we come up with a better plan.

Bare minimum is fixing Phobos+Deimos, which is the most urgent task here.

[granthutchison]

Sounds like a good idea until we come up with a better plan.

Bare minimum is fixing Phobos+Deimos, which is the most urgent task here.

I already have Phobos and Deimos fixed on my local copy, but I haven't committed because I was hoping to plough through the other changes as well. These latter require a degree of care, to make sure they work properly and I don't break anything else.
I'm experiencing a few Life Events at present, so I'm making only slow progress. But I can easily commit the bald Phobos/Deimos fix if there is some urgency.

Grant

[chris]

Sounds like a good idea until we come up with a better plan.

Bare minimum is fixing Phobos+Deimos, which is the most urgent task here.

I already have Phobos and Deimos fixed on my local copy, but I haven't committed because I was hoping to plough through the other changes as well. These latter require a degree of care, to make sure they work properly and I don't break anything else.
I'm experiencing a few Life Events at present, so I'm making only slow progress. But I can easily commit the bald Phobos/Deimos fix if there is some urgency.

I think it's worth fixing Phobos and Deimos right away, if it's not too much trouble. It can of course wait if you've got too much else going on right now.

--Chris

[granthutchison]

OK. The new Phobos and Deimos orbits have been committed. I've used epoch 2010 to give us reasonable accuracy over the next couple of years.

Grant

[chris]

OK. The new Phobos and Deimos orbits have been committed. I've used epoch 2010 to give us reasonable accuracy over the next couple of years.

Grant

Thanks so much, Grant!

--Chris

[ajtribick]

Thank you!

[jogad]

Hello

I have installed the new orbits and compared them with those in Celestia 1.5.1. They are a little different. As an example here is a view of Deimos seen from the same point on Mars (here).

The left picture is shown in Celestia 1.6.0 with the new orbits and the right in Celestia 1.5.1.



The difference is clearly visible to the naked eye and the distance between positions is more than 1000 km.

I wonder what is the actual accuracy on the positions?

Thank you.

[granthutchison]

Accurate at epoch, less accurate the farther you move from epoch. This is always the case for EllipticalOrbit definitions.
The previous orbits were epoch 2000, so were getting progressively less accurate with time; the new orbits are epoch 2010, so should actually get better for the next year.
(For best positional accuracy, I've used some mean elements. In particular, using the period supplied with the osculating elements at epoch generates a progressive drift in position that can be avoided by using the mean period.)

Grant

[jogad]

Thank you very much for the care that you have taken to provide the best possible accuracy and for the kind explanation about it.

[granthutchison]

CustomRotation has also broken Venus.
The original definition for this planet used an "anticlockwise rotation" definition for the north pole, which was a Celestia standard across the data files. The new CustomRotation evidently uses the IAU "north of the ecliptic" definition.
So the planet has been turned upside down. The planetographic grid is the wrong way up (aligned with the inverted textures), and the quoted latitude and longitude values of all features have been flipped N-S and E-W.

Fixing this with the current CustomRotation will require a texture flip for surface and clouds, a revision of the location files, and some recoding for the planetographic grid and how location data are parsed. There are then obvious consistency issues across the other retrograde rotators.
Converting the CustomRotation to Celestia's standard would avoid these extensive knock-on effects, but I've no idea how easy that would be. Chris?

Quick and easy fixes would be simply to restore the original ecliptic UniformRotation, or to set up a new UniformRotation in equatorial coordinates.

Grant

[ajtribick]

The display of the rotation period of Venus as a large negative number of seconds ought to be fixed too.

[granthutchison]

The display of the rotation period of Venus as a large negative number of seconds ought to be fixed too.

It's part of the same problem. With the IAU's choice of north, the period is necessarily negative. With Celestia's choice of north, we don't have negative periods, so the code's not coping very well.
In retrospect, the appearance of the negative period (with the attendant handling error expressing the period in seconds) should have alerted us that all was not well with Venus after the introduction of CustomRotation.

Whether or not we fix this by removing the negative rotation period, I suppose users may enter negative periods for their own purposes. I'd guess fixing the code would be as easy as ensuring that the choice of units is made according to the magnitude of the absolute value of period, rather than the actual value.

Grant

[t00fri]

Negative periods are certainly physical nonsense...This is a convention-independent fact

Fridger

[chris]

CustomRotation has also broken Venus.
The original definition for this planet used an "anticlockwise rotation" definition for the north pole, which was a Celestia standard across the data files. The new CustomRotation evidently uses the IAU "north of the ecliptic" definition.
So the planet has been turned upside down. The planetographic grid is the wrong way up (aligned with the inverted textures), and the quoted latitude and longitude values of all features have been flipped N-S and E-W.

Fixing this with the current CustomRotation will require a texture flip for surface and clouds, a revision of the location files, and some recoding for the planetographic grid and how location data are parsed. There are then obvious consistency issues across the other retrograde rotators.
Converting the CustomRotation to Celestia's standard would avoid these extensive knock-on effects, but I've no idea how easy that would be. Chris?

Quick and easy fixes would be simply to restore the original ecliptic UniformRotation, or to set up a new UniformRotation in equatorial coordinates.

I thought I'd accounted for the flipping when I implemented CustomRotations. I'll have a look at the code again--it should be easy to fix. There's certainly no need to modify the existing textures and locations.

--Chris