Mouvement des astres du Système Solaire

[henryallen]

Bonsoir,

Pour m’amuser et m’entraîner en Python, j’ai voulu faire une simulation des mouvements des astres au sein du Système Solaire.

En voici le fonctionnement : je considère chaque corps un par un, je détermine la somme vectorielle des forces qui lui sont appliquées (en utilisant la formule de la gravitation de Newton : ), j’en déduis son vecteur accélération par la deuxième loi de Newton (), j’en déduis la variation de vitesse durant un court intervalle, puis par conséquent la variation du vecteur position. Finalement, j’obtiens donc les nouvelles coordonnées de chaque corps après un court intervalle de temps.

C’est donc ce que j’ai fait dans un premier temps avec la Terre et le Soleil (à ce niveau, aucun problème, tout fonctionne), avant de tenter de rajouter la Lune. Et là, problème : ma Lune s’écrase sur le Soleil.

Je tiens à préciser que j’ai utilisé, pour les distances, masses et vitesses, les vraies valeurs (ou du moins des arrondis suffisamment proches selon moi), en ajustant avec des échelles de temps et de longueur.

Ainsi, je ne comprends pas pourquoi la Lune n’orbite pas autour de la Terre (et, de plus, en calculant la force gravitationnelle exercée par le Soleil sur la Lune, et celle exercée par la Terre sur la Lune, je trouve que la première est supérieure à la seconde …).

Je me doute que présenté ainsi, sans code aucun, mon problème peut paraître assez abstrait, mais je ne sais pas où le poster, dans la mesure où dans la partie programmation du forum, le problème potentiel serait l’utilisation des lois physiques, et ici, mon programme pourrait sembler déplacé … Si cependant vous considérez que c’est bien dans le forum de programmation que ce fil a sa place, libre à un administrateur passant par là de le déplacer

Ainsi, si vous pouviez m’aider en repérant dans le raisonnement présenté ci-dessus une éventuelle erreur qui pourrait expliquer mon problème (la disposition initiale doit-elle être choisie précisément ? Est-ce que j’ai fait des hypothèses fausses, une mauvaise application des lois ? …), je vous en serais reconnaissant.

Merci d’avance,
Bonne soirée.
-----

[Calvert]

Salut !

Mauvaises conditions initiales ? Comment as-tu obtenu la vitesse de la Lune que tu injectes au départ ?

[yves95210]

Bonsoir,

ça ressemble plutôt à un bug de programmation ou dans l'initialisation des variables. Donc ça serait peut-être plus facile de te répondre si tu nous mettais ton code en pièce jointe (je n'ai jamais programmé en Python, mais je suppose que ça se lit bien, du moment qu'on connaît d'autres langages)...
Ou alors il faudrait que tu décrives de manière plus détaillée ton algorithme, et les valeurs initiales de tes variables. Première idée qui me vient à l'esprit au vu du problèmes que tu décrits : le vecteur vitesse de la Lune est-il bien initialisé ? (en tenant compte du référentiel dans lequel tu travailles)

[LeMulet]

Première idée qui me vient à l'esprit au vu du problèmes que tu décrits : le vecteur vitesse de la Lune est-il bien initialisé ? (en tenant compte du référentiel dans lequel tu travailles)

Bien vu.
Si le vecteur vitesse de la Terre n'a pas été ajoutée au moment de définir les valeurs initiales à celui de la Lune, ça peut expliquer le problème.

[A voir en vidéo sur Futura]

[yves95210]

Hier soir je n'ai pas vu que Calvert avait répondu plus vite que moi.
Mais je vois qu'on a tous la même idée... J'espère que henryallen nous confirmera que c'était bien la cause de son problème.

[Calvert]

Hier soir je n'ai pas vu que Calvert avait répondu plus vite que moi.

Pas de soucis, ta réponse était plus détaillée que la mienne !

[Deedee81]

Salut,

Attention à ce type de simu pas-à-pas, ce n'est pas trivial. Je l'avais déjà fait et j'ai eut la surprise de voir la Lune s'échapper.... à cause d'une divergence des calculs

Mais ici je pense plutôt comme les coreligionnaires qu'il s'agit d'un problème d'initialisation des données.

[LeMulet]

Attention à ce type de simu pas-à-pas, ce n'est pas trivial. Je l'avais déjà fait et j'ai eut la surprise de voir la Lune s'échapper.... à cause d'une divergence des calculs

Je ne sais pas ce que vous appelez "divergence des calculs".
Par contre, et on parle peut-être de la même chose, il est certain que le "pas temporel" (le temps écoulé entre chaque itération, pour faire simple) doit être adapté aux déplacements en jeu.

Parfois, dans les simulations, on fait varier dynamiquement la durée d'un pas en fonction des "distances de déplacement par pas" (ce qui équivaut à vérifier que la norme du vecteur vitesse de tous les objets ne dépasse pas un certain seuil).

D'autre part, même si pour le moment sans connaitre ni le code ni le niveau technique de la simulation on ne peut pas préjuger de la question, il est peut-être bon de rappeler que pour éviter un "effet de bord", l'accélération calculée par objet (Terre, Lune, Soleil) ne doit être appliquée à la position qu'une fois toutes les accélérations calculées.
On calcule l'accélération de chaque objet (et on stocke la valeur), puis, une fois cette phase terminée, on applique cette accélération à la vitesse de chaque objet dont on peut cette fois (si on ne tient pas compte des collisions) directement déduire la position.

[phys4]

Ainsi, je ne comprends pas pourquoi la Lune n’orbite pas autour de la Terre (et, de plus, en calculant la force gravitationnelle exercée par le Soleil sur la Lune, et celle exercée par la Terre sur la Lune, je trouve que la première est supérieure à la seconde …).

Bonjour,
Petit complément aux réponses précédentes : la force exercée par le Soleil est en effet plus grande que celle de la Terre, c'est normal et cela n’empêche pas la Lune d'orbiter autour de la Terre.

Une conséquence est que la courbure de la trajectoire lunaire en système héliocentrique est toujours tournée vers le Soleil.

[Deedee81]

Je ne sais pas ce que vous appelez "divergence des calculs".

Par exemple une équation différentielle (avec condition initiale donnée) qui converge, on discrétise, on programme et là ça ne converge pas.
Un grand classique en calcul numérique.

Tout à fait d'accord avec le reste.
Il faut vérifier trois choses :
- si la discrétisation ne provoque pas la divergence (ça arrive, il y a des tests mathématiques pour vérifier ça. Mais je ne me souviens plus lesquels, j'ai vu ça il y a trente ans).
- si le pas est correct, comme tu l'expliques (c'était mon problème dans ma simu d'orbites)
- si la précision des nombres flottants est suffisant (j'ai eut cette mauvaise surprise dans une simulation en automatique pendant mon travail de fin d'étude, j'ai dû écrire ma propre librairie de calcul en Fortran pour régler cette difficulté).

[henryallen]

Bonjour,

Tout d'abord, merci pour toutes vos réponses !

Il est vrai qu'initialement, assez bêtement, je n'avais pas pensé à ajouter la vitesse de la Terre autour du Soleil à celle de la Lune autour de la Terre ... C'est chose faite. Mais ... le problème reste le même.

Cependant comme l'a fait remarquer LeMulet, je fais bouger mes corps un à un, ce que je devrais éviter de faire. De plus, ma gestion du temps (correspondance temps simulation / temps réel) me semble très probablement fautive (ou tout du moins fausse).

Là maintenant, je ne peux pas corriger ces défauts, je pense que je pourrai m'y atteler plus tard dans la journée.

En attendant, voici mon code (attention, il n'est pas du tout optimal, beaucoup de choses seraient sûrement à modifier):

import tkinter as tk
from math import sqrt

G = 6.67 * 10**(-11)

class Corps:
    def __init__(self, x, y, masse, vx, vy, rayon, couleur = "green"):
        """Constructeur de la classe."""
        self.x, self.y = x, y
        self.masse = masse
        self.vitesse = [vx, vy]
        self.acceleration = [0, 0]
        self.rayon = rayon #Sert uniquement pour l'affichage.
        self.couleur = couleur
    def bouger(self, liste_corps, dt):
        """Réajuste les coordonnées du corps."""
        sommeForces = [0, 0]
        #Pour chaque corps, on détermine l'attraction gravitationnelle sous forme vectorielle.
        for corps in [corps for corps in liste_corps if corps != self]:
            distance = sqrt((corps.x-self.x)**2+(corps.y-self.y)**2)
            vecteurUnitaire = [(corps.x-self.x)/distance, (corps.y-self.y)/distance]
            sommeForces = [sommeForces[0] + G * corps.masse * self.masse *  vecteurUnitaire[0] / (distance * echelleDistance)**2, sommeForces[1] + G * corps.masse / (distance * echelleDistance)**2 * self.masse * vecteurUnitaire[1]]
        #On applique la deuxième loi de Newton.
        self.acceleration = [sommeForces[0] / self.masse, sommeForces[1] / self.masse]
        #accélération = dérivée de la vitesse par rapport au temps.
        self.vitesse = [self.vitesse[0] + self.acceleration[0] * dt, self.vitesse[1] + self.acceleration[1] * dt]
        #vitesse = dérivée de la position par rapport au temps.
        self.x, self.y = self.x + self.vitesse[0] * dt / echelleDistance, self.y + self.vitesse[1] * dt / echelleDistance

fenetre = tk.Tk()
canvas = tk.Canvas(fenetre, height = 700, width = 700)

#Dans l'ordre: Soleil, Terre, Lune.
listeCorps = [Corps(350, 350, 2 * 10**30, 0, 0, 10, "yellow"), Corps(100, 350, 6 * 10**24, 0, 30000, 3, "blue"), Corps(100, 350.64, 7.34 * 10**22, 1022 + 30000, 0, 3, "red")]

#Dictionnaire contenant les cercles du Canvas.
dicoCercles = {}
for i in range(len(listeCorps)):
    dicoCercles[i] = canvas.create_oval(listeCorps[i].x - listeCorps[i].rayon, listeCorps[i].y - listeCorps[i].rayon, listeCorps[i].x + listeCorps[i].rayon, listeCorps[i].y + listeCorps[i].rayon, fill = listeCorps[i].couleur)

dt = 10000 #1 unité de temps dans la simulation => dt unité de temps en réalité.
echelleDistance = 149.6 * 10**9 / 250 #250 pixels (?) correspondent à une Unité Astronomique.

def mouvement():
    for i in range(len(listeCorps)):
        #Suppression du cercle, mouvement, création du cercle.
        canvas.delete(dicoCercles[i])
        listeCorps[i].bouger(listeCorps, dt)
        dicoCercles[i] = canvas.create_oval(listeCorps[i].x - listeCorps[i].rayon, listeCorps[i].y - listeCorps[i].rayon, listeCorps[i].x + listeCorps[i].rayon, listeCorps[i].y + listeCorps[i].rayon, fill = listeCorps[i].couleur)
    canvas.pack()
    canvas.after(1, mouvement) #On attend 1 milliseconde et on recommence.

mouvement()
fenetre.mainloop()

Merci encore,
Bonne journée

[yves95210]

Il est vrai qu'initialement, assez bêtement, je n'avais pas pensé à ajouter la vitesse de la Terre autour du Soleil à celle de la Lune autour de la Terre ... C'est chose faite. Mais ... le problème reste le même.

Si je ne me trompe pas en lisant le code, tu as inversé les coordonnées x et y du vecteur vitesse de la Lune par rapport à celles de la Terre. Ce qui a pour effet de donner à la Lune une vitesse initiale de 30 km/s en direction du Soleil. Pas étonnant qu'elle tombe

Cependant comme l'a fait remarquer LeMulet, je fais bouger mes corps un à un, ce que je devrais éviter de faire.

Je suis d'accord avec la remarque.
Avec un intervalle de temps assez petit (tel que durant cet intervalle la distance parcourue par la Terre reste très inférieure au rayon de l'orbite de la Lune) ça ne devrait pas avoir trop d'impact. Mais là, en 10000 s, la Terre a parcouru 300000 km et a laissé la pauvre Lune loin derrière elle

Sans modifier ton algorithme tu pourrais essayer de prendre dt = 100. Sauf que ta simulation risque de ne pas avancer très vite... Il va falloir plus de trois jours pour que la Terre fasse le tour du Soleil (mais si tu n'as pas le temps de faire mieux, ça te permettra quand-même de vérifier au bout de quelques heures que la Lune ne tombe plus vers le Soleil)
Donc il vaut mieux appliquer directement la solution proposée par LeMulet.

[eudea-panjclinne]

Il faut aussi considérer la méthode d'intégration numérique qui, sauf erreur, est ici une méthode d'Euler à l'ordre 1 (O(h)). Si la méthode marche relativement bien avec deux corps et un pas petit, elle diverge rapidement quelque soit le pas avec plus de deux corps. Une bonne méthode d'intégration numérique, c'est à dire avec un bon rapport qualité - complexité à programmer est la méthode de Runge-Kuta à l'ordre quatre, O(h^4). C'est une méthode qui est souvent utilisée dans les petits logiciels de simulation des planètes avec un certain succès sur des périodes pas trop longues.

[henryallen]

Bonjour,

Déjà, merci à tous / toutes pour vos réponses

@yves95210: Je me sens vraiment bête pour le coup ... Je ne sais pas comment j'ai fait, mais en effet les coordonnées du vecteur vitesse étaient inversées. Après rectification, ça marche ... Donc Calvert, yves95210, LeMulet, vous aviez raison !

Je vais également essayer de m'intéresser à une meilleure gestion du temps (peut-être pourrais-je garder une même valeur de dt, mais faire les calculs des trajectoires sur des intervalles de temps plus courts. Le résultat serait que, certes, les calculs seraient plus longs, mais plus précis, et visuellement on aurait toujours un affichage de dt en dt. A voir ...).
Après modification de la vitesse de la Lune, et le calcul des forces fait simultanément pour tous les corps, je trouve une période d'un peu plus de 26 jours pour la Lune. Un peu en-deçà de la réalité, mais en modifiant les imprécisions, le résultat devrait être meilleur (et je m'estime déjà satisfait de ceci ...).

@eudea-panjclinne: Merci, je vais essayer, à l'occasion, d'approfondir le sujet. Je dois cependant avouer que je ne suis pas vraiment très au point au niveau des équations différentielles ... Et ici, je ne suis pas sûr de voir quelles équations entrent en jeu (certes, position, vitesse et accélération sont liées par dérivations successives de la première, mais je ne dispose pas d'une "vraie" équation, si ?).

Je vais peut-être essayer, après avoir amélioré le programme, de rajouter de plus en plus de corps (mais bon, cela risque de devenir extrêmement lent et imprécis ...).

@Dedee81: Je dois reconnaître que je ne me suis pas intéressé à la précision des nombres flottants ici, mais il faudrait que j'y fasse attention en effet ... Je me rappelle que dans un programme, je manipulais des entiers, et que je testais certaines conditions. Or celles-ci me retournaient constamment False, simplement parce qu'un calcul devant donner 2 en théorie me donnait quelque chose comme 1.9999999997 ... A voir donc !

@phys4: Désolé, voici une réponse assez tardive, mais je n'arrive pas à comprendre: pourquoi cette différence de forces n'empêche-t-elle pas que la Lune orbite autour de la Terre ?

Encore une fois merci à tout le monde !
Bonne fin de journée

[pm42]

@phys4: Désolé, voici une réponse assez tardive, mais je n'arrive pas à comprendre: pourquoi cette différence de forces n'empêche-t-elle pas que la Lune orbite autour de la Terre ?

La Lune et la Terre tournent toutes les 2 autour du Soleil. Mais l'orbite de la Lune est perturbée régulièrement par l'attraction terrestre. Vu du Soleil, cela fait des "petites boucles". Vu de la Terre, cela fait une orbite autour de nous.
Version simple et imagée, tu vas sans doute avoir plus détaillé ou mieux, ou les 2.

[henryallen]

Merci pour la réponse.

Du coup l'idée (certes non présentée scientifiquement) serait que la Lune, comme les planètes du Système Solaire, tourne autour du Soleil selon une ellipse, mais que la présence de la Terre perturbe son orbite (d'où un mouvement en épicycloïde) ?

Autrement dit, il n'y a aucune raison que la Lune s'écrase sur le Soleil, puisqu'elle dispose d'une vitesse qui, comme pour les planètes, compense l'attraction gravitationnelle du Soleil et lui permet d'avoir une orbite stable ?

Merci encore, et bonne soirée

[pm42]

Du coup l'idée (certes non présentée scientifiquement) serait que la Lune, comme les planètes du Système Solaire, tourne autour du Soleil selon une ellipse, mais que la présence de la Terre perturbe son orbite (d'où un mouvement en épicycloïde) ?
Autrement dit, il n'y a aucune raison que la Lune s'écrase sur le Soleil, puisqu'elle dispose d'une vitesse qui, comme pour les planètes, compense l'attraction gravitationnelle du Soleil et lui permet d'avoir une orbite stable ?

Oui. Regarde ici à "heliocentric perception", cela va devenir très clair : https://malagabay.wordpress.com/2012...omment-page-1/

[henryallen]

En effet, merci beaucoup !

[henryallen]

Me revoici ...

Je suis tombé sur un site Internet sur les points de Lagrange. Si j'ai bien compris, si l'on considère deux corps massifs dont l'un orbite autour de l'autre, il existe 5 points tels que si un corps de masse négligeable s'y trouve, alors relativement aux deux autres corps, il sera immobile (3 des points étant instables, les deux autres stables).

Mais le corps de masse négligeable placé à un point de Lagrange doit-il avoir une vitesse initiale ? Je veux dire dans le cas du système Soleil-Terre, le corps doit-il être initialement en mouvement par rapport au Soleil, ou immobile ?

Merci d'avance,
Bonne soirée

[phys4]

Il doit évidemment avoir la vitesse initiale qui correspond au point de Lagrange considéré, facile à calculer, puisque les points sont synchrones du mouvement de rotation de la Terre autour du Soleil.

[yves95210]

Mais le corps de masse négligeable placé à un point de Lagrange doit-il avoir une vitesse initiale ? Je veux dire dans le cas du système Soleil-Terre, le corps doit-il être initialement en mouvement par rapport au Soleil, ou immobile ?

Réfléchis un peu : les points de Lagrange tournent autour du Soleil avec la même vitesse angulaire que la Terre, puisque leur position est fixe dans un repère centré sur le Soleil et en rotation avec la Terre.

PS : grillé par phys4...

[henryallen]

Merci pour vos réponses, je n'avais en effet pas entièrement compris ce qu'était un point de Lagrange, je pense que c'est maintenant chose faite !

Bonne soirée.