Celestia Forums

Hi.
I'm new to this forum and new to Celestia: please forgive me if what I'm about to say has either already been discussed or is about to be addressed in the next release. I have searched the forum on a few plausible search words without turning up anything relevant.

I noticed that the orientation of some natural satellites generated from solarsys.ssc was wrong: specifically, those defined without custom orbits - Phobos, Diemos, Amalthea and Proteus. After a bit of messing about with the file, I think I've worked out that these satellites are generated in the correct orientation (with the zero meridian pointing at the centre of the parent planet), at some standard zero position in orbit. But the addition of a random mean anomaly for display purposes then moves them around their orbits without altering their absolute orientation, so that the zero meridian ends up misaligned. This can be corrected by adding a RotationOffset term that is equal to the MeanAnomaly. (Effectively rotating the satellite back into its correct position.)
However, putting in real-world values for ArgOfPericenter and AscendingNode messes this up again. The AscendingNode problem is fixed by using a solution already posted by Matt McIrvin: set Obliquity to equal Inclination, and LongOfRotationAxis to equal AscendingNode. This yanks the satellite around into the correct position at the ascending node. The ArgOfPericenter problem is fixed by setting RotationOffset equal to MeanAnomaly+ArgOfPericenter.
Finally, things go awry again if an epoch other than the default J2000.0 epoch is used - we have to compensate for the partial rotations the satellite achieves between the entered epoch and the default epoch. In degrees, this is equal to 360*FRAC{(2451545-Epoch)/Period}, where FRAC indicates the fractional part (the figures right of the decimal point).
So the general solution to keeping satellites aligned correctly is:

RotationOffset = MeanAnomaly+ArgOfPericenter+[360*FRAC{(2451545-Epoch)/Period}]

This assumes that you have made Matt McIrvin's correction for the AscendingNode. If you have not, you should add AscendingNode to the above formula.
Any reorientation for artificial satellite models should then be added to that sum.
If either MeanAnomaly or ArgOfPericenter is not entered, then they should be set to zero. If no Epoch is given, then the epoch term should be set to zero.
I've tested this on the solarsys.ssc file, and have confirmed that this formula preserves correct satellite orientations. It also makes sense in terms of the way the various terms work to define an orbit, and my guesses about how Celestia works. But if anyone sees a flaw in the argument, please put me right!

Grant

I'd never checked to the orientations of any of the satellites . . . I'm glad to heard that at least the larger satellites are oriented correctly.

I will eventually add custom orbits for all of the moons in the solar system; until that time, your adjustments are a good way to put things in order.

I recently changed LongOfRotationAxis to EquatorAscendingNode, since that's what was really mean all along. The actual longitude of the rotation axis is 90 degrees less than the equatorial ascending node.

--Chris

chris wrote:I'd never checked to the orientations of any of the satellites . . . I'm glad to heard that at least the larger satellites are oriented correctly.

Oops, what I wrote was misleading. I haven't checked the CustomOrbit moons at all systematically, since I wasn't sure how I could glean the relevant information to orientate them precisely. I just zeroed in on the ones without custom orbits, because I could vary their parameters at will and see what happened. So my "specifically" was intended to say that I was going to discuss specifically that type of moon, not that I'd checked the others and they were OK.

Did you, by the way, receive my e-mail about the shape model for Phobos? It is mirrored north-south, as is its texture map. Deimos, Proteus and Amalthea shapes are OK, I think, but the texture map for Deimos seems to be mirrored north-south, too.

Grant

chris wrote:I'd never checked to the orientations of any of the satellites . . . I'm glad to heard that at least the larger satellites are oriented correctly.

OK, I've had a look at the Galileans, and they aren't orientated correctly either. My formula doesn't seem to work with the quoted parameters for their custom orbits. But the necessary RotationOffsets (by Mark I Eyeball) are as follows:

Io 20
Europa 225
Ganymede 225
Callisto 50

chris wrote:I recently changed LongOfRotationAxis to EquatorAscendingNode, since that's what was really mean all along. The actual longitude of the rotation axis is 90 degrees less than the equatorial ascending node.

Makes sense - I noticed the discussion on this topic on the original thread. Is that in 1.2.5? It doesn't seem to work in 1.2.4.

For anyone who's interested, here are the definitions I've worked up for Phobos, Deimos, Amalthea and Proteus, using data from the JPL website:


I'll check the orientation of the other moons and report back.

Grant

Grant,

What are your sources for the orientations of the satellites?
Direct observation?
JPL's Horizons service?
Some other ephemerides? What ones?

I'm just curious: I've found that Horizons sometimes has some bad information in it. (The orbit of the INTEGRAL gamma ray telescope, for example, is way off from what's described on Integral's Web site at http://astro.estec.esa.nl/SA-general/Projects/Integral/status_results.html

selden wrote:What are your sources for the orientations of the satellites?

The convention for mapping of synchronous natural satellites is to have the zero meridian pointing at the centre of the parent body. (There is obviously some averaging process here for eccentric orbits.) Phil Stooke's shape models use the same convention.
So for the shape models of Phobos, Deimos, Amalthea and Proteus, I'm making reference to Phil Stooke's shape models (I've generated these myself in POVray, so I know the data even though I can't access the 3DS files directly). For the other satellites (and as a cross-check on Phobos and Deimos), I'm using published maps - mainly the NASA Atlas of the Solar System.
It's easy enough to check the approximate apparent longitude of mapped features in Celestia's satellites by:
1) Going to the parent body and then looking at the satellite (zero meridian).
2) Going to the satellite and moving around it until it aligns with the centre of the parent body (180 meridian).
3) Orientating north or south of the satellite and checking which features align with the marked line of orbit (90 and 270 meridians).

At present I'm trying to refine this by laying on a texture with marked, numbered grid lines, so that I can just read off the necessary RotationOffset, but I'm struggling to get Celestia to accept my texture jpeg, for some reason.

Grant

OK. I think I understand. Presumably you're taking libration into account. (the averaging you mention?)

Also, in case you hadn't realized, Celestia requires the surface texture images be a powr of two in their dimensions. e.g. 1024x512. Most published surface maps are not and have to be scaled. (POV-Ray doesn't have that restriction.)

I hope this helps.

selden wrote:OK. I think I understand. Presumably you're taking libration into account. (the averaging you mention?)

I presume the cartographers calculate a mean meridian and then either choose a surface feature or a specific epoch to define their zero.
Me, I'm taking this into account to the extent that eyeball correction of the orientation of the CustomOrbit satellites is never going to be better than five degrees or so - for reasonably circular orbits I think this error will be considerably greater than any error created by the state of libration of the satellite at the moment I eyeball it. (I've just this minute run a check on that, by following Io around its orbit with my grid texture pasted on to it, and the libration does seem to be relatively trivial compared to my eyeball error. Obviously I need to check that again when I come to more eccentric satellites.)
For objects without CustomOrbits, my situation is more precise. Celestia generates these in an orientation I can recover from the orbit definition, and therefore correct exactly with the formula above. With CustomOrbits there's more going on somewhere I can't access/understand, so at present I'm having to just look at the final result and insert a jigger factor.

selden wrote:Also, in case you hadn't realized, Celestia requires the surface texture images be a powr of two in their dimensions. e.g. 1024x512.

This is exactly what was going wrong with my custom jpeg grid - between my last post and your reply I manage to figure that one out (only just!), but thanks indeed for coming to my aid. I'm going to lay the grid on to the remaining CustomOrbit satellites, and come back with list of RotationOffsets that should dramatically tighten up their orientations, even if it isn't perfect.

Grant

Grant,

Thanks a lot for all the effort you're investing in this. We'll all appreciate knowing that the additional accuracy is present. I'm rashly assuming you'll make the modified solarsys.ssc available for Chris to include with Celestia.

If you could make your planetary grid available, too, I suspect some other folks would find it useful. Someone else created one not too long ago, but it's probably somewhat different from what you're using. Of course I can't find the posting now, so I can't give it the correct attribution

Thanks, again.

selden wrote:I'm rashly assuming you'll make the modified solarsys.ssc available for Chris to include with Celestia.

Sure, if he wants it.

selden wrote:If you could make your planetary grid available, too, I suspect some other folks would find it useful.

Very happy to do so -but it's just a jpeg file with labelled meridians at 30 degree intervals.
However, I don't have a website to post it on with a linking URL here. Is there somewhere else I should upload it?

Grant

Grant,

Chris has been known to make space available on http://www.shatters.net for contributions to Celestia: Rassilon and Fridger both have Web pages there.

Alternatively, I could put a few small files on the server I use, if you can e'mail them to me. (Web and e'mail links are below)

Right, I've finally worked out what's going wrong with Phobos.
The shape model is in fact correctly orientated, but when I lay my gridded texture map on to it, I find that the map is effectively turned inside-out: as if instead of pasting straight on to the surface of the model, each bit of map had passed right through the centre of the model and pasted itself on to the inside of the opposite surface. So that when I look at my gridded Phobos from Mars I don't see the zero meridian facing me - I see the 180 degree meridian, with its label upside down and mirrored.
This effect is partially offset by the fact that the Celestia Phobos texture map is 180 degrees out of longitude alignment with the shape model - the turning-inside-out process brings each line of longitude of this misaligned map back to where it should have been originally, although still reversed north for south. (Phew! No wonder it took so long to figure out.)
As a temporary fix, I've greated a texture called "phobosmirror.jpg", simply by reflecting the original Celestia map north and south in an image editor. This drapes on to the Phobos shape model beautifully, and the craters in the northern and southern hemispheres now look round, and are laid over appropriate dents in the shape model.
The problem is present in all the other *.3ds models I've looked at (Diemos, Amalthea, Proteus, Hyperion), but not in the *.cms models for Phoebe and Nereid. Since Amalthea, Proteus and Hyperion have random textures applied, the texture error just introduces a bit of variety. But Diemos also needs a "diemosmirror.jpg" created - which again improves the appearance dramatically, with areas of high relief now clearly marked by paler terrain.

Grant

For those who are interested, Selden has kindly (and stunningly quickly) built a web page containing my reflected Phobos and Deimos textures, as well as my (roughly labelled) lat/long grid.

Grant

Another parameter I hadn't previously considered is the edge longitude of the maps used by Celestia. Some of these start with zero degrees at the edge, some with 180 degrees, and there are a selection of oddballs - like Callisto, which has 30W at the edge.
This is relevant in two ways:
1) An extra jigger factor must be added to RotationOffset if the Celestia map has an edge meridian other than the prime meridian. (At present I'm getting the spherical satellites correctly orientated as if the prime meridian were the edge meridian, and then subtracting the value of the true edge meridian (in degrees west) from the RotationOffset - this spins the satellite until the map is correctly registered.)
2) Any texture map changes may affect the orientation of the satellite, if the edge meridians are different - the RotationOffset would require editing to fix the orientation.

All this added an extra disorientation to setting up Triton correctly.
Triton's already difficult because of its retrograde motion, meaning that 180 degrees must be added or subtracted here and there to keep things straight, then a final 180-degree twist added to centre the map over the prime meridian.
I've set Triton's rotation axis perpendicular to its orbit, in the absence of any other information. Orbit data from the 1.2.5 solarsys.ssc, which provides more detail for Triton.


And here are the new parameters for Amalthea, calculated from the new epoch data used for the Galileo encounter in 1.2.5.

The U.S. Naval Observatory's "Explanatory Supplement to the Astronomical Almanac" (1992 edition) gives the rotation of various solar system objects in terms of their "cartographic coordinates", consisting of the orientation of the north pole and the position of the prime meridian of an object with respect to an inertial reference frame. Specifically, these elements are given by three variables: a0, d0, and W, as functions of time.

a0 and d0 are the right ascension and declination of date (i.e. at a given time) of the object's north pole. (The "north" pole, as defined by the International Astronomical Union, is the rotation axis on the north side of the invariable plane of the solar system.)

W is the angle, measured along the the object's equator in a counter-clockwise direction when viewed from the north pole, from the ascending node of the object's equator on the Earth's mean equator of J2000.0 to the point where the prime meridian of the object crosses its equator. (Note that the right ascension of the node is at 6h+a0, and the inclination of the object's equator to the standard equator is 90-d0.)

In the expressions given for these variables, time is specified in two ways: T is the time from J2000.0 (JD 2452545.0 TDB) in Julian centuries (36525 days), and t is the time from J2000.0 in days (86400 SI seconds).

As an example, for Triton:

W = 296.53 - 61.2572637*t + 22.25*sin(N7) + 6.73*sin(2*N7) + 2.05*sin(3*N7) + [6 more terms]

where

N7 = 177.85+52.316*T

Similar expressions are given for a0 and d0.

Would this kind of information be useful?

- Hank

HankR wrote:The U.S. Naval Observatory's "Explanatory Supplement to the Astronomical Almanac" (1992 edition) gives the ...

Ah. I actually have this sitting on a shelf next to me as I type, but hadn't thought to open it.
I can certainly work out a pole position for the epoch of the orbit defined in Celestia, and see how this relates to the orbital "pole" for the same epoch.
There might be a long silence while I work on the trig ...

Grant

OK, here are the eyeballed corrections (correct to around 5 degrees, I estimate) to get the major synchronously rotating planetary moons with CustomOrbits orientated correctly in Celestia. (I've already covered the ones with non-custom orbits.)
Since the correct orientation depends on the edge meridian of the texture map used, I've also noted the edge meridian of the maps provided with Celestia - if you're changing to another map, you'll need to check and correct for any difference in edge meridian.

Io
RotationOffset 20 #map has 0?W edge meridian

Europa
RotationOffset 230 #map has 0?W edge meridian

Ganymede
RotationOffset 220 #map has 0?W edge meridian

Callisto
RotationOffset 50 #map has 30?W edge meridian



Mimas
RotationOffset 320 #map has 180?W edge meridian

Enceladus
RotationOffset 320 #(no map with Celestia - calculated for map with 180?W edge meridian)

Tethys
RotationOffset 325 #map has 180?W edge meridian

Dione
RotationOffset 320 #map has 180?W edge meridian

Rhea
RotationOffset 190 #map has 180?W edge meridian

Titan
RotationOffset 175 #(in anticipation of a surface map with 180?W edge meridian)

Iapetus
RotationOffset 230 #map has 180?W edge meridian



Miranda
RotationPeriod 33.912 #required to correct rotation bug in Celestia
RotationOffset 330 #map has 90?W edge meridian

Ariel
RotationOffset 230 #map has 180?W edge meridian

Umbriel
RotationOffset 260 #map has 180?W edge meridian

Titania
RotationOffset 280 #map has 180?W edge meridian

Oberon
RotationOffset 0 #map has 180?W edge meridian

The most noticeable changes are that the large crater Herschel is now correctly orientated on Mimas, and Iapetus's leading hemisphere is now appropriately the dark one.

Grant

Grant,

Thanks a lot for taking the time to do all the careful work this required. Many of us greatly appreciate it.

Unfortunately, it turns out that at least one of the major planets has similar difficulties: I just determined that the map of Mars is off by at least 180 degrees compared to solarsys.ssc. I haven't checked it to more accuracy than that, and I haven't checked Mercury or Venus, either.

selden wrote:Unfortunately, it turns out that at least one of the major planets has similar difficulties: I just determined that the map of Mars is off by at least 180 degrees compared to solarsys.ssc.

Yes, Mars has major problems. In addition to the misalignment of the RotationOffset, its axial inclination is off by a few degrees, and there's a 180 degree error in the EquatorAscendingNode.
From the standard J2000.0 parameters for the Martian north pole and prime meridian, I calculate the following:


This gets Mars into nice agreement with various lists of central meridians.
You can check that my change of Obliquity and EquatorAscendingNode are appropriate by skating around to the south pole of Mars with the celestial grid on, and pulling back so you can eyeball the direction of the axis of rotation: it should be pointing at 53 degrees north, 21.2h right ascension. (Compare this with the direction generated by Celestia, which is in another part of the sky entirely.)

Grant

Grant,

When you write

granthutchison wrote:there's a 180 degree error in the EquatorAscendingNode.

Does that imply that the current maps would be correctly alighed if the EAN were corrected?