View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0000144OpenFOAMBugpublic2011-02-23 02:012011-02-24 10:40
Reporteruser137Assigned Touser4 
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
PlatformLinuxOSDebian, UbuntuOS Versionsid, 10.04
Summary0000144: if deltaT is too small setDeltaT.H keeps decreasing it.
Descriptionwe 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

TS1...
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

TS2...
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

TS3...
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 Reproducespecific cases, but I assume it could happen generally.

Additional Informationcould 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)

ie.

adding
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_);
- }
- else
- {
- 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_);
+ }
+ else
+ {
+ deltaT_ = max(newDeltaT, 0.2*deltaT_);
+ }
         }
     }
 }


TagsNo tags attached.

Activities

user4

2011-02-23 17:03

  ~0000261

Hi andersking,

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?

user137

2011-02-24 00:58

  ~0000263

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.

user4

2011-02-24 10:40

  ~0000264

fixed in 7fe1057a4bc51e20677f7e16c5ad84afe8dc896c.

Thanks for reporting.

Issue History

Date Modified Username Field Change
2011-02-23 02:01 user137 New Issue
2011-02-23 17:03 user4 Note Added: 0000261
2011-02-24 00:58 user137 Note Added: 0000263
2011-02-24 10:40 user4 Note Added: 0000264
2011-02-24 10:40 user4 Status new => resolved
2011-02-24 10:40 user4 Fixed in Version => 1.7.x
2011-02-24 10:40 user4 Resolution open => fixed
2011-02-24 10:40 user4 Assigned To => user4