View Issue Details

IDProjectCategoryView StatusLast Update
0002820OpenFOAMBugpublic2018-02-08 11:26
ReporterShorty Assigned Towill  
PrioritynormalSeveritymajorReproducibilityrandom
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

Activities

Shorty

2018-01-27 12:51

reporter  

Shorty

2018-01-27 12:51

reporter  

Time.C (29,225 bytes)   

Shorty

2018-01-27 12:52

reporter   ~0009225

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

will

2018-02-02 15:44

manager  

Foam_Time_adjustDeltaT.diff (1,032 bytes)   

will

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.

Shorty

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.

Shorty

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.

will

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.

Shorty

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;

to

scalar deltaT = deltaT_;

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

will

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