View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002820 | OpenFOAM | [All Projects] Bug | public | 2018-01-27 12:51 | 2018-02-08 11:26 |
Reporter | Shorty | Assigned To | will | ||
Priority | normal | Severity | major | Reproducibility | random |
Status | resolved | Resolution | fixed | ||
Platform | GNU/Linux | OS | Ubuntu | OS Version | 16.04 |
Product Version | dev | ||||
Fixed in Version | dev | ||||
Summary | 0002820: Tricky bug in »adjustableRunTime« while using functionObjects | ||||
Description | Hi 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 Reproduce | Start the run script in the attachment | ||||
Additional Information | A 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. | ||||
Tags | Time Control | ||||
|
chtResControlCheck_Transient_BugReport.tar.gz (1,264,720 bytes) |
|
Time.C (29,225 bytes) |
|
That was really a tricky one :) Hope you can reproduce it on your machines. |
|
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_); } else { - deltaT_ = max(newDeltaT, 0.2*deltaT_); + deltaT = max(newDeltaT, 0.2*deltaT_); } } } functionObjects_.adjustTimeStep(); + + // Adjust the time step based on functionObjects settings or controlDict + deltaT_ = min(deltaT_, deltaT); } |
|
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. |
|
Thanks @will for your investigation. I will check the setTimeStepFunctionObject and see if I can find any solution. |
|
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. |
|
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. |
|
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. |
|
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. |
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 |