Integrators, mods, etc questions

[resyst]

Hello all. I do not currently have access to US2 but I am an owner of US1. The new simulation features introduced already justify the value of the program quite fairly. But I do have a couple of questions.

Is there a list of the integrator methods used to simulate. The best I found was a comment on a blog post but I'm sure if it reflects what currently in the program.

Also, I remember asking about support for custom math to allow different equations, integrators, etc to be used. I did find mention of "light modding" but I'm not sure if this would be regarded in that scope.

Finally, is there an option to run the same simulation in parallel using different integrators? It would be nice to see how fast simulations diverge.

[Greenleaf]

See this for question about integrators
https://www.youtube.com/watch?v=IJ2MhXUDZ6o


As to running two or more simulations in parallel, it is something which is planned, but is not currently in the pipeline.

[resyst]

Thanks for your quick reply.

I believe that you commented also at the blog http://blog.frogslayer.com/universe-sandbox-simulation-analysis/
It was mentioned there that US2 would have

As to the actual integration schemes used, where US1 had two, we have in US2 currently

Adams Bashforth 6th order multistep
Admas Moulton 7th order multistep
Explicit Euler 1th order
Semi implicit Euler 1st order symplectic
Forest Ruth 4th order symplectic
Hermite 6th order
PEFRL 4th order symplectic
Runge Kutta 2nd order
Runge Kutta 4th order
Runge Kutta Feldberg 4th/5th order
Verlocity Verlet 2dn order symplectic

I purchased US2 but am unable to find any settings specific to the integrator used. This is actually located as a submenu in the "Gravity" section. The timestep also appears to be ignored past a certain point.

I did not see the Adams or Hermite methods listed. Will multistep methods not be supported or will that be in the future.

[Greenleaf]

Thanks for your quick reply.
...

The timestep also appears to be ignored past a certain point.
...
I did not see the Adams or Hermite methods listed. Will multistep methods not be supported or will that be in the future.

Thanks for posting interesting questions ;-)

The default time stepping is adaptive, which means that the time step, the user can control, is the desired time between two frames - not the integration step length. If the user requests a time of 30 days, but the current system will become unstable at steps longer than 5 days, then the integration will take 30 days / 5 days=6 steps of 5 days before returning and letting graphics render the new state.
So it is...render, step 5, step 5, step 5, step 5, step 5, step 5, render, step...

The sensitivity of the simulation is controlled through the accuracy. This is used to define how much/little instability is ok. This in turn affects the allowable step length. Higher sensitivity and the safe step might be 1 day rather than 5 days. This would then require 30 steps between frames, which can affect performance.
To cater for the interactive experience, physics gets a certain time to do its work. That could be for example 10 ms. This prevents physics from locking up everything while it is taking a million small integration steps (if sensitivity is high and user requested time between frames is large).

So, if the user asks for 30 days between frames and a stable time step is 5 days this requires 6 steps of 5 days to move all the 30 days forward in time.
If every sub step takes 2 ms and physics is only given 10 ms for its work, what will happen is that
10 ms/ 2 ms = 5 steps can be taken before time runs out.
.. so the user asked that the simulation would advance 30 days every frame, but physics only has time to do 5 steps of 5 days which is 25 days. After this it must return.

This will result in the time step visually turning red or yellow in the GUI to reflect that things are not running quite as fast as requested. By hovering over the time step text at the bottom of the screen, you can see the requested speed (relative to real time) as well as the maximal possible speed.

This should all mean that you can request any time, however fast, and the simulation should still be responsive and not unduly fly apart. You will, however, only get as much time acceleration as your system can handle. In reality you can actually still make things fly off... in a wrong way. I am working on a better stability criterion since the current is in some cases too simplistic.

Interesting fact (though obvious, but still worth mentioning) is that this is not a real-time application. It is a faster than real time. Default solar system runs at 1296000 times real time or 15 days every wall clock second. Was it only 1x time, things would be so simple.

As to the missing integrators... Hermite 4th order was dropped because it performed no better or worse than comparable integrators and it did require calculating the time derivative of acceleration, commonly called... the jerk. Since it was the only integrator with that requirement, it simplified things to drop it entirely.For multi step methods (integration methods which base the future state on the history of the last few steps and how things changed between steps), they are also currently dropped because they had special requirements. They are good, fast and simple, if you start an n-body system and let it run its course. If you frequently add or remove bodies (user interactions, collisions etc), then they have to be constantly restarted, since their history steps become invalid. In short, they are not that well suited for a highly interactive sandbox.