Number of time steps for adjustableRunTime calculated not robust

The current logic to calculate the remaining number of time steps goes

    scalar nSteps = timeToNextWrite/deltaT_ - SMALL;
    label nStepsToNextWrite = label(nSteps) + 1;

which for e.g. deltaT=0.005, writeInterval 0.1 should go

   nSteps = 19.99999999;
  nStepsToNextWrite = 19+1

however the SMALL can fall in the truncation error and instead

   nSteps = 20.000000001;
  nStepsToNextWrite = 20+1

so replace logic with

    scalar nSteps = timeToNextWrite/deltaT_;
    // nSteps can be < 1 so make sure at least 1
    label nStepsToNextWrite = max(1, round(nSteps));

mentioned in commit 867ae452e4e1dc6680239dbdd3259583f59d445b

I believe we need ceil instead of round. Imagine deltaT = 0.7 and writeInterval = 1.0, then nSteps = 1.429; nStepsToNextWrite = 1; So actual deltaT would be set to 1.0, which would violate CFL criterion pretty badly.

By Ilya Popov on 2017-03-13T08:26:32 (imported from GitLab project)

Good point but ceil instead of round would also cause the example above (nSteps = 20.00000001) to become 21 timesteps. There is the protection in the change of the deltaT (deltaT_ = min(newDeltaT, 2.0*deltaT) but in your example this is not good enough. Any ideas?

closed via commit 3b95f1e492e77c11e7f6b6dcaf657515ee75e758

By Andrew Heather on 2017-06-29T20:10:09 (imported from GitLab project)

closed via merge request !121 (merged)

By Andrew Heather on 2017-06-29T20:10:10 (imported from GitLab project)

mentioned in commit 3b95f1e492e77c11e7f6b6dcaf657515ee75e758

By Andrew Heather on 2017-06-29T20:38:04 (imported from GitLab project)