Greetings and Kudos (New Member)

[Apollonian]

Greetings everyone.

I had looked at Celestia a couple years ago and found it to be one of the best Open Source projects on the net. Now looking at the new version I see that you all have been busy since then

I am currently studying celestial mechanics at the University of Illinois and so I've become interested in the inner workings of Celestia. Given the recent near-miss Asteroid which visited us a few weeks back, a lot of us are interested in modeling the solar system better.

I am specifically interested in looking into the accuracy and precision of the orbital elements and propagation involved in Celestia.

For an opening question to the community, has anyone already looked at this? Does Celestia have functionality for sphere-of-influence considerations (interactions with bodies other than the orbital focus)? And is there some way that I might apply my newfound knowledge of celestial mechanics to the project (if I ever find the time)?

[selden]

Apollonian,

Celestia does not calculate any gravitational effects, so the concept of "sphere of influence" is irrelevant to its code.

Instead, it uses position formulas that have time as the only independant variable. The VSOP87 Theory is used internally to calculate the positions of the major planets, and comparable equations are used for many of the major moons. The use of more recent JPL ephemerides are planned for the future.

The orbits of most bodies are defined using simple Keplerian orbital parameters, so they're only valid for relatively short periods around their Epochs. One also can define trajectories by specifying time and xyz coordinates relative to a primary. People often use Horizons to calculate heliocentric trajectories for spacecraft like Cassini, for example.

Does this clarify things at all?
If not, searching the Web for VSOP87 should prove illuminating.

[Guest]

Thank you for the swift reply. I figured that this would be the case. I will look into the theory but I assume that it is a relatively straight forward Keplerian system.

I already know how to work all the orbital elements and such using ssc files. However, I have not looked at any of the source in depth yet. Is there a way to alter the source such that I might include my own propogator? In other words, is there a way to alter the code or create a script to continually update the xyz positions and rates for the orbiting bodies? (what is the extent of capabilities with scripts?)

If this is possible, it will make for an extremely handy visualization tool for those of us who are more inclined to celestial mechanics and not so much to OpenGL programming.

Also, Selden - I am assuming that you are the originator of the very nice supplemental tutorial site linked from Shatters? Kudos.

[Apollonian]

<< bah, forgot to set the site to login automatically >>

[selden]

Apollonian,

No, VSOP87 is not a Keplerian system.
It consists of a set of polynomials with more than 1000 terms in each which have been fit to the observed positions of the planets.

All of Celestia's source code is available for downloading from SourceForge. You'll need to learn how to use cvs (read SourceForge's documentation) and a C++ compiler if you haven't already. Windows systems need the current version of VisualStudio. Unix and Linux use the GNU tools. I'm completely unfamiliar with what's needed for Mac software development.

Realtime placement of objects normally has to be predefined in catalogs or in the code. Someone with more scripting experience than I have will have to provide the details of what it can do.

I've written a few documents describing how to do some Addon stuff using Catalogs. Others have written about how to use Celestia itself and Cel and CelX (Lua) scripting.

[t00fri]

Apollonian,

Celestia does not calculate any gravitational effects, so the concept of "sphere of influence" is irrelevant to its code.

the VSOP87 theory as used in Celestia certainly does account for plenty of gravity effects, not only due to nearest (massive) neighbors but also due to all other (relevant) massive bodies. However it does that in a time-averaged way that boils down to the appearance of hundreds of correction terms wrto the Keplerian orbits in form of a Tchebichef polynomial expansion.

If you happen to have also taken a course in Atomic physics you can directly compare the VSOP87 theory with the Hartree-Fock method. Since both gravity and the electromagnetic forces have infinite range, approximations beyond "nearest neighbor" are very essential for the resulting accuracy in both cases.

In any way the resulting orbit accuracy is outstanding, about the best that is available on this planet .

There is no comparison with the accuracy of Keplerian orbits...

What is neglected consistently (for good reasons!) in Celestia are gravity effects on the observer's "spaceship". The observer acts as a "Superman/woman" who can travel with theoretically infinite speed and has no mass. So he/she is also not subject to the laws of special/general relativity.

Bye Fridger

[selden]

Fridger,

The point I was trying to make was that all of those gravitational effects are precalculated and the results are used only to position those specific bodies for which "VSOP87 Theory" formulae are available.

Celestia does not provide any way for a user to define a new body in an SSC file with its own "sphere of influence". Any such effects have to be precalculated by some other means. Two of those "means" can be by using Horizons to generate an xyz file or by providing some other highly accurate ephemeris, like those that JPL uses within Horizons.

[Apollonian]

Fascinating. I see your point about the VSOP87 methodology. Specifically, I'm looking at two things - Earth and a fictitious asteroid (one which will impact Jan 2015)

Upon fussing with the orbital elements, I noticed there was a slight discrepency in the final collision. After perusing the fora here and looking briefly at the VSOP87 stuff, I am assuming this has to do with the asteroid's motion close to the earth or due to slight inaccuracies in these orbital elements.

What exactly is an xyz file and is it possible to construct one manually? I noticed that several of the spacecraft (eg Cassini) which make use of them. Since interplanetary missions involve sphere-of-influence considerations, I am hoping that plotting asteroid trajectories could be done in similar fashion.

[selden]

Apollonian,

Celestia's trajectory files ( whatever.XYZ) are plain text files containing 4 floating point numbers per location (usually all 4 are on one line, but that probably isn't necessary). The numbers are a julian date (aka Epoch), followed by the object's x,y and z cartesian coordinates (in km) at that Epoch. The coordinates for heliocentric (sun centered) trajectories are relative to the Ecliptic coordinate system.

XYZ trajectories can be relative to any object, but I don't recall which coordinate systems are used for ones which are not relative to the sun.

Horizons can return compatible coordinates. Its files have to be reformatted slightly, though.

[Apollonian]

Excellent. I will have to try this route. If this sort of thing works like I think it does it makes for an easy way to program trajectories for those who know how to manupulate the coordinate systems.

I am assuming that the "x" coordinate is then in the traditional direction toward "first point in Ares" corresponding to the vernal equinox? (The same "x" direction used for Geocentric orbits)

If I come up with any code that makes creating custom XYZ files easier, I will be sure to post them for the community. I expect to have a greater understanding of orbital perturbation theory by the end of the academic semester.

Again, thanks for your help and many Kudos on the quality of the project. Keep up the good work and maybe sometime in the future this will turn into a robust enough program to really start applying it to real research in space exploration (if it isn't already)- not to mention being a really fascinating toy!

[granthutchison]

I am assuming that the "x" coordinate is then in the traditional direction toward "first point in Ares" corresponding to the vernal equinox?

Yes. Y at 90 degrees ecliptic longitude, and Z at 90 degrees ecliptic latitude.
The coordinate system is equatorial for bodies other than the Sun, with the X direction defined by the ascending node of the body's equator on the ecliptic ... this is different from the Horizons coordinate system, which places X on the ascending node of the body's equator on the celestial equator.

Grant

[Apollonian]

Ok, now I'm confused...

Yes. Y at 90 degrees ecliptic longitude, and Z at 90 degrees ecliptic latitude.

This makes sense...

The coordinate system is equatorial for bodies other than the Sun, with the X direction defined by the ascending node of the body's equator on the ecliptic

So... are you saying that the x coordinate changes depending upon which celestial body we are talking about??? It was my understanding that solar system coordinates use only the Earth-equator with eccliptic definition for the x-unit-vector. It does not seem to make sense to have hundreds of different coordinate systems, one for each body.

For instance, if I enter an XYZ file with only one data point (not signifying an ascending node to the orbit) what coordinate system are we talking about here?

As another thought - "bodies other than the sun" - do you mean extrasolar orbits? (In which case, of course a heliocentric Earth-referenced coordinate system makes little sense) But if this is the case, assuming only one orbiting body around the star, there would be no ascending node since the orbit plane would be the local ecliptic. ???

... this is different from the Horizons coordinate system, which places X on the ascending node of the body's equator on the celestial equator.

So, you're just trying to make the distinction between coordinates used in observational astronomy and those used in celestial mechanics?

Grant

On a side note, I've been perusing the source code and noticed that you have a solver for the Laguerre-Conway orbit propagation algorithm. As I mentioned I am currently taking a course in orbital mechanics, the course happens to be taught by Prof. Conway (who, unlike Laguerre, is not a long-dead mathematician ). So, I thought that was a fun thing to note.

[granthutchison]

So... are you saying that the x coordinate changes depending upon which celestial body we are talking about???

X, y and z, necessarily, since the coordinate systems are based on the equatorial plane of the body in question. The alignment of the coordinate frame with the prime rotation axis surely makes sense?

For instance, if I enter an XYZ file with only one data point (not signifying an ascending node to the orbit) what coordinate system are we talking about here?

It's unspecified in the xyz file. You can only use an xyz by referring to it in an ssc file. For instance:

Code: Select all

"Cassini" "Sol"
{
   Class "spacecraft"
   Mesh "cassini.3ds"
   Radius 0.011
   SampledOrbit   "cassini.xyz"
}

tells Celestia to go find cassini.xyz and refer its coordinates to Sol ... so they're interpreted as ecliptic coordinates. But you could easily define an xyz centred on Saturn for the orbital phase of the mission, in which case you would use Saturn's equatorial plane for the xy plane, with x orientated along the ascending node of Saturn's equator on the ecliptic.

As another thought - "bodies other than the sun" - do you mean extrasolar orbits?

Sorry, I wasn't clear ... I meant other bodies of the solar system. The reference plane for other stars is the ecliptic, and for extrasolar planets is body-equatorial - so the same system as for the solar system. While it's appealing, I think in practice trying to define "ecliptic" planes for other stars would start to clunk audibly, given that the orbital plane of most extrasolar planets is unknown.

So, you're just trying to make the distinction between coordinates used in observational astronomy and those used in celestial mechanics?

I'm not sure what you mean, here. Are you asking if the choice of coordinate systems in Celestia was made specifically in order to make some sort of distinction (in which case Chris, who set up the coordinate systems, is probably the only person who knows); or are you seeing some philosophical contrast between the choice of node in Horizons and Celestia that I haven't cottoned on to?

Grant

[Apollonian]

Ok, I see what you're saying now. The reference plane of the coordinate system is with respect to the second body referenced in the ssc file. I had forgotten about the format of the ssc files for a moment. Yes, this makes perfect sense now.

One more thing, however: in defining the ascending node let me see if I get this right. So, we want to define an orbit for spacecraft "SC" around body "B" which itself is revolving around body "F" (focus)...

- SC orbits B which orbits F

- SC's x-coordinate lies along the vector created by the intersection of the equatorial plane of B with the orbital plane of B about F ? I would guess that this would be the "ascending node" - so maybe based upon the rotation of body B ? If I am thinking correctly, this would also correspond to the determination of the "first point in ares" for Earth.

However, there are two such vectors. How do you choose the analog to the "first point in ares" for non-geocentric orbits?

I was looking at Cassini's orbit thismorning to take a look at how its orbit was handled. Based on what has been said here, it seems that there did not seem to be a point where it switched over to Saturn-centric orbit rather than plotting a Helio-centric path orbiting Saturn.

The more I am looking at this, the more clever things I see. Although, I do have to admit that I am still a undergraduate student so I know just enough to be dangerous - if that wasn't made clear

[granthutchison]

- SC's x-coordinate lies along the vector created by the intersection of the equatorial plane of B with the orbital plane of B about F ?

Not quite. The fundamental plane is always the ecliptic plane, the plane of Earth's orbit. So we imagine the intersection of the planet's equatorial plane with the ecliptic, and we watch it rotate - the ascending node of the equator is the point at which the planet's equator is passing through the ecliptic plane from south to north. That's the x direction, and the origin of longitude for Keplerian orbits.
The First Point of Ares is defined in an analogous way that is effectively the reverse of Celestia's convention - it's the ascending node of the ecliptic on the Earth's equatorial plane, which makes it the descending node of Earth's equator on the ecliptic. Since we want to keep the first Point of Ares as our zero longitude for orbits around the Earth, there's a compensatory tweak embedded in solarsys.ssc which (uniquely) defines a negative Obliquity parameter for the Earth, so that the x-axis aligns appropriately.

I was looking at Cassini's orbit thismorning to take a look at how its orbit was handled. Based on what has been said here, it seems that there did not seem to be a point where it switched over to Saturn-centric orbit rather than plotting a Helio-centric path orbiting Saturn.

That's right. It's heliocentric all the way. But you could define a Saturn-centric xyz if you wanted to. I built a body-centric xyz for the NEAR-Shoemaker orbit around Eros, for instance, because it was the only way to get an accurate enough relationship between the orbit and the central body.

Grant

[chris]

So, you're just trying to make the distinction between coordinates used in observational astronomy and those used in celestial mechanics?

I'm not sure what you mean, here. Are you asking if the choice of coordinate systems in Celestia was made specifically in order to make some sort of distinction (in which case Chris, who set up the coordinate systems, is probably the only person who knows); or are you seeing some philosophical contrast between the choice of node in Horizons and Celestia that I haven't cottoned on to?

If the coordinate system in Celestia seems slightly strange, it's probably because I've used the conventions of computer graphics instead of celestial mechanics--not because I think that they're superior, but rather because I was much more familiar with them when I started writing Celestia. If I was starting over, I'd make different choices.

--Chris

[Apollonian]

If the coordinate system in Celestia seems slightly strange, it's probably because I've used the conventions of computer graphics instead of celestial mechanics--

--Chris

Ok, this is actually what I had suspected and why I asked the question. I unfortunately don't know too much about conventions in computer graphics though I imagine I will understand most of the lingo after looking at attitude dynamics a bit this summer (which seems to share a lot in common with graphics).

Chris, would you mind explaining the coordinate system from a perspective of the graphics? Basically, the convention doesn't matter to me (I can come up with the appropriate transformation codes myself). I am just looking to figure out how to generate the appropriate orbit orientations.

Specifically - what are the xyz conventions for a ficticious object (spacecraft or asteroid) in a heliocentric orbit ?

Is the x direction the reverse of the "first point in ares" ? From this, which axis is normal to the ecliptic plane and in which direction (right hand rule with Earth's orbit?)

For those of us in astrodynamics at least, we are used to grappling with various coordinate systems, so I wouldn't worry too much about the difference between celestial mechanics and computer graphics. It would be nice to write this up in some documentation somewhere after we finish discussing it, however. After looking through old forum threads, it seems I'm not the only one interested in figuring out xyz files.

Thanks, keep up the good work.

PS - Oh, and if this is something that might be helpful - let me know if I should forward any coordinate-conversion scripts I come up with. Eventually, my plan is to try to create some routine in C or Matlab which generates an ssc and xyz file based on an arbitrary mission profile.

[Apollonian]

After playing around with a test object added to the spacecraft.ssc file in the data directory - I have concluded that the xyz conventions actually do follow celestial mechanics conventions at least for heliocentric orbits.

X is the vector point from the Earth to the Sun on the first day of spring. Z is the direction following right hand rule with Earth's orbital direction, normal to the ecliptic. Y is right handed from these two. (X cross Y gives Z)

An interesting point to note. It appears that the program is using splines between xyz samples, another nifty feature of which I was pleasantly surprised to see. Again, Kudos.