View Issue Details

IDProjectCategoryView StatusLast Update
0002820OpenFOAM[All Projects] Bugpublic2018-02-08 11:26
ReporterShortyAssigned Towill 
Status resolvedResolutionfixed 
PlatformGNU/LinuxOSUbuntuOS Version16.04
Product Versiondev 
Fixed in Versiondev 
Summary0002820: Tricky bug in »adjustableRunTime« while using functionObjects
DescriptionHi all,

yesterday I build two tutorials for @Will in order to check the residual control. During the evening, I was investigating into the transient case and added some more stuff. However, I realized, that after adding a functionObject, the solver behaves strange. The time step decreased (for any reason) sometimes to 1e-20 and I had to make several iterations in order to reach the next write step. First, I thought it is a problem of my set-up, or local computer. I rechecked the set-up two times. With functionObject, strange behavior, without everything is fine.

The time decrease can be so extreme, that I get an floating point exception. After restarting the case, everything seems to be okay for a few more iterations till the same strange behavior occurs.

Thus, I checked it on another machine too. The same situation. During the night I was debugging and found, that the function »adjustDeltaT« in the Time class makes some trouble.

The problem is that we are not allowed to change the deltaT_ before calling the objectFunction.adjustTimeStep() function. If we do so, this function has a wrong deltaT information for estimating the new deltaT.

Thus, if one has some » unluckily « chosen writeInterval values in the controlDict (solver) and functionObject, they end up in this strange behavior.

I hope I made a clear statement.
Steps To ReproduceStart the run script in the attachment
Additional InformationA patch is included, that changes the set-up of deltaT_ in the Time class after we have the correct estimation of the function object adjustment.
TagsTime Control



2018-01-27 12:51


chtResControlCheck_Transient_BugReport.tar.gz (1,264,720 bytes)


2018-01-27 12:51


Time.C (29,225 bytes)


2018-01-27 12:52

reporter   ~0009225

That was really a tricky one :)
Hope you can reproduce it on your machines.


2018-02-02 15:44


Foam_Time_adjustDeltaT.diff (1,032 bytes)
diff --git a/src/OpenFOAM/db/Time/Time.C b/src/OpenFOAM/db/Time/Time.C
index f002f414f..fc828e00b 100644
--- a/src/OpenFOAM/db/Time/Time.C
+++ b/src/OpenFOAM/db/Time/Time.C
@@ -96,6 +96,9 @@ void Foam::Time::adjustDeltaT()
+    // Estimation for controlDict settings
+    scalar deltaT = 0;
     if (adjustTime)
         scalar nSteps = timeToNextWrite/deltaT_ - small;
@@ -111,16 +114,19 @@ void Foam::Time::adjustDeltaT()
             // and the decrease within a factor of 5.
             if (newDeltaT >= deltaT_)
-                deltaT_ = min(newDeltaT, 2.0*deltaT_);
+                deltaT = min(newDeltaT, 2.0*deltaT_);
-                deltaT_ = max(newDeltaT, 0.2*deltaT_);
+                deltaT = max(newDeltaT, 0.2*deltaT_);
+    // Adjust the time step based on functionObjects settings or controlDict
+    deltaT_ = min(deltaT_, deltaT);


2018-02-02 15:44

manager   ~0009241

I have reproduced this, and the provided fix does solve the problem for this case. However, the change breaks other function objects' modification of the time step; notably setTimeStepFunctionObject. I haven't figured a way around this yet.

Also, the local deltaT variable needs initialising to the class deltaT_, rather than zero, if non-adjustable time stepping is to continue working.

I've attached a patch that applies cleanly to dev (post all the great/vGreat/small/... changes), in case anyone else wants to tinker.


2018-02-02 15:55

reporter   ~0009244

Thanks @will for your investigation. I will check the setTimeStepFunctionObject and see if I can find any solution.


2018-02-02 15:58

reporter   ~0009245

I just wanted to ask something more. Do you have any defined or structured procedure in order to identify if the patch makes problems with other function objects? Or do you just try one by one? I am asking in order to do this process myself in order to save your time.


2018-02-02 16:39

manager   ~0009248

The only automated check we have is ./Alltest in the tutorials directory. That's how I noticed that the deltaT initialisation was causing fixed time-step cases to fail.

Sometimes you just have to run tests and/or read the code, though. In this instance I noticed the change's incompatibility with other function objects by reading through the implementations of "adjustTimeStep". There are only two that actually do anything.


2018-02-04 18:14

reporter   ~0009251

I had a look at it again. First, yes, deltaT should not be initialized with 0. After I changed it, the timeStep is working as expected in combination with the functionObjects. Please just change

scalar deltaT = 0;


scalar deltaT = deltaT_;

This fixes it. I did not figure out any other problems anymore.


2018-02-08 11:26

manager   ~0009282

Your change still breaks the setTimeStepFunctionObject. Try the multiphase/reactingTwoPhaseEulerFoam/laminar/steamInjection tutorial.

I've had to change how it works more fundamentally. The function object now returns the time to the next write, rather than setting the time directly. This keeps the logic within the Time class and fundamentally prevents this sort of interaction from occurring. An added benefit is that the setTimeStepFunctionObject can now be used with or without adjustable write time.

Resolved in dev by commit 139ffcc1.

Issue History

Date Modified Username Field Change
2018-01-27 12:51 Shorty New Issue
2018-01-27 12:51 Shorty File Added: chtResControlCheck_Transient_BugReport.tar.gz
2018-01-27 12:51 Shorty Tag Attached: Time Control
2018-01-27 12:51 Shorty File Added: Time.C
2018-01-27 12:52 Shorty Note Added: 0009225
2018-02-02 15:44 will File Added: Foam_Time_adjustDeltaT.diff
2018-02-02 15:44 will Note Added: 0009241
2018-02-02 15:55 Shorty Note Added: 0009244
2018-02-02 15:58 Shorty Note Added: 0009245
2018-02-02 16:39 will Note Added: 0009248
2018-02-04 18:14 Shorty Note Added: 0009251
2018-02-08 11:26 will Assigned To => will
2018-02-08 11:26 will Status new => resolved
2018-02-08 11:26 will Resolution open => fixed
2018-02-08 11:26 will Fixed in Version => dev
2018-02-08 11:26 will Note Added: 0009282