Normalement on utilise le barycentre des masses comme origine du repère. On peut facilement prouver que le barycentre a une vitesse nulle (au moins pour 2 corps, pour >2 je me rappelle plus faudrait faire le calcul). Il faut absolument que tu corriges cela, car là tu bouffes de la précision numérique avec un système pas centré.
Fait moins de snapshot (1 sur 10 pas, comme ton calcul de conservation, c’est encore trop fréquent àmha) sinon ça va te bouffer trop de temps. Probablement que tes pas sont trop grand si tu fais un snapshot par pas.
Pour t’aider à trouver la bonne taille de pas, tu peux faire un jeu de simu en réduisant le pas, et voir à quel moment le résultat se stabilise (ie. réduire le pas ne change pas fondamentalement le résultat de la simu).
La loi_aire n’est pas donnée, mais fondamentalement il s’agit de la conservation du moment cinétique (c’est un vecteur). Tu gagnerais à le formaliser comme ça car la conservation du moment cinétique permet de s’assurer que ton orbite est bien dans un plan (par conservation de la direction du moment) et que tu obéis à la loi des aires (par conservation de l’amplitude du moment). De plus as-tu bien vérifié que les deux grandeurs (énergie et moment) sont bien conservées ?
Normalement on normalise un code physique : G vaut 1, toutes les grandeurs (variables, masses, etc.) sont autour de 1. Par exemple la masse du corps principal est fixée à 1 et celle des corps qui orbitent à une fraction de la masse du corps principal. Le corps qui orbite est à une distance 1. C’est l’idée grosso modo. La conversion en unités physique se fait à part... éventuellement.
Pour quelque chose de plus pro. les conditions initiales (CI) devraient être dans un fichier — identique au format de tes snapshots, car des CI sont un snapshot de ta simu (tu pourras ainsi arrêter et reprendre ta simu sur le dernier snapshot si tu veux). Il te faudra éventuellemnt un petit utilitaire pour construire un snapshot ad-hoc pour démarrer une simu (mais pour commencer je te recommande de faire des snapshots ascii tabulé directement exploitable à la main).
Fais des CI simple, dans le plan XY, avec une orbite circulaire, etc. Dans le cas à deux corps, l’orbite se calcule de manière analytique (tu retrouveras facilement sur le web les calculs je pense). Ça te permettra de valider ton programme par comparaison au résultat analytique, avec un jeu de fichiers standards (d’où l’importance du point 6). Avec des CI simples, ça facilitera la visualisation graphique des snapshot aussi : suffira de tracer les points (X,Y), vérifier que Z reste nul, etc.
Il y aura une dérive numérique, même dans le cas à deux corps, surtout avec une méthode "naïve" (si je me souviens bien il y en a qui sont conçues pour conserver les deux grandeurs énergie & moment, et donc plus robustes, mais ça devient beaucoup plus difficile à implémenter). Faut pas s’affoler si l’orbite n’est pas très stable, même après à peine 10 révolutions tu pourrais voir une décalage de l’orbite, signe qu’il faudra réduire la taille du pas (au prix d’une simu plus longue).
Optimisation. La force du corps A sur le corps B est l’opposée de la force du corps B sur le corps A. (À toi de retrouver comme exploiter cela dans ton code.)
Optimisation. La trajectoire d’un corps ne dépend pas de sa masse. (À toi de trouver comment exploiter cela dans ton code.)
# Quelques remarques
Posté par ml . En réponse au message Positions/vitesses initiales de satellites pour observer leurs trajectoires. Évalué à 8. Dernière modification le 12 avril 2023 à 23:45.
En vrac :
Normalement on utilise le barycentre des masses comme origine du repère. On peut facilement prouver que le barycentre a une vitesse nulle (au moins pour 2 corps, pour >2 je me rappelle plus faudrait faire le calcul). Il faut absolument que tu corriges cela, car là tu bouffes de la précision numérique avec un système pas centré.
Fait moins de snapshot (1 sur 10 pas, comme ton calcul de conservation, c’est encore trop fréquent àmha) sinon ça va te bouffer trop de temps. Probablement que tes pas sont trop grand si tu fais un snapshot par pas.
Pour t’aider à trouver la bonne taille de pas, tu peux faire un jeu de simu en réduisant le pas, et voir à quel moment le résultat se stabilise (ie. réduire le pas ne change pas fondamentalement le résultat de la simu).
La loi_aire n’est pas donnée, mais fondamentalement il s’agit de la conservation du moment cinétique (c’est un vecteur). Tu gagnerais à le formaliser comme ça car la conservation du moment cinétique permet de s’assurer que ton orbite est bien dans un plan (par conservation de la direction du moment) et que tu obéis à la loi des aires (par conservation de l’amplitude du moment). De plus as-tu bien vérifié que les deux grandeurs (énergie et moment) sont bien conservées ?
Normalement on normalise un code physique : G vaut 1, toutes les grandeurs (variables, masses, etc.) sont autour de 1. Par exemple la masse du corps principal est fixée à 1 et celle des corps qui orbitent à une fraction de la masse du corps principal. Le corps qui orbite est à une distance 1. C’est l’idée grosso modo. La conversion en unités physique se fait à part... éventuellement.
Pour quelque chose de plus pro. les conditions initiales (CI) devraient être dans un fichier — identique au format de tes snapshots, car des CI sont un snapshot de ta simu (tu pourras ainsi arrêter et reprendre ta simu sur le dernier snapshot si tu veux). Il te faudra éventuellemnt un petit utilitaire pour construire un snapshot ad-hoc pour démarrer une simu (mais pour commencer je te recommande de faire des snapshots ascii tabulé directement exploitable à la main).
Fais des CI simple, dans le plan XY, avec une orbite circulaire, etc. Dans le cas à deux corps, l’orbite se calcule de manière analytique (tu retrouveras facilement sur le web les calculs je pense). Ça te permettra de valider ton programme par comparaison au résultat analytique, avec un jeu de fichiers standards (d’où l’importance du point 6). Avec des CI simples, ça facilitera la visualisation graphique des snapshot aussi : suffira de tracer les points (X,Y), vérifier que Z reste nul, etc.
Il y aura une dérive numérique, même dans le cas à deux corps, surtout avec une méthode "naïve" (si je me souviens bien il y en a qui sont conçues pour conserver les deux grandeurs énergie & moment, et donc plus robustes, mais ça devient beaucoup plus difficile à implémenter). Faut pas s’affoler si l’orbite n’est pas très stable, même après à peine 10 révolutions tu pourrais voir une décalage de l’orbite, signe qu’il faudra réduire la taille du pas (au prix d’une simu plus longue).
Optimisation. La force du corps A sur le corps B est l’opposée de la force du corps B sur le corps A. (À toi de retrouver comme exploiter cela dans ton code.)
Optimisation. La trajectoire d’un corps ne dépend pas de sa masse. (À toi de trouver comment exploiter cela dans ton code.)