New "plug-in" for Celestia

[Cham]

This message, in French, is for Vincent. Sorry guys, but I'm forced to use the forum directly because there's apparently a huge problem with PM (white page bug... Please Chris, this is urgent and needs a solution with LaTeX enabled).

Vincent, voici les fonctions ? utiliser pour remplir la fen?tre :

Soient [tex]r[/tex] et [tex]v[/tex], respectivement la distance et la vitesse instantan?e de l'objet s?lectionn? (variables donn?es par Celestia). J'introduit alors les deux fonctions suivantes (sans dimension et strictement positives) :

[tex]u(r, v, T) = \frac{v T}{2\pi r}[/tex]

[tex]F(r, v, T) = (1 + 6*9 u^2 + 6 u \sqrt(3 + 9^2 u^2) )^\frac{1}{3}[/tex]

alors :

[tex]a(r, v, T) = \frac{r}{6}(1 + F + \frac{1}{F})[/tex] ?qu. (1)

ce qui forme la solution alg?brique de l'?quation obtenue en combinant l'?nergie totale de l'objet (par unit? de masse) et la 3e loi de Kepler (pour ?liminer la masse du parent) :

[tex]\frac{E}{m} = \frac{v^2}{2} - \frac{G M}{r} \equiv - \frac{G M}{2 a}[/tex],

ce qui implique l'?quation suivante (en utilisant [tex]T^2 = \frac{4 \pi^2}{G M} a^3[/tex]) :

[tex](\frac{v T}{2 \pi})^2 = \frac{2 a^3}{r} - a^2[/tex]

La solution de cette ?quation est donn?e par l'?quation (1) ci-haut.

Connaissant maintenant le demi-grand-axe [tex]a[/tex], la masse [tex]M[/tex]du parent sera alors simplement :

[tex]M(T, a) = \frac{4 \pi^2 a^3}{G T^2}[/tex]

L'excentricit? s'exprime en fonction du moment angulaire par unit? de masse ([tex]\ell \equiv L/m[/tex]) :

[tex]e = \sqrt(1 - (\frac{\ell T}{2\pi a^2})^2)[/tex] ?qu. (2)

o? le moment angulaire [tex]\ell[/tex] peut ?tre calcul? comme suit :

[tex]\ell = r \sqrt(v^2 - v_{rad}^2)[/tex]

o? [tex]v_{rad} = \vec{\bold{r}} \bullet \vec{\bold{v}} /r[/tex] est la vitesse radiale. Je ne sais pas si Celestia peut calculer automatiquement ces vecteurs (je pense bien que oui). ? confirmer, s.v.p.

Pour certains objets (sonde spatiale, comme Voyager 2 ?), il est possible que [tex](\frac{\ell T}{2\pi a^2})^2 > 1[/tex]. Dans ce cas, l'excentricit? (2) n'est pas d?finie ? l'aide des formules pr?c?dentes. Celestia doit alors afficher quelque chose comme "param?tre non-d?fini", ou "mouvement hyperbolique".

Note importante : Ces ?quations ne sont valables que si l'objet tourne autour du parent, ce dernier ?tant beaucoup plus lourd que l'autre ; M >> m. Pour des objets se d?pla?ant autour d'un centre de masse de type "barycenter" (ex : Pluton-Charon, ou syst?me binaire d'?toiles), il va falloir apporter une petite modification, probablement mineure (je ferai ?a plus tard).

Par contre, je me pose des questions au sujet des objets qui n'ont pas de p?riode de r?volution d?finie dans leur fichier SSC (plan?te avec CustomOrbit, astronef avec fichier XYZV, etc). Les fonctions ci-haut reposent enti?rement sur la donn?e de la p?riode orbitale, que peut fournir Celestia. Que va-t-il se passer pour les objets d?finis par une trajectoire custom ?

En ce qui concerne la temp?rature ("Temp?rature locale du rayonnement", ou "Temp?rature locale" pour abr?ger), le calcul est standard et ne devrait pas poser de probl?mes...

Enfin, la "lourdeur" des ?quations ci-haut me fait un peu peur pour le frame rate de Celestia (surtout en ce qui concerne l'?quation (1)). J'esp?re qu'il n'y aura pas d'impact notable. Qu'en penses-tu ?

-Martin.

[Vincent]

For interested people, Martin and I are currently working on a Lua addon that
dynamically computes and displays Keplerian Variables for the selected object.

Here's a screengrab (French version):

[Hungry4info]

Wow, cool! I'm certainly interested.

[Cham]

We're testing various formats and rendering styles, and of course feverishly testing the accuracy of data (which is the most important part!). The window can be grabbed with the mouse and moved continuously at any place on the screen. Really usefull !

Here's a test version (the colors and borders shown here are temporary) :


Using this tool, we can already state that many "realist" addons are actually unreliable ! Many comets, asteroids and spacecraft addons are giving wrong values to the mass of our Sun or some planets. According to the plug-in, the data defined in the SSC files of these addons is unreliable. So this new plug-in appears to have a usefullness which goes beyond what we planned at first : it may also be used as a kind of "data accuracy revelator".

I must insist on the proper interpretation of the data shown in the plug-in window : it's all about instantaneous keplerian parameters. A real planet like Mars (for example) isn't moving on a simple keplerian ellipse, since there are influences from other planets (mostly Jupiter...). Celestia is currently using a good approximation of the real path (vsop87), so our plug-in may gives values that are "fluctuating" in time for the semi-major axis and the eccentricity (which are constants, on a simple keplerian orbit). This is perfectly normal.

Also, take note that the temperature given by Celestia will be removed from version 1.6.1 (it's actually gone from the SVN code). The plug-in is keeping the instantaneous temperature with us. We haven't decided yet if we'll show the radiation temperature only (without the albedo effect), the albedo-dependant temperature, or both. Any though on this ?

[ajtribick]

Nice one here... always thought it would be good to have orbital parameters displayed in Celestia. (Incidentally it would be nice to have the code for solving the Kepler equation accessible from script too.)

Might be better instead of messing around with potentially confusing terms like temperature to go for energy flux at the given distance from the Sun.

[Cham]

Might be better instead of messing around with potentially confusing terms like temperature to go for energy flux at the given distance from the Sun.

I tend to agree. I'm not sure of the better way to present this data yet. I feel that "local radiation temperature" is an interesting (educational) parameter.

Please guys, I need your opinion : how many significant digits do you think is best ? 3, 4 or 5 ? Examples :

semi-major axis : 3.21 au
semi-major axis : 3.214 au
semi-major axis : 3.2143 au

With 4 and 5 significant digits, we can clearly see some fluctuations with time (which can be instructive), but the last digits are certainly unreliable. With 3, we don't see the variations, and the values are easier to read on the screen.

I'm yet unable to decide !

[Fenerit]

Hi there! This is a REAL plugin!!! I can't wait. About orbital parameters and corrections, one link that I know is here:
http://www.braeunig.us/space/orbmech.htm#perturbation )(thanks Selden!)
If is interesting.

[duds26]

Generally more significant digits are better, but if the last ones are unreliable it's better to stick to 3.
Considering your fourth and fifth number are unreliable they haven' t much value.

[Cham]

Vincent,

voici les r?sultats pour les syst?mes binaires...



Le point rouge repr?sente le "barycentre" du syst?me, que je vais appeler le "corps parent" des objets 1 et 2. Dans Celestia, lorsque nous s?lectionnons l'objet 1, nous avons acc?s directement ? sa distance [tex]r_1[/tex] et ? sa vitesse [tex]v_1[/tex] instantan?es par rapport ? son parent. Connaissant la p?riode orbitale [tex]T[/tex] (qui est la m?me pour 1 et 2), nous calculons le demi-grand axe [tex]a_1[/tex] et l'excentricit? [tex]e_1[/tex] (et aussi le p?rih?lie et l'aph?lie) EXACTEMENT comme avant, sans aucune modification au code. Ceci est possible gr?ce ? une "conspiration math?matique" dans les ?quations du mouvement ! Mais attention ! L'excentricit? est la m?me pour les deux objets ([tex]e_1 = e_2 \equiv e[/tex]), mais le demi-grand axe n'est pas le m?me :

[tex]\mu = \frac{m_1 m_2}{m_1 + m_2}[/tex] = "masse r?duite" du syst?me,

[tex]M = m_1 + m_2[/tex] = masse totale du syst?me,


[tex]a_1 = \frac{\mu}{m_1} a[/tex],

[tex]a_2 = \frac{\mu}{m_2} a[/tex],

[tex]a = a_1 + a_2[/tex].

On a instantan?ment (en tout temps) :

[tex]r = r_1 + r_2[/tex],

[tex]m_1 r_1 = m_2 r_2 \equiv \mu r[/tex].

L'?quation de l'?nergie totale s'?crit comme avant, mais il y a des diff?rences :

[tex]E = \frac{1}{2} \mu v^2 - \frac{G m_1 m_2}{r} = - \frac{G M \mu}{2 a}[/tex],

o? [tex]v[/tex] est la vitesse relative entre les deux corps (telle que [tex]m_1 v_1 = m_2 v_2 = \mu v[/tex]). La troisi?me loi de Kepler s'?crit avec la masse totale du syst?me (comme avant, mais ce n'est pas la masse du "parent". C'est l? une subtilit? importante ! :

[tex]GM = \frac{4 \pi^2 a^3}{T^2}[/tex].

Des manipulations alg?briques simples permettent de trouver les ?quations suivantes, en fonction des variables de l'objet 1 seulement (ce qui est accessible ? Celestia, en s?lectionnant l'objet 1) :

[tex]a_1(r_1, v_1, T) = \frac{r_1}{6}(1 + F + \frac{1}{F})[/tex], avec la m?me fonction qu'avant (pas de diff?rence dans le code !).

M?me chose pour l'excentricit?, puisque les masses n'apparaissent pas dans la formule utilis?e dans le code.

Par contre, on obtient pour la masse une quantit? fictive pour le "parent", qui ne sera pas la m?me selon qu'on s?lectionne l'objet 1 ou l'objet 2 :

[tex]\frac{4 \pi^2 (a_1)^3}{G T^2} = \frac{(m_2)^3}{M^2} = M_{p 1}[/tex]

[tex]\frac{4 \pi^2 (a_2)^3}{G T^2} = \frac{(m_1)^3}{M^2} = M_{p 2}[/tex]

Remarques les indices invers?s dans les fractions (ce n'est pas une erreur). On a [tex]M_{p 1}[/tex] et [tex]M_{p 2} < M[/tex] et [tex]M_{p 1} + M_{p 2} \neq M[/tex]

En cons?quence, nous avons un choix ? faire au sujet de la masse affich?e par le plug-in. Donnerons-nous la masse fictive [tex]M_{p 1}[/tex] pour l'objet 1, ou un double-tiret indiquant une quantit? ind?termin?e ?

Par contre, si le code est augment? de sorte ? d?terminer les deux masses fictives [tex]M_{p 1}[/tex] et [tex]M_{p 2}[/tex] (ou plut?t les deux demi-grand axes [tex]a_1[/tex] et [tex]a_2[/tex]), en s?lectionnant l'objet 1 seulement, nous pourrons afficher le rapport des masses [tex]m_1[/tex] et [tex]m_2[/tex] du syst?me, ou la masse totale, ou encore les deux masses individuelles :

[tex]\frac{m_1}{m_2} = \frac{a_2}{a_1}[/tex]

[tex]M = \frac{4 \pi^2}{G T^2}(a_1 + a_2)^3[/tex]

ou encore :

[tex]m_1 = \frac{4 \pi^2}{G T^2} a_2 (a_1 + a_2)^2[/tex] ?qu. (3)

[tex]m_2 = \frac{4 \pi^2}{G T^2} a_1 (a_1 + a_2)^2[/tex] ?qu. (4)

Remarques les indices invers?s. Les calculs du plug-in seront probablement plus lourds (?), puisque le code devra d?terminer les caract?ristiques de l'autre objet du syst?me en s?lectionnant un seul d'entre-eux ! Mais l?, c'est toi l'expert...

Conclusion : Ainsi, le plug-in pourrait donner la masse de l'objet 1 en le s?lectionnant ! Ceci est possible gr?ce au mouvement du deuxi?me objet ([tex]a_2 \neq 0[/tex]). Bien entendu, nous retrouvons le cas particulier du corps tr?s l?ger en pr?sence d'un corps central tr?s lourd, lorsque [tex]m_2 >> m_1[/tex] et [tex]a_2 \approx 0[/tex].

[Vincent]

Martin,

I'm afraid we have to face a major issue here : orbital Period is not returned for stars...

[t00fri]

I'm afraid we have to face a major issue here : orbital Period is not returned for stars...

All these familiar Kepler formulae that Martin wrote above, are used in my Perl script that is part of the Celestia distribution and serves to printout the visualbins.stc and spectbins.stc orbital data. The Period of my visual and spectroscopic binaries is read into Celestia along with the other orbital parameters, and can be gotten from there ...

So I don't see what the problem is? But probably I am not informed well enough about what you are doing here.

Fridger

[Vincent]

Fridger,

All these familiar Kepler formulae that Martin wrote above, are used in my Perl script that is part of the Celestia distribution.

I'm of course also familiar with the Kepler formulae, at least since I finished secondary school...
The issue here is to know which values are accessbile from Lua, and which need to be computed...
So, we use the forum for its LaTeX facilities...

The Period of my visual and spectroscopic binaries is read into Celestia along with the other orbital parameters, and can be gotten from there ...

So I don't see what the problem is? But probably I am not informed well enough what you are doing here.

The problem is simply that we currently can't get the orbital Period from the Lua interface.

[t00fri]

Thanks Vincent, for explaining...

Fridger

[Cham]

Martin,

I'm afraid we have to face a major issue here : orbital Period is not returned for stars...

I was expecting something like this in the case of stars, I don't know why. Well then, too bad for stars...

[Vincent]

Thanks Vincent, for explaining...

Fridger, you're welcome.

I was expecting something like this in the case of stars, I don't know why. Well then, too bad for stars...

The qt4 version of Celestia already includes an Info Browser which displays orbital elements for bodies.
I'll work on adding orbital elements for binary stars as well...


Attached is an english test-version of the plug-in

HOW TO INSTALL THE PLUG-IN ?
1- Unzip and paste the 'Keplerian_parameters' folder in your 'extras' folder.
2- Paste the 'luahookinit.lua' file in your Celestia root folder.
3- Add this line to your celestia.cfg file :
Configuration
{
LuaHook "luahookinit.lua" # <-- Line to add
...

The plug-in is for use with Celestia 1.6:
http://www.celestiaproject.net/celestia/download.html

HOW TO USE THE PLUG-IN ?
- The Dynamic Keplerian parameters window is automatically displayed when the selected object
is of one of the following types : planet, dwarfplanet, moon, minormoon, asteroid, comet, spacecraft.
As to spacecraft, some of the parameters may not be displayed when orbits are defined using xyzv files.
- The display of the Dynamic Keplerian parameters window can be enabled / disabled using [Ctrl] + [x].

[Cham]

This plug-in is getting more and more interesting, especially when applied to the exoplanets :





And it's also extremely usefull to detect errors in addons or SSC innacuracies.

[Fenerit]

.
.
.
The problem is simply that we currently can't get the orbital Period from the Lua interface.

In the case that were added, please do not forget to return also the phase angle.

[Cham]

The plug-in has evolved a lot since the last message. Here's a preview of what we have now :

[Vincent]

In the case that were added, please do not forget to return also the phase angle.

Massimo,

Unlike the orbital period for binary stars, the phase angle can be computed very easily from other available values.
Here's a script that does it (save in UTF-8 format to display degree symbol):

Code: Select all

-- Title: Display Phase Angle

getStar = function(obj)
    parent = obj;
    while parent:type() ~= "star" do
        parent = parent:getinfo().parent
    end
    return parent
end

getPhaseAngle = function(obj, obs)
    star = getStar(obj);
    obs_vec = obj:getposition() - obs:getposition()
    star_vec = (obj:getposition() - star:getposition()):normalize()
    return math.acos(star_vec * ((1.0 / obs_vec:length()) * obs_vec));
end

while true do
    sel = celestia:getselection()
    if sel:name() ~= "?" then
        obs = celestia:getobserver()
        phase_angle = getPhaseAngle(sel, obs)
        if phase_angle >= 0 and phase_angle <= 180 then
            celestia:print(string.format(" Phase Angle: %0.2f°", math.deg(phase_angle)))
        end
    end
    wait(0)
end

[ajtribick]

This plug-in is getting more and more interesting, especially when applied to the exoplanets :

...

And it's also extremely usefull to detect errors in addons or SSC innacuracies.

Working from the orbit back to the central mass is probably going to give inconsistent stellar masses in the multiplanet systems, if only because of parameters being quoted to a limited degree of precision appropriate to the observational errors on the quantities.

(On the other hand, all this reminds me that a while back I was messing around with the significantly non-Keplerian system around Gliese 876, I should probably take another look at that one)