timeStep and divergence

[Scott Cytacki]

I'm working on a proposal with Dan that would require us to synchronize the running of Lab models across multiple computers. I can go into more details later. 

Right now though I'm wondering about the timeStep, computation time, and model divergence.  

If I increase the timeStep does that increase the chances of model divergence?

Also if we remove the view code from the equation and the timeStep is multiplied by X and the timeStepsPerTick is divided by X, does that mean the model runs X times faster?  

Does the integration code use some 'settling out' approach so that larger timeSteps might require more time to solve?

I realize that some interactives run scripts on each tick, these scripts will prevent my timeStep adjustment above from speeding up the model by X times.  

Is there non-view code in MD2D that also runs on each tick which would also affect the performance of my timeStep adjustment?

-- 

Scott Cytacki

The Concord Consortium

http://concord.org

[Daniel Damelin]

> On Dec 2, 2014, at 4:27 PM, Scott Cytacki <scyt...@concord.org> wrote:
>
> Right now though I'm wondering about the timeStep, computation time, and model divergence.
>
> If I increase the timeStep does that increase the chances of model divergence?

Yes. The model calculations get less accurate and the atoms move more for each step, so there is a greater chance that a fast moving atom will overlap too much with another atom.

> Also if we remove the view code from the equation and the timeStep is multiplied by X and the timeStepsPerTick is divided by X, does that mean the model runs X times faster?

That seems right. You would be doing half as many calculations to advance one tick which would still be the same amount of model time.

> Does the integration code use some 'settling out' approach so that larger timeSteps might require more time to solve?

I don’t think so, but I’m not intimately familiar with the innards of the engine calculations.

>
> I realize that some interactives run scripts on each tick, these scripts will prevent my timeStep adjustment above from speeding up the model by X times.

That is also true if the view rendering takes a significant amount of time. In that case you won’t get the X times speedup you are expecting above.

> Is there non-view code in MD2D that also runs on each tick which would also affect the performance of my timeStep adjustment?

We store some info about the model each tick so we can go back and forth through the history without recalculating. I’m not sure if there is anything else.

-Dan

[Piotr Janik]

It depends on what we understand by "speed up". It can be either model progress in time (e.g. 1 real second = 2 model ps instead of 1 real second = 1 model ps) or perceptual speed / smoothness (measured by rendered frames per second).

This model is pretty good for experimenting with timeStep and timeStepsPerTick:

http://lab.concord.org/interactives.html#interactives/basic-examples/sample-rate-and-refresh-rate.json

2014-12-02 22:04 GMT+00:00 Daniel Damelin <ddam...@concord.org>:

> Also if we remove the view code from the equation and the timeStep is multiplied by X and the timeStepsPerTick is divided by X, does that mean the model runs X times faster?

That seems right. You would be doing half as many calculations to advance one tick which would still be the same amount of model time.

Right, but only if rendering and "per tick scripts" time cost is equal to 0. 

> Does the integration code use some 'settling out' approach so that larger timeSteps might require more time to solve?

I don’t think so, but I’m not intimately familiar with the innards of the engine calculations.

I don't think Lab has anything like that. Calculations with timeStep = 1 and timeStep = 2 should take the same amount of time. At least the basic MD2D engine. For example chemical reactions calculations are ran every X fs (not timeSteps), so if we increase timeStep, these calculations will be performed more often.

 

> Is there non-view code in MD2D that also runs on each tick which would also affect the performance of my timeStep adjustment?

We store some info about the model each tick so we can go back and forth through the history without recalculating. I’m not sure if there is anything else.

We perform couple of tasks each tick (history update, view models update etc.), but the most expensive one is rendering anyway.

Best regards,

Piotr

[Scott Cytacki]

Thank you for the responses they are very helpful.

Does anyone want to take a guess at how many weeks it would take to get a dynamically adjusting model so that the number of model seconds per real seconds is fixed regardless of whether you are on a slow computer or a fast one?  And on the slower computer if some other process is stealing CPU time then this rate needs to continue to stay constant. It wouldn't have to be perfect, but the average of this ratio would need to be nearly perfect.

Also this wouldn't have to work for every single model on slow computers, but it would need to work for most models.

On the slow computers it would be OK to sacrifice the smoothness of animation (FPS) as well as accuracy in order to keep this model seconds/real seconds constant.

The author would specify a target range of 'model seconds'/'real seconds'.  

Here is what I'm thinking we'd need to do:

We'd need to separate ticks from display refreshes. Either ticks become virtual and have a fixed period in model seconds.  Or we keep ticks linked to display refreshes and introduce a new 'event' that has a fixed period in model seconds.

We'd have to decide if the property system continue to only be based on this fixed period in model seconds.  Or perhaps it should become more complex and some properties can be updated on view refresh instead of on this fixed period.  The graph would need to be based on a fixed period. The 'tick history' would also be affected. We'd need to re-examine the point of the tick history and see the best way to adapt it to this dynamic time scaling.

I know there was some work in this direction before, but it wasn't completed. Does anyone remember the issues that came up there?

I'm thinking at least 4 weeks.  And probably more like 8 weeks.

--
You received this message because you are subscribed to the Google Groups "lab-models" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lab-models+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Piotr Janik]

I've been doing experiments which are a bit related to that. Here is another model:

http://lab.concord.org/interactives.html#interactives/basic-examples/performance-tuning-for-slow-computers.json

You can find there "simulation progress rate". I believe that what you want is to keep this value constant on every kind of device (including slow ones). It's defined as:

  FPS * timeStep * timeStepsPerTick (here)

so it defines model seconds/real seconds ratio.

There is also "auto performance tuning", defined in this class. Actually it tries to ensure that "simulation progress rate" reaches target simulation progress rate, which is 60 (optimal FPS value) * initialTimeStep * initialTimeStepsPerTick.

Why would you like to separate tick from rendering? To ensure that scripts (defined per tick) and properties update still work the same, even if we change rate of view refreshes? Note that when we start playing with timeStep, it will break determinism of models anyway. 

I think that variable time step is sometimes used when constant model/real time ratio is expected. E.g. engine can measure time that passed since the previous step and then adjusts time step for upcoming calculations. E.g. some steps can use time step 0.1fs (e.g. only 1 atom on the screen, blazing fast rendering), some 2fs (multiple atoms on screen or user started some other processes and everything slowed down), etc. But obviously there are limits of this approach.

I will definitely have to think on that more to assess required time, but it seems to be pretty challenging. Mostly because we can't tweak timeStep too much (divergence), while differences in performance are enormous (both engine and rendering). Also, models may work significantly different on various devices then (due to different time step). It may be really difficult to find values that work reasonably in all cases.