Solar System Lagrange Points - FINAL VERSION AVAILABLE

Chuft-Captain · Post #1by **Chuft-Captain** » 13.11.2007, 18:03

Hi,

This addon implements the Sun-Planet lagrange points L1..L5 for the planets, and the Planet-Moon systems for all moons of the solar system which exist within Celestia and have a documented mass at the website mentioned in "Assumptions" below.

DISCLAIMER:
Positional accuracy is limited to the theoretical locations of the libration points based on the limited 3-body approximations.
Further to this, many of the theoretical points defined, in reality will not be stable, or accurate. (This is particularly relevant to systems where there are many perturbative influences, or where the orbits are significantly elliptical eg. Nereid) -- NOTE: Rather than make an executive decision, I have left these in and leave it to the user to remove them as you see fit. Any comments regarding grounds for removal would still be welcome.

NOTE: celURL's may be outdated by future versions.

This is the final version. All Lagrange Points are now implemented as invisible ReferencePoints and therefore un-labelled, however they will be selectable via the ENTER browser. (The DEMO version is deprecated).
ANY PROBLEMS, let me know.

DOWNLOAD LINK -- version 8 (FINAL VERSION)

===============================================
Assumptions:

http://en.wikipedia.org/wiki/List_of_so ... gram_range

Any comments welcome, especially any errors.
Discussion regarding stability is also welcome. (ie. What are the chances of stable L4/L5 points for moons which are very close to large gas-giants?

)

The naming convention I've chosen uses the name of the "minor" body as a prefix.
eg. The Earth-Moon lagrange points are:

Code: Select all

Moon-L1,Moon-L2,...Moon-L5

, whilst the Sun-Earth points are:

Code: Select all

Earth-L1,...Earth-L5

Saturn-Titan system:

Code: Select all

Titan-L1,...etc..

CHANGE LOG:
=========

Systems included in the latest version:

Code: Select all

Earth
   Moon   

Mars   
   Phobos   
   Deimos   
   
Jupiter
   Amalthea
   Io
   Europa
   Ganymede
   Callisto
   Metis
   Adrastea
   Thebe
   Themisto
   Leda
   Himalia
   Lysithea
   Elara
   Ananke
   Pasiphae
   Sinope

Saturn
   Prometheus
   Pandora
   Epimetheus
   Janus
   Mimas
   Enceladus
   Tethys
   Dione
   Rhea
   Titan
   Hyperion
   Iapetus
   Phoebe
   Pan
   Atlas

Uranus
   Miranda
   Ariel
   Umbriel
   Titania
   Oberon
   Cordelia
   Bianca
   Cressida
   Desdemona
   Juliet
   Portia
   Rosalind
   Belinda
   Puck
   Caliban
   Stephano
   Sycorax
   Setebos

Neptune
   Larissa
   Proteus
   Triton
   Nereid
   Naiad
   Thalassa
   Despina
   Galatea

Pluto-Charon

Ceres
Eros

2003 EL61

Cham · Post #2by **Cham** » 13.11.2007, 18:11

Chuft-Captain,

please, edit your post to put your code inside the code brackets, like this :

Code: Select all

bla bla bla

Thanks.

Chuft-Captain · Post #3by **Chuft-Captain** » 13.11.2007, 18:30

Cham,
I think phpBB is truncating it due to it's length.

I'll just have to give you Mercury to Mars for now, and the rest later.

MKruer · Post #4by **MKruer** » 13.11.2007, 18:41

Just out of curiosity, what numbers are you using? my L1 points are slightly different, statistically speaking well within the margin of error, but all the same.

Code: Select all

Mass of Primary (M)   1.99E+30   Sol   
Mass of Child (m)   5.97E+24   Earth   
Distance Between Objects (R)    149,597,870,691   m   

Mass must be greater then 25 to 1 for Lagrange Points to exist         
a = m/(M+m)   0.00000300150      

L1: (R[1-(a/3)^(1/3)])   148,101,642,814   0 Degrees   Between Primary and Child
L2: (R[1+(a/3)^(1/3)])   151,094,098,568   0 Degrees   Past Child
L3: (-R[1+(5/12)*a])   -149,598,057,782   180 Degrees   Far Side of Primary
L4:   149,597,870,691   60 Degrees   Preceding Child
L5:   149,597,870,691   -60 Degrees   Following Child

It might be a good time to revisit this? Adding the Mass option and just calculating the Lagrange Points

http://www.celestiaproject.net/forum/viewtopic.php?t=8640

Chuft-Captain · Post #5by **Chuft-Captain** » 13.11.2007, 18:52

MKruer wrote:Just out of curiosity, what numbers are you using? my L1 points are slightly different, statistically speaking well within the margin of error, but all the same.

The masses are from the wikipedia page quoted in my original post. (I don't always trust WIKI pages but I believe this one is fairly accurate.
The main source of the differences (which should be limited to the planetary systems) is probably due to my very rough approximation of the AU. (I'll use your figure of 149,597,870,691 in the next iteration (what's your source?).

Chuft-Captain · Post #6by **Chuft-Captain** » 13.11.2007, 19:01

OK,

Here's the inner system (including Martian Moons) using MKreur's definition of AU.

EDIT: Corrected code (I think I accidentally switched L4 and L5 ).
L4 should now be leading.

Code: Select all

 
*** DOWNLOAD LINK ADDED TO FIRST POST ***

MKruer · Post #7by **MKruer** » 13.11.2007, 19:08

Chuft-Captain wrote:
MKruer wrote:Just out of curiosity, what numbers are you using? my L1 points are slightly different, statistically speaking well within the margin of error, but all the same.
The masses are from the wikipedia page quoted in my original post. (I don't always trust WIKI pages but I believe this one is fairly accurate.
The main source of the differences (which should be limited to the planetary systems) is probably due to my very rough approximation of the AU. (I'll use your figure of 149,597,870,691 in the next iteration (what's your source?).

Here's the MARTIAN MOON systems:

Code: Select all
*** DELETED *** see below

Oh the Irony http://en.wikipedia.org/wiki/Astronomical_unit

Chuft-Captain · Post #8by **Chuft-Captain** » 13.11.2007, 19:47

MKruer wrote:Oh the Irony http://en.wikipedia.org/wiki/Astronomical_unit

BTW: I've just corrected the code above for a silly typo, so you should GET IT again.

CC

MKruer · Post #9by **MKruer** » 13.11.2007, 21:09

Well Earth is now defined as being 1.000000112 AU or 149,597,887,506m away. Is this proof that the sun is expanding and the reason why the Earth temperature has risen by 1/2 of one degree in the last 100 yrs. Are we soon to be flung out of the solar system. :twisted:

Post #10by **selden** » 13.11.2007, 21:30

Don't forget that the Earth's orbit is elliptical. The AU is an average value. To quote the Wikipedia article: "The Earth is 1.00 ?± 0.02 AU from the Sun" so it's actually unusually close to its nominal distance from the Sun.

ajtribick · Post #11by **ajtribick** » 14.11.2007, 00:20

MKruer: I think it's something to do with the AU being defined for a massless particle with an orbital period of 1 Gaussian year, as opposed to the orbit of the real Earth.

Chuft-Captain · Post #12by **Chuft-Captain** » 14.11.2007, 07:29

SITESLED IS BACK! So I've uploaded a new version (download link in first post)

This version scales the size of the demo spheres (inversely proportional to ALPHA) so that they are more appropriately scaled for viewing at the likely viewing distance, but mainly to prevent them overwhelming smaller moons.

I think this addon has also identified a bug in Celestia's reference frame code which was the cause of the previous comment:

Chuft-Captain wrote:EDIT: Corrected code (I think I accidentally switched L4 and L5 ).
L4 should now be leading.

It turns out, this comment was a red-herring caused by the fact that I ran the addon in 1.5.0pre1 on another PC.
The v5 addon IS actually assigning the correct sign to the L4/L5 points, but when run in in Celestia versions 1.5.3pre3 and pre4, the leading libration point is L5. (L5 should be following, not leading.)

In 1.5.0pre1, L4 is the leading libration point, which is correct.

Please would someone verify this also happens for you using the addon in PRE1 and PRE3/4.

Chuft-Captain · Post #13by **Chuft-Captain** » 14.11.2007, 11:57

Added version 6 (implementing many more moon systems). Download link in first post.

MKruer wrote:]It might be a good time to revisit this? Adding the Mass option and just calculating the Lagrange Points

Yes, in principle I agree with you. The end-goal of this addon is obviously to provide a set of "Invisible" objects about which spacecraft and other objects could orbit, and perhaps allow visualization of some basic interactions of the IPS.
As the maths is quite easy, it would be straighforward to implement in "C" whereby the information in the existing catalogs (with the addition of mass information) would automatically create the valid libration points for each system where the required information exists. This means every user would get them as part of the executable.
However, I think there are many other features which the devs are more interested in implementing, and I'm not sure that there is enough interest amongst users (unfortunately) in libration points for the devs to justify the effort. Although I personally think this is an important feature because it's the basis of the Interplanetary SuperHighway, there seems to be more interest in the Splash Screen. :roll:

And even though I recognize the importance of this feature, I still personally would prefer to see development effort expended on stuff that I can't solve personally (such as Periodic Motion and decoupling of absolute times from XYZ 's --- something that I posted about more than a year ago, but hasn't had a single response in that time

) : http://celestiaproject.net/forum/viewtopic.php?t=10144

(Now that I've committed the effort to the addon I'm also less interested in it being replaced by code in the future :twisted:

)

... but to be serious: once you start comitting to creating celURL's based on these addon objects, then these would all become obsolete or incorrect if the addon was replaced by a future code version. If this was years away, then I'd go with the addon. I guess what we need is an indication one way or the other from the devs.
If there was a clear interest and commitment from the devs to implement this in code within a reasonably short time-frame, then I wouldn't take the addon any further, except as perhaps a useful visualization tool. I certainly wouldn't be locating objects relative to these points or creating celURLS's.

One thing I would like to have clarified by the devs (Chris?) is this:
Regardless of implentation (code versus addon), any libration point's location will change if at some time in the future the catalog information on which it is based was changed. (ie. Known masses of moons are constantly being improved and updated).
The question is: if a user was to create a celURL relative to one of these points, would that celURL then be incorrect if the libration point moved (as above).

MKruer wrote:Earth is now defined as being 1.000000112 AU or 149,597,887,506m away.

MKreur,
Do you think I should use this value?
As I see it, this addon is never going to be particularly accurate anyway, so the difference is going to be well within the existing margins of error, because we're working with formulae which in most cases are a simplified 3-body approximation of a n-body situation.
For these reasons, I suspect many of these libration points will be theoretical only, or at best transiently stable (especially amongst the gas-giant satellite systems).

It's quite interesting however seeing this addon in action and trying to visualize the shortcuts provided by the Interplanetary SuperHighway

Post #14by **chris** » 14.11.2007, 18:10

Chuft-Captain wrote:Added version 6 (implementing many more moon systems). Download link in first post.

MKruer wrote:]It might be a good time to revisit this? Adding the Mass option and just calculating the Lagrange Points
Yes, in principle I agree with you. The end-goal of this addon is obviously to provide a set of "Invisible" objects about which spacecraft and other objects could orbit, and perhaps allow visualization of some basic interactions of the IPS.
As the maths is quite easy, it would be straighforward to implement in "C" whereby the information in the existing catalogs (with the addition of mass information) would automatically create the valid libration points for each system where the required information exists. This means every user would get them as part of the executable.
However, I think there are many other features which the devs are more interested in implementing, and I'm not sure that there is enough interest amongst users (unfortunately) in libration points for the devs to justify the effort. Although I personally think this is an important feature because it's the basis of the Interplanetary SuperHighway, there seems to be more interest in the Splash Screen.

The thing is that it's quite easy to add libration points for any add-on that requires them (as you've done.) Is there really a need for them to be built in, when an add-on does everything that the C code could? Philosophically, I'd like to have Celestia avoid doing any sort of calculations based on gravity--it's really the domain of other applications to integrate trajectories over time. Celestia is about visualization. Libration points are only simple for circular orbits; to do them right requires a lot of calculation that doesn't belong inside of Celestia (and in fact, you consider removing from your add-on the definitions for libration points for extremely elliptical orbits like Nereid's.)

And even though I recognize the importance of this feature, I still personally would prefer to see development effort expended on stuff that I can't solve personally (such as Periodic Motion and decoupling of absolute times from XYZ 's --- something that I posted about more than a year ago, but hasn't had a single response in that time ) : http://celestiaproject.net/forum/viewtopic.php?t=10144

It's a worthwhile feature that I simply haven't had time to code. You can use a ScriptedOrbit for this purpose, but it's a fairly complex solution for a simple problem.

... but to be serious: once you start comitting to creating celURL's based on these addon objects, then these would all become obsolete or incorrect if the addon was replaced by a future code version. If this was years away, then I'd go with the addon. I guess what we need is an indication one way or the other from the devs.
If there was a clear interest and commitment from the devs to implement this in code within a reasonably short time-frame, then I wouldn't take the addon any further, except as perhaps a useful visualization tool. I certainly wouldn't be locating objects relative to these points or creating celURLS's.

One thing I would like to have clarified by the devs (Chris?) is this:
Regardless of implentation (code versus addon), any libration point's location will change if at some time in the future the catalog information on which it is based was changed. (ie. Known masses of moons are constantly being improved and updated).
The question is: if a user was to create a celURL relative to one of these points, would that celURL then be incorrect if the libration point moved (as above).

This is a problem with cel URLs: the positions stored in the URL are absolute, so any change in the position of an object close to the URL will invalidate it. Sorry. It would be better to store positions in the current viewer reference frame instead. Then, provided that the viewer was in a reference frame defined by the object of interest (i.e. you're following or sync-orbiting it), the cel URL would still work even if the orbit of the object was modified.

--Chris

Post #15by **chris** » 14.11.2007, 18:28

Chuft-Captain wrote:I think this addon has also identified a bug in Celestia's reference frame code which was the cause of the previous comment:
Chuft-Captain wrote:EDIT: Corrected code (I think I accidentally switched L4 and L5 ).
L4 should now be leading.
It turns out, this comment was a red-herring caused by the fact that I ran the addon in 1.5.0pre1 on another PC.
The v5 addon IS actually assigning the correct sign to the L4/L5 points, but when run in in Celestia versions 1.5.3pre3 and pre4, the leading libration point is L5. (L5 should be following, not leading.)

In 1.5.0pre1, L4 is the leading libration point, which is correct.

Please would someone verify this also happens for you using the addon in PRE1 and PRE3/4.

The bug was in earlier version of Celestia, not 1.5.0pre4. The definition of how the relative velocity vector works in a TwoVector reference frame is potentially confusing, but it's consistent with RelativePosition. Both RelativeVelocity and RelativePosition are defined by an observer and a target object, with the position or velocity of the target relative to the position or velocity of the observer. Mathematically then, the direction of the RelativePosition vector is:

position(target) - position(observer)

And the direction of RelativeVelocity is:

velocity(target) - velocity(observer)

By default, the observer object is the center of the TwoVector frame. So when you have this:

Code: Select all

TwoVector {
    Center "Sol/Earth"
    Primary {
        Axis "x"
        RelativeVelocity { Target "Sun" }
    }
    ...
}

...you are actually setting the x axis to be in the direction of the velocity of the Sun relative to Earth--backwards from what you were expecting.

One other comment on the add-on . . . I noticed that you are setting the body frame of the libration point objects to be the body frame of the parent object. Is there a reason for this? I'd suggest just omitting the body frame.

--Chris

MKruer · Post #16by **MKruer** » 14.11.2007, 19:23

Chris,

There is another way the LaGrange Points can be defined without need to continually calculate them, that is to simply add them as another orbit and place them at the distance equal to the Lagrange distance and/or degrees offset (-60/60). This is even a better then the previous because the LaGrange points will flex with the highly elliptical orbits. This was my backup to the Venus Parasol Issue, but I had and issue with the Custom Orbit option. The only thing to calculate via mass1:mass2 would be for the initial SemiMajorAxis variations and the starting point of MeanLongitude.

The three main reasons why I think it would be good to include this directly into the source would is because all objects have them providing the 25:1 ratio. I would just limit them to Planets (Dwarf Planets) and Moons only, seriously does anyone care about a comets LaGrange points? Seconds they are good reference points like the celestial grid, addition like the celestial grid you should be able to turn them on or off, because adding 5 additional points per object creates a lot of clutter. Thirdly it gives you a direct relationship in the solar system browser, which is something none of the other options allow for (yet)

Code: Select all

"Earth L1" "Sol"
{
   Texture       ""
   Radius      1000

#   CustomOrbit "vsop87-earth"
   EllipticalOrbit {   
      Period             1.0000
      SemiMajorAxis      0.99
      Eccentricity       0.0167
      Inclination        0.0001
      AscendingNode    348.739
      LongOfPericenter 102.947
       MeanLongitude    100.464
   }
}

Unfortunately if you use the custom orbit option, this will not work, the Orbit is Defaulted to 1AU

BTW:
Since the SI has now defined Dwarf Planets, any chance of getting that into Celestia as a class of object? That would be Ceres, Pluto and Eris, though Pluto and Eris are also KBO?€™s which I think should be a class as well.

EDIT: for clarity

Cham · Post #17by **Cham** » 14.11.2007, 19:30

MKruer wrote:BTW:
Since the SI has now defined Dwarf Planets, any chance of getting that into Celestia as a class of object? That would be Ceres, Pluto and Eris, though Pluto and Eris are also KBO?€™s which I think should be a class as well.

Oh yesss, we definitely need more classes of SSC and DSC objects (custom classes, etc). I already asked for this before, since a long time.

MKruer · Post #18by **MKruer** » 14.11.2007, 19:39

Cham wrote:
MKruer wrote:BTW:
Since the SI has now defined Dwarf Planets, any chance of getting that into Celestia as a class of object? That would be Ceres, Pluto and Eris, though Pluto and Eris are also KBO?€™s which I think should be a class as well.

Oh yesss, we definitely need more classes of SSC and DSC objects (custom classes, etc). I already asked for this before, since a long time.

I think just about everyone has. :twisted:

As more information is added, it becomes even more important to quantify and classify objects.

Chuft-Captain · Post #19by **Chuft-Captain** » 17.11.2007, 08:22

chris wrote:...The definition of how the relative velocity vector works....

Thanks for the detailed explanation -- all becomes clear now.
It's very easy for me to reverse the sign of the Y component of the L4 and L5 definitions.
(So L4 will be -sqrt(3)/2*R and L5 will be +sqrt(3)/2*R in Celestia. )

chris wrote: . . I noticed that you are setting the body frame of the libration point objects to be the body frame of the parent object. Is there a reason for this? I'd suggest just omitting the body frame.

This is a leftover from when I first started on the add-on and was contemplating using models for the L points in the demo mode/version:

... so that they could be viewed from above the ecliptic (without spinning too much), like so:

I've since abandoned this idea as I don't think it adds any real value... I think spheres will be fine for visualization purposes.
.. and in "invisible" mode, which I imagine will be the most common use, the orientation and rotation of the LPoint is superfluous....

... UNLESS, the bodyframe orientation of the LPoint defines the default equatorial reference for the orbits of any objects around it. Is this the case?
(If so, then it might still be useful for standardizing those orbits, otherwise I'll just remove it as you suggest)

Chuft-Captain · Post #20by **Chuft-Captain** » 17.11.2007, 09:07

chris wrote:The thing is that it's quite easy to add libration points for any add-on that requires them (as you've done.) Is there really a need for them to be built in, when an add-on does everything that the C code could? Philosophically, I'd like to have Celestia avoid doing any sort of calculations based on gravity--it's really the domain of other applications to integrate trajectories over time. Celestia is about visualization. Libration points are only simple for circular orbits; to do them right requires a lot of calculation that doesn't belong inside of Celestia (and in fact, you consider removing from your add-on the definitions for libration points for extremely elliptical orbits like Nereid's.)

To be honest, I've a foot in each camp. There's pros and cons of both approaches.
A "coded" solution:

I understand and agree with your philosophical comments, but I think you're talking about something else altogether.
There's no *integration of trajectories over time* going on here. We're not talking here about modelling the "real" behaviour of a body in a gravity field. I'm simply implementing some algebraic derivations of Lagrange's result: http://www.physics.montana.edu/faculty/ ... grange.pdf which have mass and semimajoraxis as variables.

I think your main concern is that the lagrange co-ordinates would have to be calculated within the render loop, but I don't think that's the case, as they have nothing to do with "integration over time". They could be calculated once at "catalog load time" if the mass value was known.

On the other hand, the formulae are a 3-body approximation, so are unlikely to be up to your standards of scientific accuracy in the N-body case, so that is probably an argument for it remaining as an addon.