Celestia Forums

Hello everyone,

I am using 1.2.5pre7, have installed the Voyager spacecraft and have been enjoying the views. However, I notice that Celestia does not reproduce Voyager 2's very close (40,000km) flyby of Triton; the distance is off by about 4x. Is there updated trajectory or orbital data available that would fix this? I don't know yet whether there are other inaccuracies with respect to other flybys. Otherwise, this has been a great product.

Alex

Alex,

It seems that Chris may have accidentally used the wrong reference plane when defining the orbits of various moons. There have been several threads recently discussing problems found with various orbits. Use the forum's search page to look for postings by granthutchison

There is hope that the orbits may be corrected in v1.2.5 of Celestia when it's released. In the meantime, you might try downloading Grant's modified solarsys.ssc to see if it helps. It's available on the Web page http://www.lns.cornell.edu/~seb/celestia/hutchison/index.html

Another way to experience accurate flybys is to provide heliocentric cartesian trajectories (.xyz files) for the spacecraft and for appropriate satellites for the times you're interested in. JPL's Horizons Ephemeris Server http://ssd.jpl.nasa.gov/horizons.html, can be persuaded to supply this information in a form that only needs a little editing in order to be compatible with Celestia.

I hipe this helps a little.

Thanks - I'll give it a try!

Alex

I just finished downloading the xyz trajectories for Voyager 2's Neptune/Triton encounter: 400 samples for each of the 3 bodies, from 09:00 UT Aug 23 through 09:00 Aug 27, 1989.

It looks like Neptune's orbit may be off sightly, too

I've made them available at http://www.lns.cornell.edu/~seb/celestia/spacecraft.html#3.4.10

I tried Grant Hutchinson's revised data but that brings Voyager 2 only within about 75,000km. Maybe I'll try the samples - thanks.

Alex

I tried Grant Hutchinson's revised data but that brings Voyager 2 only within about 75,000km. Maybe I'll try the samples - thanks.

Alex

Selden, I downloaded the .ssc and .xyz files you mentioned - but what directories should they go in? I put the .ssc files in /extras and .xyz files in /data, but that results in two sets of bodies when I run Celestia.

Thanks,
Alex

Alex,

You put them in the right places.

I defined them the way I did so that the different locations can be compared easily: "Follow" the spacecraft and alternately "Select" the appropraite planetary bodies. That's also why I declared different surface texture maps in the -xyz.ssc files.

It's easy enough to modify solarsys.ssc so that the original definitions for Jupiter and Triton are invisible. I'd suggest making their radii tiny. The surface texture maps in the -xyz.ssc files should be changed to be the "right" ones. I think copying the rotational elements from solarsys.ssc to the -xyz.ssc files will work, too.

Sorry if this is a dumb question, but...

Are the samples, on the one hand, and the solarsys.ssc file on the other, mutually exclusive? That is, is there any way to fold the samples into the solarsys.ssc file in a such a way that you can run a "seamless" simulation that is (relatively) correct both at the macro level and in the specific flyby?

I'd actually like to have only *one* set of bodies in the whole simulation, but I don't know whether this is possible. To get a "correct" flyby of Triton do I simply have to create a new script?

Thanks!

Alex,

Each .ssc file adds an object to what's already there.

However, starting with 1.2.5pre6, Celestia has supported the SSC directives "Beginning" and "Ending". The object is only drawn between the specified "epochs". Either Julian or Gregorian dates can be used. They don't affect the drawing of the object's orbit, unfortunately.

To do what you want, I think this capability ought to be generalized (Enable and Disable?) so that the display of a particular object can be tuned off and on again, perhaps multiple times. Fortunately, this can be simulated by defining multiple objects, with each definition valid for a specified interval. The only differences in their definitions would be their names and their Beginning and Ending directives.

I made a simple example of the use of Beginning and Ending directives
which can be found at http://www.lns.cornell.edu/~seb/celestia/index.html#3.1

I hipe this helps.

I've been playing around with the Beginning and Ending directives like you suggested. Basically, I edited solarsys.ssc so that Neptune "ends" precisely when the samples begin, and then "begins" again when the samples end; the same with Triton and with Voyager 2 itself. This seems to introduce more complications, though: obviously, all of Neptune's other moons also disappear when the samples begin (also, for some odd reason the image of Nereid seems to disappear completely [whether pre- or post-Voyager], although the orbit is still there and Celestia thinks that it exists). Would I be right in thinking that the only way to show the other moons during the samples would be to have new and separate .ssc files for all of them, based on different ephemeris data?

Another possible problem is: when the "original" Neptune reappears after the Voyager 2 encounter, would it reappear exactly in the location from where it had disappeared, or in the place it actually would have been after the 2-day encounter with Voyager? It wouldn't make much sense to run the simulation if the former were the case. I wonder whether there is a way of specifying correct Cartesian coordinates for Neptune at that point when it "reappears".

Another thing I tried was copying and pasting the xyz samples from voyager2-triton.xyz into the appropriate place in voyager2.xyz (and keeping the "original" data for Neptune and Triton). The strange thing is, the Triton flyby is still off by about 40,000km, but at a certain point you get an image of Triton and Neptune together that is identical to the famous original photo! That might be a coincidence, though. In this version of the simulation, unfortunately, Voyager grazes Neptune within about 1,000km, which also isn't quite right.

So, another question would be - can the orbital data for Neptune and Triton in solarsys.ssc be tweaked in such a way that the Voyager 2 encounter is relatively accurate? This, of course, is way over my head.

Alex

Alex,

I suspect Chris will have to clarify some of the issues. I haven't looked at the code that implements the Beginning/Ending directives, but I'm not surprised that they affect all of the bodies that are defined in terms of the object that the directives are being applied to. Turning off a planet doesn't leave much for its moons to orbit around!

Your description sounds like you might be using several Beginning and Ending directives within the same object definition. Is that the case? I never even thought of trying that, although maybe it actually is supposed to work.

I haven't tried to reproduce what you've done (I'd need a copy of your files to be sure I'm actually doing the same things). At any rate, if you're using separate "Neptune" definitions (Neptune-before-encounter, Neptune-during-encounter and Neptune-after-encounter, perhaps) and if Nerid is listed in all of them and doesn't reappear, then it sounds like you've found a bug.

Alex wrote:Would I be right in thinking that the only way to show the other moons during the samples would be to have new and separate .ssc files for all of them, based on different ephemeris data?

Certainly (as mentioned above) I'd use three separate sets of definitions although I'd probably use many of the same values for the satellites' orbital elements. They can all be put into the same file once they've been debugged, but it's easier to track down mistakes when the definitions are in separate files.

Alex wrote:when the "original" Neptune reappears after the Voyager 2 encounter, would it reappear exactly in the location from where it had disappeared, or in the place it actually would have been after the 2-day encounter with Voyager?

The positions of objects are calculated in real time for the epoch displayed in the upper right corner of Celestia's window. Planetary positions won't pick up where they left off. Objects will be shown where they are supposed to be at that time.

Celestia has internal subroutines that implement the set of formulas known as the "vsop87 theory" for each of those orbits declared as "CustomOrbit". The less accurate "EllipticalOrbit" definitions are ignored unless you comment out the "CustomOrbit" line.

Xyz positions are stored internally as single precision values. As a result, they are less precise at the distance of the outer planets than some of us would like. Also, Celestia only does linear interpolations between the samples. This can introduce significant errors when an object's trajectory is changing quickly, like during V2's Neptune flyby. While the samples that I got are for about every 15 minutes, that may not be good enough.

(This has caused a lot of confusion, even for Chris. It took a while to figure out why Galileo's position was wrong by more than 100,000 km during its flyby of Earth. More freqent samples fixed that.)

Alex wrote:So, another question would be - can the orbital data for Neptune and Triton in solarsys.ssc be tweaked in such a way that the Voyager 2 encounter is relatively accurate? This, of course, is way over my head.

It is my understanding that Chris plans to fix the problem with the coordinate system used for satellite orbits. That should improve the flyby of Triton significantly. However, I suspect that, althogh more frequent xyz samples may help, the best results for both flybys may have to wait until Celestia implements double-precision xyz trajectories internally. In another thread Chris said he's expecting to make that an option in a future release. Right now storing all the samples in double precision would take up too much memory for most systems.

Another consideration is that the orbital computations take a while. More and more terms have to be calculated in order to produce more accurate CustomOrbit planetary and satellite positions. Since the positions are calculated in real time, extremely precise positioning could slow Celestia's framerate by an unacceptable amount.

And finally, it isn't obvious to me that the xyz positions returned by Horizons are based on the vsop87 theory. In fact, I'm positive they aren't. There are some more recent models of the solar system which use a slightly different mass for Neptune. Calculations based on them would necessarily produce slightly different positions for objects than Celestia calculates.

(p.s. written later:
I just looked at Horizons' documentation message. It says that planetary positions are calculated based on "DE403/LE403", which I know is different from vsop87. Later it also says that it uses the DE-405 ephemeris. Several different methods are used for the various natural satellites.*sigh*)

I hope this clarifies some things a little

Selden, I was using three different sets of definitions for Neptune, Triton, and Voyager 2 (i.e., Neptune pre-Voyager, then neptune-v2.xyz samples, then Neptune post-Voyager).

Where, exactly, can I go to download the xyz coordinates at those times for the other Neptunian moons? I don't know how time-consuming it would be to do this, but I'd be willing to give it a try just to see what kind of results I can get. Like I said, I added the new data to voyager2.xyz for that time period, so the spacecraft's trajectory itself should be "correct"; then it would simply be a matter of adding new samples for all of Neptune's moons (or would it?).

Thanks,
Alex

fisher wrote:I tried Grant Hutchinson's revised data but that brings Voyager 2 only within about 75,000km. Maybe I'll try the samples - thanks.

I'm surprised it made any difference - I didn't revise Chris's orbital elements for Triton at all, as far as I recall; I just got its rotation correctly orientated for the orbit he gave.
At least two things may be wrong with the Triton-Voyager encounter in solarsys.ssc:
1) The ascending node may well be in error, because of the coordinate-conversion problem we've discovered elsewhere.
2) The orbital elements given are for this year. I don't know how fast Triton's orbital plane precesses, but I think that would make a significant difference over more than a decade.

It's certainly possible to come up with a set of orbital elements for Celestia that would reproduce the Voyager-Triton encounter crisply, but they would then be in error for other dates. Selden's xyz files with fixed start and finish times are probably the best solution until Chris makes a CustomOrbit for Triton.

Grant

Alex,

JPL runs the "Horizons Ephemeris Server." It has a database of over 100,000 objects. Anyone can use it. It has a Web interface, a telnet interface and an e'mail interface. I usually use the telnet interface to get elliptical orbit parameters (which are short) and its e'mail interface to get xyz coordinates (which can be quite long). The Web interface is rather limited, but looks like it ought to be great for finding where to look in the sky for an object. Our skies here are usually clouded over .

Start with their Web server, though: it explains how to get documentation for the other interfaces. http://ssd.jpl.nasa.gov/horizons.html

When asking for xyz coordinates, be sure to specify heliocentric coordinates in order to be compatible with Celestia.

I've added a link on my "spacecraft" web page to a template that should work for the e'mail interface. See http://www.lns.cornell.edu/~seb/celestia/spacecraft.html#3.4.1
It's the "e'mail" link in the "Comments" column for Cassini.

Yes, the elements for Triton's EllipticalOrbit have a faulty ascending node - it should have 24.527368 degrees subtracted to correct the coordinate system. This doesn't help with the Voyager encounter, though, because it's still applying 2002 elements to 1989.
I've downloaded appropriate elements for the day of the encounter, and sure enough, the ascending node has twisted by 5 degrees in the intervening time - enough to make a big difference to Triton's position relative to Voyager, even if all the other elements stayed the same. So I've plugged the appropriate elements into Celestia, with a slight modification - I've inserting the average period for Triton, rather than the instantaneously-calculated period. That gives a more realistic position at dates other than epoch. And I've modified the rotation period and offsets for Triton accordingly, to get the prime meridian correctly positioned for this new orbit. Here's the description for Triton using this information:

Plug that in, and you should get a good Voyager encounter at ~40,000km, and reasonable positions at future dates, albeit with a cumulative error in ascending node of about 0.5 degrees/year. (Although the pericentre is moving faster, the orbit has such small eccentricity it's not going to be very noticeable.)
A useful check that I've done the sums correctly is to take a look at the sunlit portion of Triton on 25 Aug 1989 - it matches the mapped area perfectly.

Grant

Selden, do you get the elliptical orbital parameters simply by typing the body name at the telnet prompt (i.e., Horizons>TRITON)? Or is there a command I'm missing that will give further details?

Thanks!
Alex

Grant, that looks much better; now I can reproduce Voyager 2's departure photo of Triton superimposed on Neptune's limb on 31 August. I may try downloading some samples of Neptune + moons from JPL and see if the results are similar.

Alex

Alex,

Specifying the object by supplying its name (or number) is just the first step.

The other major choices are the central body and the coordinate system. I've found heliocentric orbits are easy: central body = sun & ecliptic coordinate system.

Choosing the right coordinate system for any of the moons is another matter entirely. I simply don't have the grasp of the 4D relationships of the orbital parameters that Grant does, so I have yet to be able to apply the appropriate transforms to convert the elements that Horizons supplies into the coordinate system that Celestia currently uses.

That's why I "cheat" and use heliocentric xyz trajectories for the flybys that I find interesting.

(My dream is that Chris will modify Celestia's plenetocentric coordinate system so that Horizons' elements can be used unchanged. Unfortunately, I fear that so substantial a change might require more of a delay in the final 1.2.5 release than he's willing to accomodate at this point -- and I wouldn't blame him at all. It's clear that getting this release finalized is taking far longer than anyone ever expected. We keep pointing out bugs that just *have* to be fixed!)

Thanks, Selden. The other obvious problems are the V1 and V2 flybys of Jupiter; in both cases the moons are not in their correct positions, but the planet itself looks fine. I wonder whether anyone else has encountered this and tried to put together some samples for those events as well.

Cheers,
Alex