How do computers “solve” the three-body-problem?












1












$begingroup$


I've done a bit of research, and have learned that computers "solve" the three-body-problem by using "Numerical methods for ordinary differential equations", but I can't really find anything about it other then Wikipedia. Does anyone have any good sources about this topic that isn't any kind of Wikipedia?



My thoughts:

Currently I'm using simulations of three bodies flying around each other, using Newton's gravitational law, and at a random time in the simulation, everything goes chaotic. I though that this was the only way to kind of "solve" it, but how does this "Numerical methods for ordinary differential equations" method work? And what does the computer actually do?










share|cite|improve this question









New contributor




HeeysamH is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.







$endgroup$








  • 2




    $begingroup$
    Related post by OP: physics.stackexchange.com/q/456720/2451
    $endgroup$
    – Qmechanic
    4 hours ago










  • $begingroup$
    Do you want to learn how to write your own gravity sim software? Do you know much calculus?
    $endgroup$
    – PM 2Ring
    3 hours ago






  • 1




    $begingroup$
    it is unclear how your simulator "solved it". Did you make it?
    $endgroup$
    – Wolphram jonny
    3 hours ago










  • $begingroup$
    Forget the ode's and model it, as I think you're already suggesting: At each timestep, update each object's position using its current velocity, i.e., $vec x_i = vec x_i + vec v_itimes dt$. Then update each object's velocity by calculating the total force on that object due to all the other objects (in your case, gravitational force). That is, $vec v_i = vec v_i + frac{vec F_i}{m_i}times dt$, where $vec F_i$ is the sum of all the forces on $m_i$. If you're doing that correctly and it's not working, try dividing your $dt$ timestep by $2$. Recurse as necessary.
    $endgroup$
    – John Forkosh
    2 hours ago








  • 5




    $begingroup$
    @John It looks like you're recommending naive Euler integration. That's notoriously prone to accumulating errors, even in 2 body orbits of low eccentricity. Trying to simulate potentially chaotic n body gravitational systems with it will be very unrealistic, although if your aim is to see some kind of chaotic behaviour, it will do that. ;) Gravity sims should use a symplectic integrator like Leapfrog or Verlet. They only require a minor change to the code, but don't blow up from lack of energy conservation due to accumulated floating-point errors.
    $endgroup$
    – PM 2Ring
    2 hours ago


















1












$begingroup$


I've done a bit of research, and have learned that computers "solve" the three-body-problem by using "Numerical methods for ordinary differential equations", but I can't really find anything about it other then Wikipedia. Does anyone have any good sources about this topic that isn't any kind of Wikipedia?



My thoughts:

Currently I'm using simulations of three bodies flying around each other, using Newton's gravitational law, and at a random time in the simulation, everything goes chaotic. I though that this was the only way to kind of "solve" it, but how does this "Numerical methods for ordinary differential equations" method work? And what does the computer actually do?










share|cite|improve this question









New contributor




HeeysamH is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.







$endgroup$








  • 2




    $begingroup$
    Related post by OP: physics.stackexchange.com/q/456720/2451
    $endgroup$
    – Qmechanic
    4 hours ago










  • $begingroup$
    Do you want to learn how to write your own gravity sim software? Do you know much calculus?
    $endgroup$
    – PM 2Ring
    3 hours ago






  • 1




    $begingroup$
    it is unclear how your simulator "solved it". Did you make it?
    $endgroup$
    – Wolphram jonny
    3 hours ago










  • $begingroup$
    Forget the ode's and model it, as I think you're already suggesting: At each timestep, update each object's position using its current velocity, i.e., $vec x_i = vec x_i + vec v_itimes dt$. Then update each object's velocity by calculating the total force on that object due to all the other objects (in your case, gravitational force). That is, $vec v_i = vec v_i + frac{vec F_i}{m_i}times dt$, where $vec F_i$ is the sum of all the forces on $m_i$. If you're doing that correctly and it's not working, try dividing your $dt$ timestep by $2$. Recurse as necessary.
    $endgroup$
    – John Forkosh
    2 hours ago








  • 5




    $begingroup$
    @John It looks like you're recommending naive Euler integration. That's notoriously prone to accumulating errors, even in 2 body orbits of low eccentricity. Trying to simulate potentially chaotic n body gravitational systems with it will be very unrealistic, although if your aim is to see some kind of chaotic behaviour, it will do that. ;) Gravity sims should use a symplectic integrator like Leapfrog or Verlet. They only require a minor change to the code, but don't blow up from lack of energy conservation due to accumulated floating-point errors.
    $endgroup$
    – PM 2Ring
    2 hours ago
















1












1








1





$begingroup$


I've done a bit of research, and have learned that computers "solve" the three-body-problem by using "Numerical methods for ordinary differential equations", but I can't really find anything about it other then Wikipedia. Does anyone have any good sources about this topic that isn't any kind of Wikipedia?



My thoughts:

Currently I'm using simulations of three bodies flying around each other, using Newton's gravitational law, and at a random time in the simulation, everything goes chaotic. I though that this was the only way to kind of "solve" it, but how does this "Numerical methods for ordinary differential equations" method work? And what does the computer actually do?










share|cite|improve this question









New contributor




HeeysamH is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.







$endgroup$




I've done a bit of research, and have learned that computers "solve" the three-body-problem by using "Numerical methods for ordinary differential equations", but I can't really find anything about it other then Wikipedia. Does anyone have any good sources about this topic that isn't any kind of Wikipedia?



My thoughts:

Currently I'm using simulations of three bodies flying around each other, using Newton's gravitational law, and at a random time in the simulation, everything goes chaotic. I though that this was the only way to kind of "solve" it, but how does this "Numerical methods for ordinary differential equations" method work? And what does the computer actually do?







computational-physics chaos-theory three-body-problem






share|cite|improve this question









New contributor




HeeysamH is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|cite|improve this question









New contributor




HeeysamH is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|cite|improve this question




share|cite|improve this question








edited 41 mins ago









Kyle Kanos

21.6k114894




21.6k114894






New contributor




HeeysamH is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked 4 hours ago









HeeysamHHeeysamH

262




262




New contributor




HeeysamH is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





HeeysamH is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






HeeysamH is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.








  • 2




    $begingroup$
    Related post by OP: physics.stackexchange.com/q/456720/2451
    $endgroup$
    – Qmechanic
    4 hours ago










  • $begingroup$
    Do you want to learn how to write your own gravity sim software? Do you know much calculus?
    $endgroup$
    – PM 2Ring
    3 hours ago






  • 1




    $begingroup$
    it is unclear how your simulator "solved it". Did you make it?
    $endgroup$
    – Wolphram jonny
    3 hours ago










  • $begingroup$
    Forget the ode's and model it, as I think you're already suggesting: At each timestep, update each object's position using its current velocity, i.e., $vec x_i = vec x_i + vec v_itimes dt$. Then update each object's velocity by calculating the total force on that object due to all the other objects (in your case, gravitational force). That is, $vec v_i = vec v_i + frac{vec F_i}{m_i}times dt$, where $vec F_i$ is the sum of all the forces on $m_i$. If you're doing that correctly and it's not working, try dividing your $dt$ timestep by $2$. Recurse as necessary.
    $endgroup$
    – John Forkosh
    2 hours ago








  • 5




    $begingroup$
    @John It looks like you're recommending naive Euler integration. That's notoriously prone to accumulating errors, even in 2 body orbits of low eccentricity. Trying to simulate potentially chaotic n body gravitational systems with it will be very unrealistic, although if your aim is to see some kind of chaotic behaviour, it will do that. ;) Gravity sims should use a symplectic integrator like Leapfrog or Verlet. They only require a minor change to the code, but don't blow up from lack of energy conservation due to accumulated floating-point errors.
    $endgroup$
    – PM 2Ring
    2 hours ago
















  • 2




    $begingroup$
    Related post by OP: physics.stackexchange.com/q/456720/2451
    $endgroup$
    – Qmechanic
    4 hours ago










  • $begingroup$
    Do you want to learn how to write your own gravity sim software? Do you know much calculus?
    $endgroup$
    – PM 2Ring
    3 hours ago






  • 1




    $begingroup$
    it is unclear how your simulator "solved it". Did you make it?
    $endgroup$
    – Wolphram jonny
    3 hours ago










  • $begingroup$
    Forget the ode's and model it, as I think you're already suggesting: At each timestep, update each object's position using its current velocity, i.e., $vec x_i = vec x_i + vec v_itimes dt$. Then update each object's velocity by calculating the total force on that object due to all the other objects (in your case, gravitational force). That is, $vec v_i = vec v_i + frac{vec F_i}{m_i}times dt$, where $vec F_i$ is the sum of all the forces on $m_i$. If you're doing that correctly and it's not working, try dividing your $dt$ timestep by $2$. Recurse as necessary.
    $endgroup$
    – John Forkosh
    2 hours ago








  • 5




    $begingroup$
    @John It looks like you're recommending naive Euler integration. That's notoriously prone to accumulating errors, even in 2 body orbits of low eccentricity. Trying to simulate potentially chaotic n body gravitational systems with it will be very unrealistic, although if your aim is to see some kind of chaotic behaviour, it will do that. ;) Gravity sims should use a symplectic integrator like Leapfrog or Verlet. They only require a minor change to the code, but don't blow up from lack of energy conservation due to accumulated floating-point errors.
    $endgroup$
    – PM 2Ring
    2 hours ago










2




2




$begingroup$
Related post by OP: physics.stackexchange.com/q/456720/2451
$endgroup$
– Qmechanic
4 hours ago




$begingroup$
Related post by OP: physics.stackexchange.com/q/456720/2451
$endgroup$
– Qmechanic
4 hours ago












$begingroup$
Do you want to learn how to write your own gravity sim software? Do you know much calculus?
$endgroup$
– PM 2Ring
3 hours ago




$begingroup$
Do you want to learn how to write your own gravity sim software? Do you know much calculus?
$endgroup$
– PM 2Ring
3 hours ago




1




1




$begingroup$
it is unclear how your simulator "solved it". Did you make it?
$endgroup$
– Wolphram jonny
3 hours ago




$begingroup$
it is unclear how your simulator "solved it". Did you make it?
$endgroup$
– Wolphram jonny
3 hours ago












$begingroup$
Forget the ode's and model it, as I think you're already suggesting: At each timestep, update each object's position using its current velocity, i.e., $vec x_i = vec x_i + vec v_itimes dt$. Then update each object's velocity by calculating the total force on that object due to all the other objects (in your case, gravitational force). That is, $vec v_i = vec v_i + frac{vec F_i}{m_i}times dt$, where $vec F_i$ is the sum of all the forces on $m_i$. If you're doing that correctly and it's not working, try dividing your $dt$ timestep by $2$. Recurse as necessary.
$endgroup$
– John Forkosh
2 hours ago






$begingroup$
Forget the ode's and model it, as I think you're already suggesting: At each timestep, update each object's position using its current velocity, i.e., $vec x_i = vec x_i + vec v_itimes dt$. Then update each object's velocity by calculating the total force on that object due to all the other objects (in your case, gravitational force). That is, $vec v_i = vec v_i + frac{vec F_i}{m_i}times dt$, where $vec F_i$ is the sum of all the forces on $m_i$. If you're doing that correctly and it's not working, try dividing your $dt$ timestep by $2$. Recurse as necessary.
$endgroup$
– John Forkosh
2 hours ago






5




5




$begingroup$
@John It looks like you're recommending naive Euler integration. That's notoriously prone to accumulating errors, even in 2 body orbits of low eccentricity. Trying to simulate potentially chaotic n body gravitational systems with it will be very unrealistic, although if your aim is to see some kind of chaotic behaviour, it will do that. ;) Gravity sims should use a symplectic integrator like Leapfrog or Verlet. They only require a minor change to the code, but don't blow up from lack of energy conservation due to accumulated floating-point errors.
$endgroup$
– PM 2Ring
2 hours ago






$begingroup$
@John It looks like you're recommending naive Euler integration. That's notoriously prone to accumulating errors, even in 2 body orbits of low eccentricity. Trying to simulate potentially chaotic n body gravitational systems with it will be very unrealistic, although if your aim is to see some kind of chaotic behaviour, it will do that. ;) Gravity sims should use a symplectic integrator like Leapfrog or Verlet. They only require a minor change to the code, but don't blow up from lack of energy conservation due to accumulated floating-point errors.
$endgroup$
– PM 2Ring
2 hours ago












2 Answers
2






active

oldest

votes


















2












$begingroup$

Numerical analysis is used to calculate approximations to things: the value of a function at a certain point, where a root of an equation is, or the solutions to a set of differential equations. It is a huge and important topic since in practice most real problems in mathematics, science and technology will not have an explicit closed-form solution. In general there are trade-offs between accuracy and computational speed.



For the three-body problem we have three point masses in starting locations $mathbf{x}_i(0)$ with velocities $mathbf{v}_i(0)$ that we want to calculate for later times $t$. Mathematically we want to find the solution to the system $$mathbf{x}'_i(t)=mathbf{v}_i(t),$$ $$mathbf{v}'_i(t)=mathbf{f}_i(t)/m_i,$$ $$mathbf{f}_i(t)=sum_{jneq i} Gm_i m_j/||mathbf{x}_i-mathbf{x}_j||.$$



The obvious method is to think "if we move forward a tiny step $h$ in time, we can approximate everything to be linear", so we make a formula where we calculate the state at time $t+h$ from the state at time $t$ (and so on for $t+2h$ and onwards): $$mathbf{x}_i(t+h)=mathbf{x}_i(t)+hmathbf{v}_i(t),$$ $$mathbf{v}_i(t+h)=mathbf{v}_i(t)+hmathbf{f}_i(t).$$ This is called Euler's method. It is simple but tends to be inaccurate; the error per step is $approx O(h^2)$ and they tend to build up. If you try it for a two body problem it will make the orbiting masses perform a precessing rosette orbit because of the error build-up, especially when they get close to each other.



There is a menagerie of methods for solving ODEs numerically. One can use higher order methods that sample the functions in more points and hence approximate them better. There are implicit methods that instead of trying to find a state at a later time only based on the current state look for a self-consistent late and intermediate state. As I said, this is a big topic.



However, for mechanical simulations you may want to look at methods designed to preserve energy and other conserved quantities (symplectic methods - these are the ones used by professionals for long-run orbit calculations). Perhaps the simplest is the semi-implicit Euler method. There is also the Verlet method and leapfrog integration. I like the semi-implicit Euler method because it is super-simple (but being a first order-method it is still not terribly accurate): $$mathbf{v}_i(t+h)=mathbf{v}_i(t)+hmathbf{f}_i(t),$$ $$mathbf{x}_i(t+h)=mathbf{x}_i(t)+hmathbf{v}_i(t+h).$$ Do you see the difference? You calculate the updated velocity first, and then use it to update the positions - a tiny trick, but suddenly 2-body orbits are well behaved.



The three body problem is chaotic in a true mathematical sense. We know there are situations where tiny differences in initial conditions get scaled up to arbitrarily large differences in later positions (even if we rule out super-close passes between masses). So even with an arbitrarily fine numerical precision there will be a point in time where our calculated orbits will be totally wrong. The overall "style" of trajectory may still be correct.






share|cite|improve this answer









$endgroup$





















    0












    $begingroup$

    The "solution" of the three-body problem can be written as the pair of differential equations,
    begin{align}
    vec{v}&=frac{mathrm dvec{x}}{mathrm dt}\
    vec{a}&=frac{mathrm dvec{v}}{mathrm dt}
    end{align}

    where the latter is usually written in terms of the force, $mvec{a}=vec{F}$. Then using the definition of the derivative,
    $$
    frac{mathrm df}{mathrm dx}=lim_{hto0}frac{f(x+h)-f(x)}{h},
    $$

    the differential equations we started with can be written as the finite difference equations,
    begin{align}
    vec x(t+mathrm dt)&simeq vec x(t)+vec v,mathrm dt \
    vec v(t+mathrm dt)&simeq vec v(t)+vec a,mathrm dt
    end{align}

    which is done assuming that $mathrm dt$ is "just small" rather than infinitesimal.



    It is these equations that a computer uses to "solve" the three body problem: given an initial condition for each of the bodies, the computer iteratively steps forward in time using the above finite difference equations with the force being the $n$-body force.



    As mentioned in the comments, the simplistic model above is called Euler integration which is not at all well-suited for this problem because it does not conserve energy. A better option is called velocity Verlet, which is disucssed in other posts on physics.SE (I would recommend this post of mine as it gives some decent, but brief, details of the implementation).






    share|cite|improve this answer









    $endgroup$













    • $begingroup$
      Velocity verlet is "good" only in comparison to Euler. For solving the solar system, it's rather worthless. Accuracy degrades rapidly. People use verlet because (a) it shows some short-term dynamics, (b) it kinda-sorta conserves quantities that should be conserved, and (c) the higher order techniques used to "solve" the solar system don't extend well to several thousand objects, let alone millions and millions of objects.
      $endgroup$
      – David Hammen
      35 mins ago










    • $begingroup$
      @DavidHammen all very good points. Note that I only said Verlet is a better option vs Euler, not that it's the best or any similar such comparison.
      $endgroup$
      – Kyle Kanos
      31 mins ago











    Your Answer





    StackExchange.ifUsing("editor", function () {
    return StackExchange.using("mathjaxEditing", function () {
    StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
    StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["$", "$"], ["\\(","\\)"]]);
    });
    });
    }, "mathjax-editing");

    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "151"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    noCode: true, onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });






    HeeysamH is a new contributor. Be nice, and check out our Code of Conduct.










    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fphysics.stackexchange.com%2fquestions%2f456808%2fhow-do-computers-solve-the-three-body-problem%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    2












    $begingroup$

    Numerical analysis is used to calculate approximations to things: the value of a function at a certain point, where a root of an equation is, or the solutions to a set of differential equations. It is a huge and important topic since in practice most real problems in mathematics, science and technology will not have an explicit closed-form solution. In general there are trade-offs between accuracy and computational speed.



    For the three-body problem we have three point masses in starting locations $mathbf{x}_i(0)$ with velocities $mathbf{v}_i(0)$ that we want to calculate for later times $t$. Mathematically we want to find the solution to the system $$mathbf{x}'_i(t)=mathbf{v}_i(t),$$ $$mathbf{v}'_i(t)=mathbf{f}_i(t)/m_i,$$ $$mathbf{f}_i(t)=sum_{jneq i} Gm_i m_j/||mathbf{x}_i-mathbf{x}_j||.$$



    The obvious method is to think "if we move forward a tiny step $h$ in time, we can approximate everything to be linear", so we make a formula where we calculate the state at time $t+h$ from the state at time $t$ (and so on for $t+2h$ and onwards): $$mathbf{x}_i(t+h)=mathbf{x}_i(t)+hmathbf{v}_i(t),$$ $$mathbf{v}_i(t+h)=mathbf{v}_i(t)+hmathbf{f}_i(t).$$ This is called Euler's method. It is simple but tends to be inaccurate; the error per step is $approx O(h^2)$ and they tend to build up. If you try it for a two body problem it will make the orbiting masses perform a precessing rosette orbit because of the error build-up, especially when they get close to each other.



    There is a menagerie of methods for solving ODEs numerically. One can use higher order methods that sample the functions in more points and hence approximate them better. There are implicit methods that instead of trying to find a state at a later time only based on the current state look for a self-consistent late and intermediate state. As I said, this is a big topic.



    However, for mechanical simulations you may want to look at methods designed to preserve energy and other conserved quantities (symplectic methods - these are the ones used by professionals for long-run orbit calculations). Perhaps the simplest is the semi-implicit Euler method. There is also the Verlet method and leapfrog integration. I like the semi-implicit Euler method because it is super-simple (but being a first order-method it is still not terribly accurate): $$mathbf{v}_i(t+h)=mathbf{v}_i(t)+hmathbf{f}_i(t),$$ $$mathbf{x}_i(t+h)=mathbf{x}_i(t)+hmathbf{v}_i(t+h).$$ Do you see the difference? You calculate the updated velocity first, and then use it to update the positions - a tiny trick, but suddenly 2-body orbits are well behaved.



    The three body problem is chaotic in a true mathematical sense. We know there are situations where tiny differences in initial conditions get scaled up to arbitrarily large differences in later positions (even if we rule out super-close passes between masses). So even with an arbitrarily fine numerical precision there will be a point in time where our calculated orbits will be totally wrong. The overall "style" of trajectory may still be correct.






    share|cite|improve this answer









    $endgroup$


















      2












      $begingroup$

      Numerical analysis is used to calculate approximations to things: the value of a function at a certain point, where a root of an equation is, or the solutions to a set of differential equations. It is a huge and important topic since in practice most real problems in mathematics, science and technology will not have an explicit closed-form solution. In general there are trade-offs between accuracy and computational speed.



      For the three-body problem we have three point masses in starting locations $mathbf{x}_i(0)$ with velocities $mathbf{v}_i(0)$ that we want to calculate for later times $t$. Mathematically we want to find the solution to the system $$mathbf{x}'_i(t)=mathbf{v}_i(t),$$ $$mathbf{v}'_i(t)=mathbf{f}_i(t)/m_i,$$ $$mathbf{f}_i(t)=sum_{jneq i} Gm_i m_j/||mathbf{x}_i-mathbf{x}_j||.$$



      The obvious method is to think "if we move forward a tiny step $h$ in time, we can approximate everything to be linear", so we make a formula where we calculate the state at time $t+h$ from the state at time $t$ (and so on for $t+2h$ and onwards): $$mathbf{x}_i(t+h)=mathbf{x}_i(t)+hmathbf{v}_i(t),$$ $$mathbf{v}_i(t+h)=mathbf{v}_i(t)+hmathbf{f}_i(t).$$ This is called Euler's method. It is simple but tends to be inaccurate; the error per step is $approx O(h^2)$ and they tend to build up. If you try it for a two body problem it will make the orbiting masses perform a precessing rosette orbit because of the error build-up, especially when they get close to each other.



      There is a menagerie of methods for solving ODEs numerically. One can use higher order methods that sample the functions in more points and hence approximate them better. There are implicit methods that instead of trying to find a state at a later time only based on the current state look for a self-consistent late and intermediate state. As I said, this is a big topic.



      However, for mechanical simulations you may want to look at methods designed to preserve energy and other conserved quantities (symplectic methods - these are the ones used by professionals for long-run orbit calculations). Perhaps the simplest is the semi-implicit Euler method. There is also the Verlet method and leapfrog integration. I like the semi-implicit Euler method because it is super-simple (but being a first order-method it is still not terribly accurate): $$mathbf{v}_i(t+h)=mathbf{v}_i(t)+hmathbf{f}_i(t),$$ $$mathbf{x}_i(t+h)=mathbf{x}_i(t)+hmathbf{v}_i(t+h).$$ Do you see the difference? You calculate the updated velocity first, and then use it to update the positions - a tiny trick, but suddenly 2-body orbits are well behaved.



      The three body problem is chaotic in a true mathematical sense. We know there are situations where tiny differences in initial conditions get scaled up to arbitrarily large differences in later positions (even if we rule out super-close passes between masses). So even with an arbitrarily fine numerical precision there will be a point in time where our calculated orbits will be totally wrong. The overall "style" of trajectory may still be correct.






      share|cite|improve this answer









      $endgroup$
















        2












        2








        2





        $begingroup$

        Numerical analysis is used to calculate approximations to things: the value of a function at a certain point, where a root of an equation is, or the solutions to a set of differential equations. It is a huge and important topic since in practice most real problems in mathematics, science and technology will not have an explicit closed-form solution. In general there are trade-offs between accuracy and computational speed.



        For the three-body problem we have three point masses in starting locations $mathbf{x}_i(0)$ with velocities $mathbf{v}_i(0)$ that we want to calculate for later times $t$. Mathematically we want to find the solution to the system $$mathbf{x}'_i(t)=mathbf{v}_i(t),$$ $$mathbf{v}'_i(t)=mathbf{f}_i(t)/m_i,$$ $$mathbf{f}_i(t)=sum_{jneq i} Gm_i m_j/||mathbf{x}_i-mathbf{x}_j||.$$



        The obvious method is to think "if we move forward a tiny step $h$ in time, we can approximate everything to be linear", so we make a formula where we calculate the state at time $t+h$ from the state at time $t$ (and so on for $t+2h$ and onwards): $$mathbf{x}_i(t+h)=mathbf{x}_i(t)+hmathbf{v}_i(t),$$ $$mathbf{v}_i(t+h)=mathbf{v}_i(t)+hmathbf{f}_i(t).$$ This is called Euler's method. It is simple but tends to be inaccurate; the error per step is $approx O(h^2)$ and they tend to build up. If you try it for a two body problem it will make the orbiting masses perform a precessing rosette orbit because of the error build-up, especially when they get close to each other.



        There is a menagerie of methods for solving ODEs numerically. One can use higher order methods that sample the functions in more points and hence approximate them better. There are implicit methods that instead of trying to find a state at a later time only based on the current state look for a self-consistent late and intermediate state. As I said, this is a big topic.



        However, for mechanical simulations you may want to look at methods designed to preserve energy and other conserved quantities (symplectic methods - these are the ones used by professionals for long-run orbit calculations). Perhaps the simplest is the semi-implicit Euler method. There is also the Verlet method and leapfrog integration. I like the semi-implicit Euler method because it is super-simple (but being a first order-method it is still not terribly accurate): $$mathbf{v}_i(t+h)=mathbf{v}_i(t)+hmathbf{f}_i(t),$$ $$mathbf{x}_i(t+h)=mathbf{x}_i(t)+hmathbf{v}_i(t+h).$$ Do you see the difference? You calculate the updated velocity first, and then use it to update the positions - a tiny trick, but suddenly 2-body orbits are well behaved.



        The three body problem is chaotic in a true mathematical sense. We know there are situations where tiny differences in initial conditions get scaled up to arbitrarily large differences in later positions (even if we rule out super-close passes between masses). So even with an arbitrarily fine numerical precision there will be a point in time where our calculated orbits will be totally wrong. The overall "style" of trajectory may still be correct.






        share|cite|improve this answer









        $endgroup$



        Numerical analysis is used to calculate approximations to things: the value of a function at a certain point, where a root of an equation is, or the solutions to a set of differential equations. It is a huge and important topic since in practice most real problems in mathematics, science and technology will not have an explicit closed-form solution. In general there are trade-offs between accuracy and computational speed.



        For the three-body problem we have three point masses in starting locations $mathbf{x}_i(0)$ with velocities $mathbf{v}_i(0)$ that we want to calculate for later times $t$. Mathematically we want to find the solution to the system $$mathbf{x}'_i(t)=mathbf{v}_i(t),$$ $$mathbf{v}'_i(t)=mathbf{f}_i(t)/m_i,$$ $$mathbf{f}_i(t)=sum_{jneq i} Gm_i m_j/||mathbf{x}_i-mathbf{x}_j||.$$



        The obvious method is to think "if we move forward a tiny step $h$ in time, we can approximate everything to be linear", so we make a formula where we calculate the state at time $t+h$ from the state at time $t$ (and so on for $t+2h$ and onwards): $$mathbf{x}_i(t+h)=mathbf{x}_i(t)+hmathbf{v}_i(t),$$ $$mathbf{v}_i(t+h)=mathbf{v}_i(t)+hmathbf{f}_i(t).$$ This is called Euler's method. It is simple but tends to be inaccurate; the error per step is $approx O(h^2)$ and they tend to build up. If you try it for a two body problem it will make the orbiting masses perform a precessing rosette orbit because of the error build-up, especially when they get close to each other.



        There is a menagerie of methods for solving ODEs numerically. One can use higher order methods that sample the functions in more points and hence approximate them better. There are implicit methods that instead of trying to find a state at a later time only based on the current state look for a self-consistent late and intermediate state. As I said, this is a big topic.



        However, for mechanical simulations you may want to look at methods designed to preserve energy and other conserved quantities (symplectic methods - these are the ones used by professionals for long-run orbit calculations). Perhaps the simplest is the semi-implicit Euler method. There is also the Verlet method and leapfrog integration. I like the semi-implicit Euler method because it is super-simple (but being a first order-method it is still not terribly accurate): $$mathbf{v}_i(t+h)=mathbf{v}_i(t)+hmathbf{f}_i(t),$$ $$mathbf{x}_i(t+h)=mathbf{x}_i(t)+hmathbf{v}_i(t+h).$$ Do you see the difference? You calculate the updated velocity first, and then use it to update the positions - a tiny trick, but suddenly 2-body orbits are well behaved.



        The three body problem is chaotic in a true mathematical sense. We know there are situations where tiny differences in initial conditions get scaled up to arbitrarily large differences in later positions (even if we rule out super-close passes between masses). So even with an arbitrarily fine numerical precision there will be a point in time where our calculated orbits will be totally wrong. The overall "style" of trajectory may still be correct.







        share|cite|improve this answer












        share|cite|improve this answer



        share|cite|improve this answer










        answered 1 hour ago









        Anders SandbergAnders Sandberg

        8,21621025




        8,21621025























            0












            $begingroup$

            The "solution" of the three-body problem can be written as the pair of differential equations,
            begin{align}
            vec{v}&=frac{mathrm dvec{x}}{mathrm dt}\
            vec{a}&=frac{mathrm dvec{v}}{mathrm dt}
            end{align}

            where the latter is usually written in terms of the force, $mvec{a}=vec{F}$. Then using the definition of the derivative,
            $$
            frac{mathrm df}{mathrm dx}=lim_{hto0}frac{f(x+h)-f(x)}{h},
            $$

            the differential equations we started with can be written as the finite difference equations,
            begin{align}
            vec x(t+mathrm dt)&simeq vec x(t)+vec v,mathrm dt \
            vec v(t+mathrm dt)&simeq vec v(t)+vec a,mathrm dt
            end{align}

            which is done assuming that $mathrm dt$ is "just small" rather than infinitesimal.



            It is these equations that a computer uses to "solve" the three body problem: given an initial condition for each of the bodies, the computer iteratively steps forward in time using the above finite difference equations with the force being the $n$-body force.



            As mentioned in the comments, the simplistic model above is called Euler integration which is not at all well-suited for this problem because it does not conserve energy. A better option is called velocity Verlet, which is disucssed in other posts on physics.SE (I would recommend this post of mine as it gives some decent, but brief, details of the implementation).






            share|cite|improve this answer









            $endgroup$













            • $begingroup$
              Velocity verlet is "good" only in comparison to Euler. For solving the solar system, it's rather worthless. Accuracy degrades rapidly. People use verlet because (a) it shows some short-term dynamics, (b) it kinda-sorta conserves quantities that should be conserved, and (c) the higher order techniques used to "solve" the solar system don't extend well to several thousand objects, let alone millions and millions of objects.
              $endgroup$
              – David Hammen
              35 mins ago










            • $begingroup$
              @DavidHammen all very good points. Note that I only said Verlet is a better option vs Euler, not that it's the best or any similar such comparison.
              $endgroup$
              – Kyle Kanos
              31 mins ago
















            0












            $begingroup$

            The "solution" of the three-body problem can be written as the pair of differential equations,
            begin{align}
            vec{v}&=frac{mathrm dvec{x}}{mathrm dt}\
            vec{a}&=frac{mathrm dvec{v}}{mathrm dt}
            end{align}

            where the latter is usually written in terms of the force, $mvec{a}=vec{F}$. Then using the definition of the derivative,
            $$
            frac{mathrm df}{mathrm dx}=lim_{hto0}frac{f(x+h)-f(x)}{h},
            $$

            the differential equations we started with can be written as the finite difference equations,
            begin{align}
            vec x(t+mathrm dt)&simeq vec x(t)+vec v,mathrm dt \
            vec v(t+mathrm dt)&simeq vec v(t)+vec a,mathrm dt
            end{align}

            which is done assuming that $mathrm dt$ is "just small" rather than infinitesimal.



            It is these equations that a computer uses to "solve" the three body problem: given an initial condition for each of the bodies, the computer iteratively steps forward in time using the above finite difference equations with the force being the $n$-body force.



            As mentioned in the comments, the simplistic model above is called Euler integration which is not at all well-suited for this problem because it does not conserve energy. A better option is called velocity Verlet, which is disucssed in other posts on physics.SE (I would recommend this post of mine as it gives some decent, but brief, details of the implementation).






            share|cite|improve this answer









            $endgroup$













            • $begingroup$
              Velocity verlet is "good" only in comparison to Euler. For solving the solar system, it's rather worthless. Accuracy degrades rapidly. People use verlet because (a) it shows some short-term dynamics, (b) it kinda-sorta conserves quantities that should be conserved, and (c) the higher order techniques used to "solve" the solar system don't extend well to several thousand objects, let alone millions and millions of objects.
              $endgroup$
              – David Hammen
              35 mins ago










            • $begingroup$
              @DavidHammen all very good points. Note that I only said Verlet is a better option vs Euler, not that it's the best or any similar such comparison.
              $endgroup$
              – Kyle Kanos
              31 mins ago














            0












            0








            0





            $begingroup$

            The "solution" of the three-body problem can be written as the pair of differential equations,
            begin{align}
            vec{v}&=frac{mathrm dvec{x}}{mathrm dt}\
            vec{a}&=frac{mathrm dvec{v}}{mathrm dt}
            end{align}

            where the latter is usually written in terms of the force, $mvec{a}=vec{F}$. Then using the definition of the derivative,
            $$
            frac{mathrm df}{mathrm dx}=lim_{hto0}frac{f(x+h)-f(x)}{h},
            $$

            the differential equations we started with can be written as the finite difference equations,
            begin{align}
            vec x(t+mathrm dt)&simeq vec x(t)+vec v,mathrm dt \
            vec v(t+mathrm dt)&simeq vec v(t)+vec a,mathrm dt
            end{align}

            which is done assuming that $mathrm dt$ is "just small" rather than infinitesimal.



            It is these equations that a computer uses to "solve" the three body problem: given an initial condition for each of the bodies, the computer iteratively steps forward in time using the above finite difference equations with the force being the $n$-body force.



            As mentioned in the comments, the simplistic model above is called Euler integration which is not at all well-suited for this problem because it does not conserve energy. A better option is called velocity Verlet, which is disucssed in other posts on physics.SE (I would recommend this post of mine as it gives some decent, but brief, details of the implementation).






            share|cite|improve this answer









            $endgroup$



            The "solution" of the three-body problem can be written as the pair of differential equations,
            begin{align}
            vec{v}&=frac{mathrm dvec{x}}{mathrm dt}\
            vec{a}&=frac{mathrm dvec{v}}{mathrm dt}
            end{align}

            where the latter is usually written in terms of the force, $mvec{a}=vec{F}$. Then using the definition of the derivative,
            $$
            frac{mathrm df}{mathrm dx}=lim_{hto0}frac{f(x+h)-f(x)}{h},
            $$

            the differential equations we started with can be written as the finite difference equations,
            begin{align}
            vec x(t+mathrm dt)&simeq vec x(t)+vec v,mathrm dt \
            vec v(t+mathrm dt)&simeq vec v(t)+vec a,mathrm dt
            end{align}

            which is done assuming that $mathrm dt$ is "just small" rather than infinitesimal.



            It is these equations that a computer uses to "solve" the three body problem: given an initial condition for each of the bodies, the computer iteratively steps forward in time using the above finite difference equations with the force being the $n$-body force.



            As mentioned in the comments, the simplistic model above is called Euler integration which is not at all well-suited for this problem because it does not conserve energy. A better option is called velocity Verlet, which is disucssed in other posts on physics.SE (I would recommend this post of mine as it gives some decent, but brief, details of the implementation).







            share|cite|improve this answer












            share|cite|improve this answer



            share|cite|improve this answer










            answered 43 mins ago









            Kyle KanosKyle Kanos

            21.6k114894




            21.6k114894












            • $begingroup$
              Velocity verlet is "good" only in comparison to Euler. For solving the solar system, it's rather worthless. Accuracy degrades rapidly. People use verlet because (a) it shows some short-term dynamics, (b) it kinda-sorta conserves quantities that should be conserved, and (c) the higher order techniques used to "solve" the solar system don't extend well to several thousand objects, let alone millions and millions of objects.
              $endgroup$
              – David Hammen
              35 mins ago










            • $begingroup$
              @DavidHammen all very good points. Note that I only said Verlet is a better option vs Euler, not that it's the best or any similar such comparison.
              $endgroup$
              – Kyle Kanos
              31 mins ago


















            • $begingroup$
              Velocity verlet is "good" only in comparison to Euler. For solving the solar system, it's rather worthless. Accuracy degrades rapidly. People use verlet because (a) it shows some short-term dynamics, (b) it kinda-sorta conserves quantities that should be conserved, and (c) the higher order techniques used to "solve" the solar system don't extend well to several thousand objects, let alone millions and millions of objects.
              $endgroup$
              – David Hammen
              35 mins ago










            • $begingroup$
              @DavidHammen all very good points. Note that I only said Verlet is a better option vs Euler, not that it's the best or any similar such comparison.
              $endgroup$
              – Kyle Kanos
              31 mins ago
















            $begingroup$
            Velocity verlet is "good" only in comparison to Euler. For solving the solar system, it's rather worthless. Accuracy degrades rapidly. People use verlet because (a) it shows some short-term dynamics, (b) it kinda-sorta conserves quantities that should be conserved, and (c) the higher order techniques used to "solve" the solar system don't extend well to several thousand objects, let alone millions and millions of objects.
            $endgroup$
            – David Hammen
            35 mins ago




            $begingroup$
            Velocity verlet is "good" only in comparison to Euler. For solving the solar system, it's rather worthless. Accuracy degrades rapidly. People use verlet because (a) it shows some short-term dynamics, (b) it kinda-sorta conserves quantities that should be conserved, and (c) the higher order techniques used to "solve" the solar system don't extend well to several thousand objects, let alone millions and millions of objects.
            $endgroup$
            – David Hammen
            35 mins ago












            $begingroup$
            @DavidHammen all very good points. Note that I only said Verlet is a better option vs Euler, not that it's the best or any similar such comparison.
            $endgroup$
            – Kyle Kanos
            31 mins ago




            $begingroup$
            @DavidHammen all very good points. Note that I only said Verlet is a better option vs Euler, not that it's the best or any similar such comparison.
            $endgroup$
            – Kyle Kanos
            31 mins ago










            HeeysamH is a new contributor. Be nice, and check out our Code of Conduct.










            draft saved

            draft discarded


















            HeeysamH is a new contributor. Be nice, and check out our Code of Conduct.













            HeeysamH is a new contributor. Be nice, and check out our Code of Conduct.












            HeeysamH is a new contributor. Be nice, and check out our Code of Conduct.
















            Thanks for contributing an answer to Physics Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            Use MathJax to format equations. MathJax reference.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fphysics.stackexchange.com%2fquestions%2f456808%2fhow-do-computers-solve-the-three-body-problem%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            What are all the squawk codes?

            What are differences between VBoxVGA, VMSVGA and VBoxSVGA in VirtualBox?

            Hudsonelva