View Issue Details

IDProjectCategoryView StatusLast Update
0003030OpenFOAMFeaturepublic2018-12-18 09:40
ReporterakidessAssigned Tohenry 
Status closedResolutionsuspended 
Product Version 
Fixed in Version 
Summary0003030: Restrict minimum timestep for simulations with adaptive time step
DescriptionSometimes, OpenFOAM manages to hang on to a blown up simulation by reducing the time step to very small values. This is not desirable, since it leads to the blocking of computational resources without producing a meaningful result. I thus suggest the introduction of an optional minimum allowed timestep.
Additional InformationChanges required:
1. Addition of minDeltaT in createTimeControls.H
- runTime.controlDict().lookupOrDefault<scalar>("minDeltaT", 0.0)

2. In setDeltaT.H, change the setting of new timestep to

TagsNo tags attached.



2018-08-07 08:10

manager   ~0009907

I don't think this is a good approach as the time-step control is usually used for cases in which the Courant number must be strictly limited, i.e. will crash due to unboundedness if this limit is violated. A better approach would be to simply stop the run if the time-step falls below some limit.


2018-08-07 08:38

reporter   ~0009908

Indeed that would be nicer than crashing. In this case, I guess we should add something like the following to setDeltaT.H?

scalar newDeltaT = min(deltaTFact*runTime.deltaTValue(), maxDeltaT);

if (newDeltaT < minDeltaT) runTime.writeAndEnd();


2018-08-07 09:15

manager   ~0009909

We have considered this several times and not really converged on the best approach. It could be done in setDeltaT.H but that would require maintaining several implementations, or in Time::setDeltaT which would be good if you also want options on writing because it could reset the endTime so that functionObjects etc. could execute. Another option would be to write a functionObject to stop the run.


2018-08-07 18:07

reporter   ~0009912

Tricky. Setting in setDeltaT.H seems to be the least desirable option considering maintenance, but on the other hand I think a minimum timestep criterion should be enforced at the same location where it is done for the maximum timestep. The maxCo/maxDeltaT setting is essential for transient runs with adaptive timestepping, so I wouldn't move it into a function object. This leaves moving maxDeltaT into Time::setDeltaT or adding minDeltaT to every setDeltaT.H


2018-08-07 18:22

manager   ~0009913

Stopping the run if the time-step becomes lower than some level could by done in a functionObject. The big difference to setting the maximum is that it has serious side effects, in particular stopping then run and you want a (optional) write. So it cannot really be done in setDeltaT.H, it has to be in Time or a functionObject.

Either way this is a significant effort and would need funding via maintenance:


2018-08-08 07:17

reporter   ~0009919

I'll try to submit a patch.


2018-08-14 17:25

manager   ~0009951

Suspended pending a patch and maintenance funding.

Issue History

Date Modified Username Field Change
2018-08-07 07:56 akidess New Issue
2018-08-07 08:10 henry Note Added: 0009907
2018-08-07 08:38 akidess Note Added: 0009908
2018-08-07 09:15 henry Note Added: 0009909
2018-08-07 18:07 akidess Note Added: 0009912
2018-08-07 18:22 henry Note Added: 0009913
2018-08-08 07:17 akidess Note Added: 0009919
2018-08-14 17:25 henry Assigned To => henry
2018-08-14 17:25 henry Status new => closed
2018-08-14 17:25 henry Resolution open => suspended
2018-08-14 17:25 henry Note Added: 0009951