Three-Body Problem: Soluble or Insoluble?

[D H]

Or infinite series.

Not particularly useful in this problem. The wikipedia article on the n-body problem constains a fairly good discussion of Sundman's series. Scienceworld at wolfram.com also discusses this topic. From the scienceworld article, (emphasis mine):

Since such global regularizations are available for this problem, the restricted problem of three bodies can be considered to be complete "solved." However, this "solution" does not address issues of stability, allowed regions of motion, and so on, and so is of limited practical utility (Szebehely 1967, p. 42). Furthermore, an unreasonably large number of terms (of order 10^8,000,000) of Sundman's series are required into attain anything like the accuracy required for astronomical observations.​

Links:
Wiki: http://en.wikipedia.org/wiki/N-body_problem#Sundman.27s_theorem_for_the_3-body_problem
Scienceworld: http://scienceworld.wolfram.com/physics/RestrictedThree-BodyProblem.html

Or use non-elementary functions.

Non-elementary functions were widely used prior to the advent of modern computers. Invariant and mean orbital elements are essentially special-purpose non-elementary functions. These techniques were developed to describe a body orbiting the Earth, for example. Even ignoring perturbing factors from the Sun and Moon, a body orbiting the Earth does not obey Kepler's laws because the Earth is not a point mass. Various techniques were developed to analytically describe orbital behavior about the Earth that account for Earth's oblateness to some extent (usually J2 only). These techniques are still used to some extent; the two-line orbital elements issued by NORAD are one example.

twofish-quant, you missed another formerly widely-used technique in your list of alternatives, perturbation theory. The description of the evolution of the Moon's orbit used to be done using perturbation techniques rather than numerical integration. People are much better at using analytic models than they are are performing lots and lots of rote calculations. Numerical integration didn't really become a viable option until the development of modern computers.

 

[Frame Dragger]

Not particularly useful in this problem. The wikipedia article on the n-body problem constains a fairly good discussion of Sundman's series; see http://en.wikipedia.org/wiki/N-body_problem#Sundman.27s_theorem_for_the_3-body_problem. Scienceworld @wolfram.com also discusses this; see http://scienceworld.wolfram.com/physics/RestrictedThree-BodyProblem.html From that latter article, (emphasis mine):

Since such global regularizations are available for this problem, the restricted problem of three bodies can be considered to be complete "solved." However, this "solution" does not address issues of stability, allowed regions of motion, and so on, and so is of limited practical utility (Szebehely 1967, p. 42). Furthermore, an unreasonably large number of terms (of order 10^8,000,000) of Sundman's series are required into attain anything like the accuracy required for astronomical observations.​

Non-elementary functions were widely used prior to the advent of modern computers. Invariant and mean orbital elements are essentially special-purpose non-elementary functions. These techniques were developed to describe a body orbiting the Earth, for example. Even ignoring perturbing factors from the Sun and Moon, a body orbiting the Earth does not obey Kepler's laws because the Earth is not a point mass. Various techniques were developed to analytically describe orbital behavior about the Earth that account for Earth's oblateness to some extent (usually J2 only). These techniques are still used to some extent; the two-line orbital elements issued by NORAD are one example.

twofish-quant, you missed another formerly widely-used technique in your list of alternatives, perturbation theory. The description of the evolution of the Moon's orbit used to be done using perturbation techniques rather than numerical integration. People are much better at using analytic models than they are are performing lots and lots of rote calculations. Numerical integration didn't really become a viable option until the development of modern computers.

Ok, now THAT matches what I thought I knew, and what my friend works at in the API.

EDIT... I take that back... damn... Remember again that as Ich said, I'm talking about pure GR, regularized PDE's using Numerical GR (and therefore computers with a looooot of memory).

 

[D H]

You are still going to have to use numerical techniques, Frame Dragger, if you want to do anything beyond a toy problem. That one has to resort to numerical techniques does not mean the problem is insoluble.

 

[Frame Dragger]

You are still going to have to use numerical techniques, Frame Dragger, if you want to do anything beyond a toy problem. That one has to resort to numerical techniques does not mean the problem is insoluble.

That does make sense. Thanks very much for helping me (start) to understand this. I'm going to hit MTW and some others and recognize that I need to learn a loooooot more.

 

[twofish-quant]

twofish-quant, you missed another formerly widely-used technique in your list of alternatives, perturbation theory. The description of the evolution of the Moon's orbit used to be done using perturbation techniques rather than numerical integration.

It's still pretty widely used in actual calculations. The trouble with numerical integration is that it takes forever to do a calculation so what people do in practice for these sorts of things is that they use numerical calculations to figure out the perturbation elements, and then when people run code that involves the location of the planets they do a quick calculation out of the perturbation elements (VSOP87) rather than a long calculation that reruns the numerical integrations.

People are much better at using analytic models than they are are performing lots and lots of rote calculations.

And analytic or semi-analytic models tend to be very, very fast. The thing about computers is that they make possible analytic calculations that would not otherwise be possible. You can even do symbolic analytic calculations.

The problem is that if you are doing widely different problems, the setup time is painful.

 

[D H]

VSOP87

There is a good reason VSOP hasn't been updated since 1987: It's not a very good model. An analytic model is not going to be as good as a numeric model. There are two leading contenders for high-precision planetary ephemerides, the Development Ephemerides (DE series) from JPL and the Ephemerides of the Planets and the Moon (EPM series) from the Russian Institute of Applied Astronomy. Both are based on numerical integration. To avoid the numerical integration, the released data in the DE series are in the form of sets of Chebyshev polynomial coefficients, with each set applying to a particular planet and a particular span of time. Computing the expansion of the resulting Chebychev polynomials is very fast. In a realistic orbital simulation, models of the Earth's rotation, its atmosphere, and non- gravity model will take much more time than computing ephemerides. (The Moon and Mars are even worse because the gravity models for those objects are really nasty.)

 

[twofish-quant]

There are two leading contenders for high-precision planetary ephemerides, the Development Ephemerides (DE series) from JPL and the Ephemerides of the Planets and the Moon (EPM series) from the Russian Institute of Applied Astronomy. Both are based on numerical integration. To avoid the numerical integration, the released data in the DE series are in the form of sets of Chebyshev polynomial coefficients, with each set applying to a particular planet and a particular span of time.

Cool! Do you know if anyone has put together some open source software that uses these algorithms?

One thing that I'm finding, which seems to be the situation in general is that as computers increase in speed, the types of algorithms which are useful changes quite radically.

 

[Frame Dragger]

Cool! Do you know if anyone has put together some open source software that uses these algorithms?

One thing that I'm finding, which seems to be the situation in general is that as computers increase in speed, the types of algorithms which are useful changes quite radically.

Your comment about speed is very true, but these models are often limited more by memory than raw clock speed. (at least, in the case of work at the the API in Germany). Hell, it's like any other backwards-engineering project... brute force goes a long way, but you have to refine that attack. More power then allows for a more effcient use of memory resources, which ARE severely limiting.

 

[Nabeshin]

EDIT... I take that back... damn... Remember again that as Ich said, I'm talking about pure GR, regularized PDE's using Numerical GR (and therefore computers with a looooot of memory).

So... why use GR for the solar system? It's like demanding we obtain equations of motion for all 10^35 particles (or whatever number) in the apollo rocket before we send it to space...

Or of course a 3-body black hole system or something similar? Although even here I'm not sure you'd need full GR, given that the system is likely unstable and one (or all) of the bodies will become ejected. The scales on which you need to do these full GR calculations is quite small compared to any astronomical scale (order of 10-100s of schwarzschild radii, or <~100km!).

Are you just trying to create an incredibly computationally difficult problem with little to no rewards (i.e. just for fun)?

 

[Frame Dragger]

So... why use GR for the solar system? It's like demanding we obtain equations of motion for all 10^35 particles (or whatever number) in the apollo rocket before we send it to space...

Or of course a 3-body black hole system or something similar? Although even here I'm not sure you'd need full GR, given that the system is likely unstable and one (or all) of the bodies will become ejected. The scales on which you need to do these full GR calculations is quite small compared to any astronomical scale (order of 10-100s of schwarzschild radii, or <~100km!).

Are you just trying to create an incredibly computationally difficult problem with little to no rewards (i.e. just for fun)?

Me?! I'm not modeling anything, and wouldn't know where to start if I wanted to! I'm referring to a friend who works on the 2-body problem re: predicting gravitational waves. I was explaining why I misunderstood that n-body problems are not insoluble. From my understanding, using Newtonian approximations with GR corrections is far more efficient for the solar system, but again, I'm not in a position to know. As I said, this is a friend of mine in Germany, not me, here. Sorry if I was in any way misleading... I thought I was pretty clear.

EDIT: That said, it DOES sound fun to compute down to the Planck Scale... fun, but a terrible waste as you say. I won't deny that it would be amazing to see it however...

 

[D H]

Cool! Do you know if anyone has put together some open source software that uses these algorithms?

http://www.ephemeris.com/software.html
http://www.projectpluto.com/jpl_eph.htm

Fortran source code + data + documentation is at
ftp://ssd.jpl.nasa.gov

 

[Nabeshin]

Me?! I'm not modeling anything, and wouldn't know where to start if I wanted to! I'm referring to a friend who works on the 2-body problem re: predicting gravitational waves. I was explaining why I misunderstood that n-body problems are not insoluble. From my understanding, using Newtonian approximations with GR corrections is far more efficient for the solar system, but again, I'm not in a position to know. As I said, this is a friend of mine in Germany, not me, here. Sorry if I was in any way misleading... I thought I was pretty clear.

EDIT: That said, it DOES sound fun to compute down to the Planck Scale... fun, but a terrible waste as you say. I won't deny that it would be amazing to see it however...

Ahh, ok I don't know why I thought you were doing something. I see your initial post now.

Yeah, we have enough trouble with 2-body problems in numerical GR as it is that to imagine going to three is quite hopeless atm. I mean, simulations already take months running on super computers and generate endless terabytes of data. At least we know how to extract waveforms from these cases by this point!

Again, though, 3-body is an academic exercise at best. I doubt we would expect anywhere within the universe past, present, or future, a 3-body black hole or neutron star system for which these calculations would be necessary.

 

[D H]

So... why use GR for the solar system?

JPL and the Russian Institute of Applied Astronomy do use GR, or rather a post-Newtonian approximation. They model general relativity as a perturbative acceleration on top of that predicted by Newtonian gravity. They are also very careful regarding dynamic time, the time scale in which the equations of motion are propagated. JPL uses its own home-brewed T_eph; they apparently do not like Barycentric Coordinate Time.

 

[Frame Dragger]

Ahh, ok I don't know why I thought you were doing something. I see your initial post now.

Yeah, we have enough trouble with 2-body problems in numerical GR as it is that to imagine going to three is quite hopeless atm. I mean, simulations already take months running on super computers and generate endless terabytes of data. At least we know how to extract waveforms from these cases by this point!

Again, though, 3-body is an academic exercise at best. I doubt we would expect anywhere within the universe past, present, or future, a 3-body black hole or neutron star system for which these calculations would be necessary.

I agree 100%. I was making roughly that point, except that I misunderstood the difference between "theoretically impossible" and "deeply impractical"... which is not a small mistake on my part.

 

[twofish-quant]

Your comment about speed is very true, but these models are often limited more by memory than raw clock speed. (at least, in the case of work at the the API in Germany).

Depends on the calculation. PDE's are very heavily limited by memory. ODE's are not. In any case the cost of memory has gone down as quickly as the cost of CPU.

Hell, it's like any other backwards-engineering project... brute force goes a long way, but you have to refine that attack.

Or you can wait for better computers to come out. Also putting together brute force is sometimes non-trivial.

 

[Frame Dragger]

Depends on the calculation. PDE's are very heavily limited by memory. ODE's are not. In any case the cost of memory has gone down as quickly as the cost of CPU.



Or you can wait for better computers to come out. Also putting together brute force is sometimes non-trivial.

I can only admit to familiarity with the use of H/PDE's in this particular case, but cost aside, it's still a factor given the amount of information produced (as Nabeshin has said). As for waiting... I find the demands placed on computers outpace the development of the computers themselves, thus far at least. EDIT: I should add, as I said, "in the case of the work at the API...", and they ARE using H/PDE's for their current simulations. I don't believe I claimed that this was a universal truth in Numerical GR. Also... waiting doesn't really advance research.

For the brute force... my only familiarity with BF algorithms has been... well... let's say it was in the "information security" region. They are difficult to assemble because you need such a vast library to attempt it... hence the need to pick and choose. Cracking a password or encryption, and breaking down PDEs is similar. That said, trivial or not, sometimes it's the only way given limited information, or if you want to be careful that you don't screen valuble information (say, in the case of medical imaging).

 

[twofish-quant]

I find the demands placed on computers outpace the development of the computers themselves, thus far at least.

That's because you are always trying to use the compute power that you have for something new. In the case of PDE's, more compute power, higher resolution.

Cracking a password or encryption, and breaking down PDEs is similar.

I don't see the connection. The two are very, very different problems.

 

[Frame Dragger]

That's because you are always trying to use the compute power that you have for something new. In the case of PDE's, more compute power, higher resolution.



I don't see the connection. The two are very, very different problems.

I was speaking strictly in the context of brute-force vs. algorithmic attacks on a problem, and the demands they place on the computer. Brute Force uses the CPU heavily, but spares the memory. The other produces a great deal of data, which hogs memory.

 

[twofish-quant]

I was speaking strictly in the context of brute-force vs. algorithmic attacks on a problem, and the demands they place on the computer. Brute Force uses the CPU heavily, but spares the memory. The other produces a great deal of data, which hogs memory.

I still don't see the connection with PDE's. With PDE's, the amount of memory that you need is large, but it's constant over time, since you aren't saving any results in memory. All your results are dumped to disk.

Also with PDE's, "brute force" techniques tend to use a lot more memory.

 

[Frame Dragger]

I still don't see the connection with PDE's. With PDE's, the amount of memory that you need is large, but it's constant over time, since you aren't saving any results in memory. All your results are dumped to disk.

Also with PDE's, "brute force" techniques tend to use a lot more memory.

I'm not sure how to describe this well (for lack of technical knowledge, not a glut of it)...

PDEs take results, feed them back into the original problem, run it again, etc. A good cracking algorithim does much the same thing. I'll take your word for it (you're knowledgeable,) as to the memory demands of PDE's being constant over time... as for CPU demands however, Brute Force vs. Algorithm is still a valid comparison. I didn't realize that memory was constant with PDE's... how is it that you don't need to keep track of the process for error correction? I'm now genuinely confused.

 

[twofish-quant]

PDEs take results, feed them back into the original problem, run it again, etc.

No they don't. If you are doing time stepping, you are just looking at the last set of results. Anything before that you don't need in order to do any calculation, and you can dump all of that to disk.

as for CPU demands however, Brute Force vs. Algorithm is still a valid comparison.

I think we are talking about very different things here.

how is it that you don't need to keep track of the process for error correction?

Because you set up the algorithm in ways so that the errors are bounded. If the errors are not bounded, then what happens is that your calculation becomes unstable and you get garbage very quickly.

I think you are getting confused because you are thinking there is some sort of connection between security algorithms and PDE calculation, and as far as I can tell there isn't.

 

[Frame Dragger]

No they don't. If you are doing time stepping, you are just looking at the last set of results. Anything before that you don't need in order to do any calculation, and you can dump all of that to disk.



I think we are talking about very different things here.



Because you set up the algorithm in ways so that the errors are bounded. If the errors are not bounded, then what happens is that your calculation becomes unstable and you get garbage very quickly.

I think you are getting confused because you are thinking there is some sort of connection between security algorithms and PDE calculation, and as far as I can tell there isn't.

Well, this seems to be a pretty clear case of, "I'm completely wrong." On the bright side, I have another area to research. Thanks for taking the time to lead me by the hand (so to speak) on this one. I appreciate it.