Use gravity to crash planets and suns into each other in the name of science? Yes, please! Welcome to Super Planet Crash, a webtoy by science blogger Stefano Meschiari, which serves as a kind of digital orrery (a device which shows the relative size, position and motion of planets in a solar system). In this addicting little app, you have a 2AU area, that is, an area only twice the distance of our Earth from the sun, in which to place planets and/or stellar companions, and attempt to keep them stable for up to 500 years of elapsed time. With small, earth-type bodies, it's a cinch, but add a dwarf star and you up the difficulty. Fortunately, you also increase the points you earn for each year of stability.
The sleek design and ease of use make the app irresistible, especially when you begin to click around on the page. You can choose different solar system templates, such as a compact Kepler-11 theoretical system, four different planet sizes, and two stellar companions. You can speed it up, slow it down, pause and take a picture of your winning combination. The "end screen" even gives you a link to share the system you create on your web site or blog. In addition to the fun stuff, there are also links to space and science sites to help you make sense of the Newtonian physics at work. Be sure you want to leave the page though: they open in the same window. And who knows. The next time we check, we may see your name (and get to watch a prerecorded version of your system) in the the High Scores list.
Lol. I thought I found a loophole by spamming 10 ice giants (and was thinking of using heavier things next) in the habitable zone in the exact same orbit. It gave me a very high score.... which turned out to be nothing when I noticed the leaderboard. :p
That's pretty clever--I never thought of it until I looked at the high scorers' recordings. I can't come close to their scores, even doing what they did!
Actually, turns out that many people in the leaderboards used the strategy. It seems that I just need a dwarf star and some luck.
cute, but it clearly suffers from numerical instabilities. Multi-body orbital problems are highly non-linear, so the slightest rounding error can cause them to explode unexpectedly...
I ran the high score models and didn't get the results that they did. I suspect that when you accelerate it actually increases the model timestep, and models like this are going to be very sensitive to the timestep size and prone to quantization error.
Which is to say - while there is a strategy for getting high scores, actually achieving one is mostly luck and perseverance.
I hate the fact that it always starts you with a planet already in play.
@eamurdock:
Upon digging in the simulation code it's using Euler method as the integrator (gravitation force is GMm/(r^2) towards direction of the other body, or GMm/(r^3) times distance vector. The code just add the above expression up for all mass pairs). Euler method is the simplest and worst integrator of all of them, having a error size to order (step size)^1, which of course, is very bad when being used in physical simulation.
In physical simulation the standard integrator is the 4th order Runge-Kutta method (called 4th order because error are to order (step size)^4), and it's quite easy to implement. The downside is you have to evaluate the calculation 4 times as usual.
Hi, uncopy2002 -- a commenter on my website directed me to this comment.
Sorry, I need to correct you here.
I am well aware of the problem associated with rounding errors, in fact I wrote about it here [1] and other places on the web as comments. When games are saved, coordinates are truncated, so for highly chaotic systems (as would be the highest-scoring systems), any approximation is inflated exponentially with time. This is a feature *inherent* to the N-body problem. (A feature I did research about during my undergraduate career, way back when!). There are a few more issues that are hard to solve -- feel free to shoot me an email if you want to keep this conversation going (see below.)
The simulation code is most definitely *not* Euler, which as the comment mentioned is a very numerically unstable, 1st order integration scheme. What is implemented is a leapfrog (Verlet) integrator, which is a symplectic 2nd order scheme. For an interactive N-body simulator (running in Javascript, so limited in performance to what the browser offers), it gives the best bang for the buck by conserving energy of the (perturbed) Hamiltonian [2]. If you could go higher order, you would not not want to use Runge-Kutta 4, which is a generic integrator, but rather a 4-th order symplectic scheme such as the Hermite algorithm.
Increasing the speed does not change the time-step, but rather how many time-steps are taken between frames. You can verify it in the code (UI.evolve).
Finally, I am sure the code is by no means bug-free, so anyone should feel free to report bugs via email: stefano.meschiari AT gmail.com (this of course will be easier once the code is actually on GitHub :))
-StefanoM
[1] http://www.stefanom.org/2000000-systems-played/
[2] Although energy and other conserved quantities are of course not time-symmetric once you start adding bodies ex-nihilo...
@smeschia: Thanks for the comment! I learnt something from you today. :D
Sorry for my limited understanding; reading unbeautified code is confusing and prone to errors, and you definitely know better than me about numerical methods.
Absolutely, no need to apologize! I hope I didn't end up sounding condescending.
I'm trying to get the code open source as soon as I can so that people can wade into its internals and improve it, but since there will be many eyes looking at it, I want to make sure that (a) I choose the right license for it (so that it will not be exploited commercially), and (b) the code is better commented and structured.
I keep trying to set up an earth-size planet in the L1 point of a dwarf star orbiting the primary star, but I've had no luck. I'm not sure it can be done without control over the initial velocity.
What is the mass of the primary star? I was guessing around 300,000 times earth's mass, a little smaller than the sun. That would mean the planet's orbital radius should be a little less than 1/3 the dwarf star's orbital radius, I think.
After playing quite a few times (fun!) I was wondering why smaller bodies weren't more commonly trapped by larger ones as moons. I did have an earth-sized body trapped in an orbit around a brown dwarf or dwarf star once or twice but only for 20-30 revolutions before being flung out into the barrier. Is there some reason that an earth-sized body is too big to be a stable moon, even for a dwarf star? (I guess the largest moon in our own solar system, Ganymede, is not as large as Earth...) Or is there some other explanation?
http://www.stefanom.org/spc/?np=2&m1=1&x1=-.6&y1=.6&vx1=-0.0187&vy1=-0.0187&m2=.00003&x2=-0.5&y2=0.5&vx2=0.025&vy2=0.009&speed=10&dt=0.05
Hey guys,
If you are interested in setting up some different systems (and not actually scoring) then you can easily do this by editing the browser code of the three templates systems.
I have no idea about code, and very little understanding of orbital mechanics other than high school physics, but from what I can figure out:
np = number of planets (does not count initial star)
m1, m2... = mass of body 1,2... in relation to initial star
y1, y2... = distance from initial star in the y axis
x1, x2... = distance from initial star in the x axis
vy1, vy2... = velocity from initial star in the y axis
vx1, vx2... = velocity from initial star in the x axis
speed = initial star speed
dt = ???
Also, the coordinate system is based on the initial star, but the screen is centred on the centre of mass. If you place m1=1 at x=.8 y=-.8, then to put the next body directly in the middle of the screen, it's x=.4 y=-.4
snubcube22: Capturing of a smaller body as a moon is actually rather difficult in reality, and given how the game works I think it should be impossible in principle, or nearly so. The problem, however, is not how big the bodies are, but how much energy they have.
In reality, for a smaller body approaching a larger one from a distance to get captured, it must lose some of its energy somehow, such as in a collision or by plowing through a gas cloud. Otherwise its total energy (the sum of its kinetic and potential energies) will be too high to it to fall into a steady orbit around the larger body. If its energy was low enough for a stable orbit, it would already have been in such an orbit to start with. Since it was moving freely at the start, it must remain free at the end, merely making a close, high-speed pass and then flying away. Planets in a system stay in orbit around their star because they formed with energies low enough to make escape impossible.
To make matters more difficult, the would-be moon must lose enough energy to give a stable bound orbit, but not too much. Otherwise it will pass so close to the larger body that it will either collide or break up from tidal forces.
In this simulation, there is no way for bodies to lose energy in this fashion. So, if you look at simple two-body interactions (i.e. you ignore the influence of the other more distant bodies), any close pass must be a one-time affair. However, since this is an N-body system, and furthermore is being simulated numerically with finite accuracy, things get more complicated, because it's possible for energy to be transferred among the bodies. I guess that temporarily bound pairs can pop up, since you've seen some. But such a pair is probably very unlikely to remain stable.
Thanks Colin! That clears things up nicely about the game. Though I'm wondering now about what I've read about irregular satellites like Neptune's moon Triton that are thought to have been captured from the Kupier belt. There are lots of satellites like this... Wikipedia says 113. So is it just that there have been several billion years for flying rocks to get lucky, or would all of those satellites have had to pass through a gas cloud or collide with something to make capture more likely? Or would they have low energy for some other reason?
OMG! I just got the highest score! I tried to copy paste what I did, but it didn't work. Anyway, I had a small planet near the edge, and I put a dwark right next to the sun. Prefect.
To go above, I someone put a brown dwarf like a mercury distance away, put a ton of small planets in habitable zone. 11,315,578
I just beat everyone. I'm new high score. It was luck because I had the small planet in the perfect spot but it only took me about ten minutes or so to get it.
Update