Simulateur perso : bug introuvable (résolu)

Thierz a écrit:Je n'utilise pas Matlab, c'est Space Opera qui en parle dans ses messages ci-dessus. Pour ma part, j'utilise Java, j'ai codé l'intégrateur.

Si tu utilises Java et que tu ne veux pas réinventer la roue, tu peux utiliser la librairie Apache Commons-Math qui te permettra de gérer facilement les vecteurs 3D et elle propose toute une série d'intégrateurs en partant de la méthode d'Euler jusqu'à du Dormand-Prince d'ordre 8, voire plus.

krys a écrit:Donc je te conseille au minimum de changer et de passer au moins en cartésien. Car tu vas vite te prendre la tête à calculer tes perturbations en r "point" et teta "point" alors que c'est en général simple en cartésien (exemple typique: le drag...).

Ah pourtant le drag ça me semblait simple en polaire : direction opposée à la vélocité, intensité calculée selon l'atmosphère et l'angle de pénétration.

krys a écrit:Si tu utilises Java et que tu ne veux pas réinventer la roue (...)

Au contraire je veux tout réinventer, pour comprendre (Marty, 2,21 GW !!! :eeks:)

krys a écrit:Sans Matlab, il faudrait que tu fasses l'intégrateur (ici j'utilise par facilité "ode45" de Matlab) mais en codant un simple RK4 (Runge Kutta d'ordre 4 - cf Wikipedia) et en prenant un pas d'une minute, ça doit être assez précis.

Thierz a écrit:Pour ma part, j'utilise Java, j'ai codé l'intégrateur.

Erratum ! Je me suis renseigné sur ce que tu appelles un "intégrateur", je n'ai pas du tout codé ça. Moi ce que j'appelais l'intégrateur, c'est la fonction qui m'intègre l'accélération pour en faire une vitesse et la vitesse pour en faire un mouvement.

Dis-moi si je me trompe, mais avec un tel intégrateur, tu prédis instantanément la trajectoire sur une période à venir ? Je n'ai rien fait de tel, moi j'ai un calcul instantané de l'orbite théorique compte tenu de ma position et ma vitesse actuelles.

Pour un problème à 3 corps (ta boule, la Terre et le soleil), il n'y a pas de solution analytique, pas de formule qui te permet de trouver le résultat.
Donc la façon la plus simple est de résoudre l'équation différentielle numériquement, avec ce qu'on appelle des "intégrateurs", c'est à dire des outils qui somment de façon intelligente des accélérations instantanées pour calculer des variations de vitesse puis de position. Il est impossible de remonter à la position directement à partir de la formulation de la gravité des 3 corps.
Il y a des intégrateurs simples, comme des simples additions d'accélérations locales, mais l'erreur numérique s'accumule très vite et ta boule va se retrouver sur Jupiter en quelques centaines d'orbites (sauf si tu mets des pas de temps exagérément faibles). D'autres techniques classiques, comme un RK4, permettent de sommer de façon plus maligne ces accélérations instantanées pour remonter aux positions/vitesses.

Space Opera a écrit:
Il y a des intégrateurs simples, comme des simples additions d'accélérations locales, mais l'erreur numérique s'accumule très vite et ta boule va se retrouver sur Jupiter en quelques centaines d'orbites (sauf si tu mets des pas de temps exagérément faibles). D'autres techniques classiques, comme un RK4, permettent de sommer de façon plus maligne ces accélérations instantanées pour remonter aux positions/vitesses.

Et pourtant, elles tournent ....
Dame nature ne connait pas l'intégrateur RK4 et s'il n'existe pas de formule algébrique pour résoudre l'équation différentielle des n corps, c'est sans doute que dame nature fait autrement pour déterminer à t+1 la position des particules dotées d'une masse. Donc pourquoi pas de simples additions d'accélération (plutôt des additions de forces d'ailleurs) et un pas de temps très très faible ? Logiquement, ça doit marcher, et la question importante est de savoir, effectivement, quelle est la précision requise pour le pas de temps.
Mais allons plus loin : sachant que chaque particule massique de l'univers a théoriquement sa contribution à apporter à la somme des forces agissant sur une particule massique, la complexité du problème devient quasi-infinie. Devant cet abîme de complexité, il est sage de douter de la formalisation du problème. Qu'on se rassure, certains, comme Einstein, ont eu l'idée de considérer qu'en fait de forces agissant à distance (quand on y pense, il faut un certain degré de folie pour admettre qu'il y a un effet instantané d'un objet sur un autre alors que les 2 sont séparés par des distances faramineuses ...), il s'agissait plutôt d'une déformation de l'espace. Dans la relativité générale, puisque telle est son nom, le formalisme adopté par Einstein est celui d'un espace continu. Cet espace pourrait aussi être discret, ou quantique si on préfère, mais peu importe. La question que je me pose est la suivante : est-ce qu'il y a des gens qui ont programmé le déplacement des satellites en utilisant le formalisme de la déformation de l'espace ?
Ne répondez pas tous à la fois ... ;-)

Heu, perso il faut que j'aille acheter mon pain car si je tarde il n'y en aura plus. Mais je vais y penser plus tard.   :sage:

Argyre a écrit:Et pourtant, elles tournent ....
Dame nature ne connait pas l'intégrateur RK4 et s'il n'existe pas de formule algébrique pour résoudre l'équation différentielle des n corps, c'est sans doute que dame nature fait autrement pour déterminer à t+1 la position des particules dotées d'une masse. Donc pourquoi pas de simples additions d'accélération (plutôt des additions de forces d'ailleurs) et un pas de temps très très faible ? Logiquement, ça doit marcher, et la question importante est de savoir, effectivement, quelle est la précision requise pour le pas de temps.

C'est comme ça que fonctionne mon simulateur. Je devrai choisir le dt en fonction du matériel qui exécute le programme puisqu'il est voué à être utilisé en temps réel, donc il y aura un compromis à trouver entre le temps CPU alloué au calcul, le temps CPU alloué au rendu graphique, et la longévité de la batterie.

Ce que tu fais s'appelle juste "la méthode d'Euler explicite": ça revient à linéariser ta fonction par morceau sur chaque intervalle dt. C'est la plus simple des méthodes pour résoudre numériquement des équa diff ordinaires mais c'est loin d'être la plus efficace!
Franchement, regarde RK4. C'est trivial à coder et c'est assez précis et tu n'es pas obligé de faire des pas microscopiques pour arriver à la même précision... Tu obtiendras la même précision avec 1% de CPU plutôt que 100%...

Exactement, comme j'avais dit aussi juste avant, la méthode que propose Argyre est la plus intuitive et celle que tous les étudiants veulent coder en premier. Mais un simple RK4 (il en existe des plus sioux encore) te permet de faire beaucoup mieux avec un temps de calcul plus court.

Thierz a écrit:Oui merci Space Opera, je crois que tu m'as mis sur la bonne voie. Je n'ai pas eu le temps de retravailler sur le simulateur, mais tes explications ont fait travailler mon cerveau en tâche de fond toute la journée, et je crois que je sais où se trouve mon bug. Je pense qu'il est dû au fait que je modifie la position de la boule relativement à la Terre, et non en absolu (l'absolu étant le soleil dans ma simulation). En clair, si mon idée est juste, je fais subir deux fois l'attraction du soleil à la boule :
1) une première fois quand j'applique la somme des forces exercées par la Terre + le soleil à la position de la boule par rapport à la Terre
2) une seconde fois quand j'applique la force exercée par le soleil à la position de la Terre par rapport au soleil (la boule étant positionnée par rapport à la Terre)

Un peu comme si, au lieu de faire marcher un homme dans un train, je fais marcher un homme dans un train qui est lui-même dans un train. Vu du train qui est le plus à l'extérieur, l'homme va trop vite, c'est ce qui se passe pour ma boule dont l'apogée augmente énormément et le périgée diminue tout autant.

Je testerai cette hypothèse demain et vous tiendrai informés du résultat

Bonjour à tous, après quelques modifications au simulateur et beaucoup de tests, je suis heureux de vous dire que le bug est corrigé ! C'est bien la piste de la citation ci-dessus qui était la bonne.

Merci à tous pour votre aide, notamment à Space Opera pour l'image de la plume et du marteau dans l'ascenseur, sans laquelle je n'aurais pas compris cette subtilité de la mécanique céleste. Merci aussi à krys pour les suggestions de modification, j'y viendrai au fur et à mesure que je perfectionne le simulateur, et à Astro-notes pour les encouragements et les anecdotes historiques.

Un vrai travail d'équipe !