I do mean body.x[body_index], body.y[body_index], etc as:

body={ x:[] ,y:[] ,z:[] ,vx:[] ,vy:[] ,vz:[] ,mass:[] }

I find this is running 20% faster than the fastest on my chrome browser (an old version) but is slightly slower on firefox, but catches up a bit with 11 bodies.

I expect it could run faster yet by crunching the code up more and maybe removing objects altogether, but i made few changes as possible just to compare the difference in addressing.

There is also function "offsetMomentum" which tweaks the suns movement according to momentum of the planets, it seems very extraneous to me, gravitational influence should surely be sufficient in itself regarding conservation of momentum. I suspect that function is more likely a catch for large errors which can result from point grav bodies getting to close to each other.

SoA vs AoS, see also [1] [2].

[1] https://software.intel.com/sites/default/files/article/39227...

[2] https://en.wikipedia.org/wiki/AOS_and_SOA

Thanks. I note a different aspect of SoA is when different functions or loops involve only a subset of the feilds, only the arrays of the involved fields are fetched. With AoS the feilds are scrunched in memory next to each other byRecord. That could benefit algorithms which only touch some of the records, however every record usually needs accessed to see whether its involved or not - the 'involving feild' would need stored separately for AoS to have any benefit.

Floating point errors accumulate quite quickly when dt is small it could be a smoothing function.

Forgive me a boast about a nbody simulation ive been developing: I got the details 60 planets and moons etc. from Nasas JPL server and put them into it. Running at a timestep of 30 minutes or hours (virtual time) for a year, the Earth ends up within a moons orbit of where JPL says its supposed to go. I think the innaccuracy is due to limitation of javascripts 64bit float (rather than, possible relativistic effect). Not sure yet, Solar system scales are so huge.

When dt is too large and bodies get too close, they get super-attracted to each other in one step, and by the time of the next step, they have travelled too far to get slowed again, this is where I see major errors can occur. Its necessary to put a throttle in the force calculation, or to reduce dt to deal with that 'near missing'. Or to substep but that seems to require excessive adjustments.

Nice. Agreed on errors with big dt. For me it is usually when shortening the time step to try to minimize for these that floating point errors start to come in.

Now chuck in some velocity dependent forces and start screaming (that's what I've found with physical simulations anyway).

One trick which improves stability heaps is 'tempering' the data to fit the dt. Weve got the verlet integration thing where they say the velocities should be half a step behind before updating forces. I find they should also be reduced a little as objects are cutting through the analog curve of their orbits in the timestep - as a hypotenuse instead of an arc. When I tempered the data like this orbits were all much stabilised. Its required for objects if they are added to the model later too. To have their precise velocities measured while tempered they also need 'de-tempered' to tell where they are going precisely. Just calculate their acceleration move them half step and adjust for ratio of hypot/curve.

"velocity dependent forces" I have been wondering how to implement a sort of quasi-electromagnetic force without the big expense of maintaining a magnetic field. I find the electro-magnetic force mind blowing compared to newtonian gravity. Like charges seem to be able to attract when travelling together, this would seem to produce patterns and structure more readily than gravitation.