View Issue Details

IDProjectCategoryView StatusLast Update
0000064OpenFOAMBugpublic2010-10-25 19:15
Reporteruser43Assigned Tohenry  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
PlatformLinuxOSUbuntuOS Version9.10
Summary0000064: Semi-implicit Bullirsch-Stoer ODE solver is not reducing the timestep correctly
Descriptionsrc/ODE/ODESolvers/SIBS/SIBS.C

To solve the problem, change line 41 of this file:

Original:
       SIBS::redMax = 1.0e-5, SIBS::redMin = 0.0, SIBS::scaleMX = 0.1;

New:
       SIBS::redMax = 1.0e-5, SIBS::redMin = 0.7, SIBS::scaleMX = 0.1;

Background:
ODE solver "semi-implicit Bullirsch-Stoer" uses adaptive timestepping roughly according to:

1- Take the suggested timestep, and calculate the error
2- Is the error acceptable?
Yes - Calculate a timestep increase factor.
    - Apply timestep increase and move to the next time step.
No - Calculate a timestep reduction factor.
   - Apply timestep reduction, and retry the current timestep.

The timestep reduction (red) is tested against maximum (redMax) and minimum (redMin) limits.

Problem:
These timestep reduction limits are set incorrectly, and red always evaluates to the greatest possible timestep reduction: 1.0e-5. redMin is set to zero in the constructor (line 41). Should be set to 0.7.

This may have been cause by confusion over variable "red". It is a reduction factor... so a maximum reduction factor corresponds to a minimum next timestep. redMax and redMin are named for their effect on the timestep, not on their absolute value. redMax should therefore be smaller than redMin.

Solution:
The code is directly adapted from Numerical Recipes. The values used in this case are:

redMin = 0.7
redMax = 1.0e-5
Steps To ReproducePerform any ODE solution, set the timestep to an unreasonably large value. Observe value of red as it goes through lines 207 and 208.
TagsNo tags attached.

Activities

henry

2010-10-25 19:15

manager   ~0000090

Thanks for the bug-report.
Resolved in OpenFOAM-1.7.x by commit e5e8175dbfaf1d5a6d77332ac934b37de47ce7a4

Issue History

Date Modified Username Field Change
2010-10-25 18:00 user43 New Issue
2010-10-25 19:13 henry Assigned To => henry
2010-10-25 19:13 henry Status new => assigned
2010-10-25 19:15 henry Note Added: 0000090
2010-10-25 19:15 henry Status assigned => resolved
2010-10-25 19:15 henry Resolution open => fixed