
HTML5 Gravity/Galaxy Simulator - mcdevhammer
http://mobile.sheridanc.on.ca/~claassen/Gravity/Gravity.html
======
jpco
This is cool, and I'm a sucker for gravity/space simulators (as my hours
logged on Celestia would prove), but it should be noted that in terms of
"galaxy" it's inaccurate. Specifically, this inaccuracy (the galaxy rotation
problem) is the driving force behind the hypothesis of dark matter [0].

I don't mean to be pedantic or anything. I just think it's interesting.

[0]
[http://abyss.uoregon.edu/~js/cosmo/lectures/lec17.html](http://abyss.uoregon.edu/~js/cosmo/lectures/lec17.html)

~~~
drinchev
Yeah maybe it would be nice idea if when you generate a galaxy it also
generates small dark matter particles around the regular particles.

~~~
phkahler
What laws of gravity would those particles have to obey?

~~~
drinchev
I think the answer of your question is being seek by a lot of physicists.

------
mcdevhammer
I also wrote a 3D version in C++ using OpenGL
[https://github.com/claassen/GalaxySim3D](https://github.com/claassen/GalaxySim3D)

------
ellysetaylor21
I am not familiar with this but it seems like a playing tool for kids, can I
have some tutorial to learn how this will make?

------
lemmingapex
Well done. Here's my HTML5 Version:
[https://news.ycombinator.com/item?id=8288434](https://news.ycombinator.com/item?id=8288434)

------
hliyan
What emerges from the random field looks remarkably like the large scale
structure of the known universe.

------
conistonwater
I can't help but notice there is a magical "Theta" parameter, with the
description "Higher = faster, less accurate". I think here it's a threshold
for ignoring children nodes' internal structure in an octree.

As a matter of good software engineering (and numerical analysis, and
mathematics, too), your software shouldn't have magical parameters with
mysterious consequences for the correctness of your software. (I know
correctness is maybe not the point _here_ , but still...) Also, note that
there is no way for a user to check how accurate the simulation is for a given
"Theta" parameter. The name is completely non-descriptive as well.

There are mathematically sound ways to determine the accuracy of the
simulation. If they are expensive, tell that to the user explicitly, but
default to the correct implementation, not the fast one.

Note that while the user has no clue what "Theta" is, the user might instead
be able intuitively specify that they want the simulation to be accurate "to X
digits for the first Y seconds of the simulation". I think that would be a
better software design. As it is, "Theta" is an exposed quirk of the
implementation.

~~~
lutusp
> As a matter of good software engineering (and numerical analysis, and
> mathematics, too), your software shouldn't have magical parameters with
> mysterious consequences for the correctness of your software.

To some extent, yes, but consider that we're speaking of a numerical
differential equation solver. If we make the time steps too large, the program
runs fast but the simulation is less realistic. If we go too far and make the
time steps very small, we'll start seeing rounding errors in the floating-
point processing.

The reason this class of simulation is numeric is because all but the the most
trivial orbital simulations must be performed numerically. The reason for
that, in turn, is because of the Three-Body Problem:

[http://en.wikipedia.org/wiki/Three-
body_problem](http://en.wikipedia.org/wiki/Three-body_problem)

By the way, while we're on the topic, here's my HTML5/JavaScript orbital
simulator plus math tutorial:

[http://arachnoid.com/orbital_dynamics](http://arachnoid.com/orbital_dynamics)

~~~
conistonwater
> To some extent, yes, but consider that we're speaking of a numerical
> differential equation solver. If we make the time steps too large, the
> program runs fast but the simulation is less realistic. If we go too far and
> make the time steps very small, we'll start seeing rounding errors in the
> floating-point processing.

But this just means that the problem needs to be solved carefully; what you've
done is state the problem. Look at any textbook on numerical analysis, such as
Numerical Recipes, or even something more basic. It will explain how to
implement adaptive time-stepping for numerical solution of ODEs.

Here the parameter is not for time-stepping, it's for ignoring nodes in an
octree, but you can still mathematically pick a parameter that generates
something like a desired level of accuracy, instead of having to specify the
parameter itself.

> The reason this class of simulation is numeric is because all but the the
> most trivial orbital simulations must be performed numerically. The reason
> for that, in turn, is because of the Three-Body Problem:

You make all of this sound like it's a difficult problem. For a basic ODE
solver, adaptive time-stepping is one of the most standard techniques. Most
introductory numerical analysis courses in universities cover this, so usually
the reason people implement it this way is that they simply haven't heard
about it, and don't know that they can look it up in a textbook.

~~~
lutusp
> You make all of this sound like it's a difficult problem.

It is a difficult problem. Consider all the elements of a solution on which
space missions depend. All of them must be generated using numerical modeling
methods, and for a solar system simulation in which most or all the candidate
bodies are modeled, the computation load is quite high.

> but you can still mathematically pick a parameter that generates something
> like a desired level of accuracy, instead of having to specify the parameter
> itself.

This isn't true, or it's not assured to be true. The reason is that orbital
systems with > 2 bodies meet the definition of a chaotic system, a system
acutely sensitive to initial conditions. Everyone who works in this field
understands that there's a time horizon past which we really cannot say what
the solar system's configuration will be.

~~~
conistonwater
> It is a difficult problem.

Implementing an ODE solver good enough to use for designing spacecraft
trajectories is a difficult problem. Implementing an ODE solver that can
handle an n-body problem (with a fairly small n) without leaving user-visible
magical parameters is not difficult. Introductory textbooks can explain how to
do this.

> The reason is that orbital systems with > 2 bodies meet the definition of a
> chaotic system, a system acutely sensitive to initial conditions.

Even if you have a chaotic dynamical system, you can still solve it. You don't
solve it in the sense that the trajectory you get is the correct one, because,
as you rightly say, that is mathematically impossible for long time periods.
But you can solve it in the sense that the solution you get "could" have
originated from an initial condition close to the given initial condition.

There are many interesting things you can do for complicated ODE problems. But
writing ODE solvers of the level of complexity and accuracy we are talking
about here is a solved problem.

