View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000144||OpenFOAM||Bug||public||2011-02-23 02:01||2011-02-24 10:40|
|Platform||Linux||OS||Debian, Ubuntu||OS Version||sid, 10.04|
|Summary||0000144: if deltaT is too small setDeltaT.H keeps decreasing it.|
|Description||we have cases where deltaT is small, and automatic timestepping is used. |
In some runs, DeltaT keeps decreasing, as does the maxCo number.
extract from logs
Courant Number mean: 6.0295357e-09 max: 0.019955862
deltaT = 4.1438281e-16
Increased the timePrecision from 11 to 12 to distinguish between timeNames at time 0.092389214
Courant Number mean: 1.2041388e-09 max: 0.0057485438
deltaT = 9.9451875e-17
Increased the timePrecision from 12 to 13 to distinguish between timeNames at time 0.092389214
Courant Number mean: 4.1471612e-10 max: 0.0022231297
deltaT = 2.386845e-17
Increased the timePrecision from 13 to 14 to distinguish between timeNames at time 0.092389214
|Steps To Reproduce||specific cases, but I assume it could happen generally. |
|Additional Information||could be related to Foam::Time::adjustDeltaT()|
Namely, if the deltaT is too small adjustDeltaT calculates a negative number of timesteps remaining (overflow of label type)
Info << "need " << nStepsToNextWrite << " more ts before write, dt = " << deltaT_ << ", new dt = " << newDeltaT;
to Time.C gives
need -2147483647 more ts before write, dt = 2.218159e-13, new dt = -2.3249373e-13
Propose wrapping a check for overflow, such as
@@ -76,17 +78,20 @@ void Foam::Time::adjustDeltaT()
label nStepsToNextWrite = label(timeToNextWrite/deltaT_ - SMALL) + 1;
- scalar newDeltaT = timeToNextWrite/nStepsToNextWrite;
- // Control the increase of the time step to within a factor of 2
- // and the decrease within a factor of 5.
- if (newDeltaT >= deltaT_)
+ if (nStepsToNextWrite < 0 || nStepsToNextWrite > FOAM_LABEL_MAX)
- deltaT_ = min(newDeltaT, 2.0*deltaT_);
- deltaT_ = max(newDeltaT, 0.2*deltaT_);
+ scalar newDeltaT = timeToNextWrite/nStepsToNextWrite;
+ // Control the increase of the time step to within a factor of 2
+ // and the decrease within a factor of 5.
+ if (newDeltaT >= deltaT_)
+ deltaT_ = min(newDeltaT, 2.0*deltaT_);
+ deltaT_ = max(newDeltaT, 0.2*deltaT_);
|Tags||No tags attached.|
I get 'patch' error on your snippet - might just be formatting error.
I assume it is good enough just to keep the deltaT_ constant if the nStepsToNextWrite is very large or even overflows?
Yes, it should be. (if there's more than 2000000000 time steps till it writes, making sure runTime matches with writeInterval is not an immediate problem).
Also, I think that this bug will only appears under very specific circumstances (probably the simulation is going to crash anyway - mine did). but there might be some usage case where it's a valid concern.
But the fix is easy, and shouldn't affect performance, hence the bug report.
fixed in 7fe1057a4bc51e20677f7e16c5ad84afe8dc896c.
Thanks for reporting.
||Note Added: 0000261|
||Note Added: 0000263|
||Note Added: 0000264|
||Status||new => resolved|
||Fixed in Version||=> 1.7.x|
||Resolution||open => fixed|
||Assigned To||=> user4|