Positions of Phobos and Deimos

[t00fri]

Well the Moon's orbit is explicitly defined to be in the EquatorJ2000 frame and the Moon is located in the same place under the 1.5.1 and 1.6.0 definitions of the Earth's rotation, which implies that in addition to the problems with the Keplerian orbits, the CustomOrbit needs to be looked at.

In summary, aaaaargh.

++++++++++++++++++++++++++++
I am sorry, these tests are tricky . In my first test of the Saturn-by-Moon occultation from March 2nd 2007, something must have gone wrong (perhaps the location I took was a bit too far away: London ):

See my revised Celestia 1.6.0SVN test edited appropriately in my above post!
The accuracy of Moon's orbit seems pretty good, in fact
++++++++++++++++++++++++++++

Fridger

[t00fri]

This is even more amazing: I next picked a location in England, where the occultation of Saturn should be grazing!


Indeed, choosing Birmingham/UK, I find THIS:



Fridger

[ajtribick]

Well that's a relief!

[t00fri]

Well that's a relief!

Indeed! These occultation tests are actually quite fun, since there are great photos and many very accurate data available.

Fridger

[t00fri]

The real challenges are the many possible satellite event tests in the Saturnian and Uranus systems! There are also many good photos from striking constellations of many Moons that are excellent for comparisons...

Another critical series of tests concerns the location of the Great Red Spot on Jupiter.
Here is a nice example that I did in 2002



Note that BOTH the location of the RedSpot AND the 2 moon shadows match VERY well.
No idea whether this good agreement still holds in today's Celestia 1.6.0SVN ?


Fridger

[cartrite]

Isn't there big differences in the cel url's from versions 1.4.1, 1.5.1 and 1.6.0? I seen a couple of times in this thread that cel url's were being used to transfer settings between the various Celestia versions. I would think that this wouldn't work. All the times, locations, etc. should probably be entered manually in each Celestia version instead of using cel url's.
This does look like a big set back to the release of 1.6.0 though.
cartrite

[jogad]

Very nice pictures!

With regard to the Moon, my own measurements of the positions between versions show that there is no significant difference between v1.5.1 and v1.6.0
Between v1.4.1 and 1.5.1 the difference is small (few kilometers) but real. (I take the difference in absolute coord after some corrections and the precision is less than 1 meter).
But the ChangeLog.text said:

1.5.0
…
* Improved custom orbits based on JPL ephemerides:
- Support big endian platforms
- Fixed Moon orbit
- Added orbits for Earth-Moon barycenter and sun
- Added heliocentric and solar system barycentric orbits

So I think that explain the difference.

But for spacecrafts the difference with version 1.4.1 and the next ones is big and the cause is the update of the Earth’s inclination.

And now I must go to work…
Cheer up! And good luck.

[t00fri]

Isn't there big differences in the cel url's from versions 1.4.1, 1.5.1 and 1.6.0? I seen a couple of times in this thread that cel url's were being used to transfer settings between the various Celestia versions. I would think that this wouldn't work. All the times, locations, etc. should probably be entered manually in each Celestia version instead of using cel url's.
This does look like a big set back to the release of 1.6.0 though.
cartrite

Yes, Steve,

I did not use any cel://url for such reasons. All times have been dialled "by hand" in my tests. In case of the Mars moons, the discrepancy was certainly much larger than possible differences among cel://url revisions!

Fridger

[t00fri]

Here comes the "ultimate" precision test of the Moon's orbital accuracy!

I used the occultation of Saturn by the Moon on 16 April 2002.
As observational location I chose Edinburgh/UK, since it turns out that this image
of Saturn's reappearance refers to Edinburgh:



Note the two named craters left and right of Saturn near the Moon's limb:

Hanno (left of Saturn)
Brisbane (right of Saturn)

These are the data of the event as seen from Edinburgh/GB:
from http://www.popastro.com/sections/occ/satapr.htm

EDINBURGH: DD 20h 46m 41s. Alt. 21 deg. Az. 276 deg. PA 132 deg.
RB 21h 25m 49s UT Alt. 16 deg. Az. 284 deg. PA 213 deg.

Remember
DD= Disappearance at Moon's Dark limb
RB= Reappearance at Moon's Bright limb

Now comes the precision test with Celestia 1.6.0SVN:
+++++++++++++++++++++
Observation from Edinburgh/UK
Time set at 21h 25m 51s UT
Orange crosses: craters Hanno (left of Saturn), Brisbane (right of Saturn)
+++++++++++++++++++++


On top I inserted a small part of the above reference image with the corresponding orange crosses marking the reference craters Hanno (left of Saturn), Brisbane (right of Saturn).
Note the matching location of Thetys!

++++++++++++++++++++++
Altogether, given the identical boundary conditions, the agreement of this high precision is STUNNING!
++++++++++++++++++++++

Fridger

[ajtribick]

Ok so fortunately it looks like CustomOrbits are still working. This is a relief, since the major moons of the giant planets are probably going to be ok.

The problems arise from satellites (natural and otherwise) on EllipticalOrbits, which in general will have their orbital elements specified relative to the equator of the parent planet thus putting them at risk of breakage due to updates to the parent planet's rotation.

Fortunately only Phobos, Deimos and the Earth-orbiting satellites should have incorrect positions because the giant planets have not been switched to a different rotation frame. (Possibly also Saturn's satellites). At minimum these need to be fixed. Ideally all satellites which are not on CustomOrbits should be put into a non-parent-dependent frame, e.g. EclipticJ2000.

It doesn't help that the documentation of data sources in solarsys.ssc is incomplete - I have no idea where the parameters for the EllipticalOrbits in that file come from.

[granthutchison]

Selden sends me ...

I tried posting a couple of days ago, but the forum went down when I clicked "Submit". (I'm pretty sure it wasn't my fault, though.)

"Fixing" Phobos and Deimos with Ecliptic J2000 should be easy enough: Horizons will provide ecliptic elements just as readily as body-centred elements, with the added advantage that I won't need to convert the zero points for orbit longitude. One possible problem occurs if CustomRotation produces precession: we'll see Mars' equator precess out from under the moons' orbits in the far past and future.

Looking through the current solarsys.ssc I notice that there are a few moons without CustomOrbits which do have CustomRotations defined. I'd note that this seems likely to produce unphysical evolution of the satellite's orientation with time, though I haven't tested it.

Before "fixing" the data files, are we sure this isn't an undesirable "feature" in the code for CustomRotation?
For Mars, there used to be a forty-degree difference between Celestia's zero point for orbital longitude and the standard used by JPL and other data sources. Celestia uses the planet's equatorial node on Earth's equator; JPL uses the equatorial node on the ecliptic. Has Celestia changed conventions with the introduction of CustomRotation?

Grant

[granthutchison]

OK.
On first testing, it does look as if BodyFrame or CustomRotation has switched the zero point for orbital longitude around Mars. Using unedited Horizons body-centred elements puts Phobos and Deimos back where they should be. So we seem to have switched from Celestia's old zero-point (ascending node of planet's equator on the celestial equator) to a more standard zero-point (ascending node of planet's equator on the ecliptic). For Mars, this slides the ascending nodes of Phobos' and Deimos' orbits through an angle of forty degrees, which seems to account for the shift in position of the moons themselves.

So, in a way this is a good thing: it's nice that Horizons orbital parameters don't need their ascending nodes tweaked before they can be used in Celestia. In a way it's a bad thing: at present we have some bodies following one set of rules, and some following another. And in a way it's a complete pain in the arse, because I've invested a fair chunk of my youth converting the node coordinates for every single moon in Celestia without a custom orbit, and I'm now faced with undoing all that effort.

I guess the first thing to do is to confirm that all of the above is actually correct. If this is a BodyFrame thing, then we can at least propagate the change one planet at a time.

Here are the revised definitions I've used for Phobos and Deimos, setting up a couple of "Test" objects in the extras folder. Interested folk on this thread may want to test that the "fix" is actually correct.

Code: Select all

"PhobosTest" "Sol/Mars"
{
   Mesh "phobos.cmod"
   Texture "phobos.*"
   Radius 13.0 # maximum semi-axis
   MeshCenter [ -0.233 -0.156 -0.168 ]

   EllipticalOrbit
   {
       Period         0.318910
       SemiMajorAxis  9377.2
       Eccentricity   0.0151
       Inclination    1.075
       AscendingNode  169.695   # J2000
       ArgOfPericenter 215.645  # J2000
       MeanAnomaly    189.833   # J2000
   }

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

   # Overriden by CustomRotation
   # UniformRotation
   # {
   #    Inclination        0.0
   #    MeridianAngle            354.2
   # }

   Albedo         0.07
}

"DeimosTest" "Sol/Mars"
{
   Mesh "deimos.cmod"
   Texture "deimos.*"
   Radius 7.9 # maximum semi-axis
   MeshCenter [ -0.299 -0.284 0.369 ]

   EllipticalOrbit
   {
       Period            1.262441
       SemiMajorAxis     23463.2
       Eccentricity      0.00033
       Inclination       1.793
       AscendingNode    63.412 # J2000
       ArgOfPericenter 193.141 # J2000
       MeanAnomaly       1.961 # J2000
   }

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

   # Overriden by CustomRotation
   # UniformRotation
   # {
   #    Inclination          0.9
   #    AscendingNode   183.0
   #    MeridianAngle      214.7
   # }

   Albedo         0.08
}

Grant

[t00fri]

Grant,

I never understood, why solarsys,ssc with all these crucial/basic data does not consistently include proper references! If there are typos or other bugs, whom should people "call up"?

Fridger

[granthutchison]

I never understood, why solarsys,ssc with all these crucial/basic data does not consistently include proper references! If there are typos or other bugs, whom should people "call up"?

Chris, I would guess.
Do you have any thoughts on how this present mess can best be sorted out?

Grant

[ajtribick]

Well EllipticalOrbits are going to go wrong even if they do remain in the equatorial plane of the planet.

However leaving the orbits in the body's equatorial frame while simultaneously leaving commented-out rotation parameters from the non-CustomOrbit definition, which result in a different reference frame for the satellite orbits leaves things open to serious confusion with the satellites if someone decides to do a comparison between the two.

I would suspect that the typical view would be that changing the planet's parameters should not affect the satellites... EllipticalOrbits are going to be wrong in the far future/past anyway because of gravitational interactions, so I doubt that a possible mismatch between the satellites and the planetary equator at such times is so big a deal.

[chris]

I just returned from my trip to Europe and am catching up on forum posts now...

The problem with the positions of Phobos and Deimos is indeed caused by the usage of a CustomRotation for Mars's rotation. No other objects in the standard package should be affected: Mercury and Venus don't have any satellites, the orbit of the Earth's and Pluto's moons are defined in the inertial Earth J2000 frame, and the rotation models of the giant planets haven't been changed.

For compatibility with previous versions of Celestia, it's still the case that the default frame for the orbit of a satellite is the equatorial frame of its parent planet. Therefore, changing the rotation model of the planet will affect the position of satellite unless it has an orbit frame explicitly specified. The fact that Phobos and Deimos have EllipticalOrbits instead of CustomOrbits doesn't matter at all--the CustomOrbits would still be affected by the altered rotation model. 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.

There are two things that should be done:
- I need to figure out why the equatorial plane is different for a CustomRotation than the UniformRotation
- In order to use a CustomRotation for Mars, we should redefine the EllipticalOrbits for Phobos and Deimos in an inertial frame like EarthJ2000 or EclipticJ2000.

--Chris

[granthutchison]

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. 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.

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.

Code: Select all

"PhobosBody" "Sol/Mars"
# unmodified body centred elements
# attached to CustomRotation
{
   Mesh "phobos.cmod"
   Texture "phobos.*"
   Radius 13.0 # maximum semi-axis
   MeshCenter [ -0.233 -0.156 -0.168 ]

   EllipticalOrbit
   {
       Period          3.191594680550278E-01
       SemiMajorAxis   9.378605566188982E+03
       Eccentricity    1.468147128549376E-02
       Inclination     1.075646290243919E+00 
       AscendingNode   1.696950087336492E+02
       ArgOfPericenter 2.156447142065913E+02
       MeanAnomaly     1.898331000224251E+02
   }

   BodyFrame { EquatorJ2000 {} }
   CustomRotation "iau-phobos"
   Albedo         0.07
}

"DeimosBody" "Sol/Mars"
# unmodified body centred elements
# attached to CustomRotation
{
   Mesh "deimos.cmod"
   Texture "deimos.*"
   Radius 7.9 # maximum semi-axis
   MeshCenter [ -0.299 -0.284 0.369 ]

   EllipticalOrbit
   {
       Period          1.262529978296102E+00
       SemiMajorAxis   2.345817634982984E+04
       Eccentricity    3.144182919804991E-04
       Inclination     9.187430224722115E-01 
       AscendingNode   6.341252077209298E+01
       ArgOfPericenter 1.931409087214150E+02 
       MeanAnomaly     1.960853477817803E+00 
   }

   BodyFrame { EquatorJ2000 {} }
   CustomRotation "iau-deimos"
   Albedo         0.08
}

"PhobosEcliptic" "Sol/Mars"
# unmodified ecliptic elements
# with ecliptic body frame
{
   Mesh "phobos.cmod"
   Texture "phobos.*"
   Radius 13.0 # maximum semi-axis
   MeshCenter [ -0.233 -0.156 -0.168 ]

   OrbitFrame {
           EclipticJ2000 { Center "Sol/Mars" }
   }
   
   EllipticalOrbit
   {
       Period          3.191594660665225E-01 
       SemiMajorAxis   9.378605527233729E+03 
       Eccentricity    1.468147543996196E-02
       Inclination     2.605589048779109E+01   
       AscendingNode   8.481536012636795E+01 
       ArgOfPericenter 3.427726995811867E+02 
       MeanAnomaly     1.898330972741476E+02 
   }

   BodyFrame { EquatorJ2000 {} }
   CustomRotation "iau-phobos"
   Albedo         0.07
}

"DeimosEcliptic" "Sol/Mars"
# unmodified ecliptic elements
# with ecliptic body frame
{
   Mesh "deimos.cmod"
   Texture "deimos.*"
   Radius 7.9 # maximum semi-axis
   MeshCenter [ -0.299 -0.284 0.369 ]

   OrbitFrame {
           EclipticJ2000 { Center "Sol/Mars" }
   }

   EllipticalOrbit
   {
       Period          1.262529948014802E+00 
       SemiMajorAxis   2.345817597473957E+04 
       Eccentricity    3.144023166279958E-04 
       Inclination     2.756851066441724E+01   
       AscendingNode   8.366905628616398E+01 
       ArgOfPericenter 2.150177429548746E+02 
       MeanAnomaly     1.960953198319042E+00 
   }

   BodyFrame { EquatorJ2000 {} }
   CustomRotation "iau-deimos"
   Albedo         0.08
}

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

(Edit to add: You can easily demonstrate the change in nodes I'm talking about using the above ssc. Temporarily reinstate Mars' UniformRotation in solarsys.ssc, and you'll see the "Body" definitions of Phobos and Deimos shift out of register by forty degrees relative to the "Ecliptic" definitions.)

Grant

[AstroNut]

I don't know if this is relevant to this topic, but when I tried
to check the position of the moon, I found a discrepancy in
my position above the Earth as reported by the lua tools.

I have this in my start.cel:

Code: Select all

gotolonglat {time 5.0 distance 4.0 longitude -113.18 latitude 53.33}
  wait   {duration 3.0}


In 1.5.1 the lua on screen menu shows me above the correct longlat of 113.23 degrees W
and 53.33 degrees N like this.

LongLat 151.jpg

In 1.6.0 SVN r4542 the lua on screen menu shows me above longlat 66.80 degrees E
and 53.33 degrees N like this.

LongLat 161.jpg

As you can see, visually I am above my location on the Earth, but the incorrect position is reported.
Lua tools problem or something more sinister?

When I put the planetographic grid on in 1.6.0, it shows that latitudes and longtitudes in the right place.

AstroNut

[Vincent]

I don't know if this is relevant to this topic, but when I tried
to check the position of the moon, I found a discrepancy in
my position above the Earth as reported by the lua tools.

Astronut,

Please use the Lua Edu Tools v1.2 with Celestia 1.6:
viewtopic.php?f=11&t=13162

This version takes into account the recent changes made in the Celestia code.
Also, please report your bug in the above thread, rather than in discussions
like this one about the standard Celestia distribution.

[AstroNut]

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