View Issue Details

IDProjectCategoryView StatusLast Update
0000145OpenFOAMBugpublic2011-07-20 17:05
Reporteruser137Assigned Touser8 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
PlatformLinuxOSDebian, Ubuntu (OS independent)OS Versionsid, 10.04
Summary0000145: Corner cases in ParticleI.H - lambda calculation.
DescriptionIn ParticleI.H lambda is calculated for face intersection & particle movement.

Edge cases are introduced by avoiding SIGFPE (lambdaDenominator < SMALL)

This results in some inefficiencies in the code (too many movement steps required) and near infinite loops (appears as a hang or very slow execution).

Steps To Reproducesimulation with large numbers of particles, where edge cases are more likely to occur.
Additional InformationFor particles that are moving slowly (almost stationary), or small timesteps are being used lambdaNominator and lambdaDenominator may be small. There is a check for lambdaDenominator < SMALL (stops div by 0). if both lamdaNominator and lambdaDenominator are < SMALL, an incorrect lambda value may be returned

ie. if lambdaDenominator < lambdaNominator < SMALL, lambda > 1, and we should only track to the end position directly. (Don't leave the cell)
Forcing lambdaDenominator = SMALL in this case sets lambdaNominator <lambdaDenominator and will return lambda < 1. Hence only a fraction of a step will be made.
In the next step, it is still likely that lambdaDenominator < lambdaNominator < SMALL holds, and we again track only a fraction of a step.

This means many(*) movement steps are made in cases where explicit 1 step movement could have been made.

This corner case should be tested for.

(*) I have added a step counter to test this, and with MAX_STEPS set to 1000000, a number of particles exceed this no of iterations.


A proposed change is included in the attached file. (though there's probably room for further optimisation)
TagsNo tags attached.

Activities

user137

2011-02-23 07:11

 

of-bug.C (1,225 bytes)   
scalar lambda = 0;

if (mag(lambdaDenominator) < VSMALL)
{ 
    //edge case
    if (mag(lambdaNominator) < VSMALL)
    { 
         // we're very close to the face & moving ~parallel, return lambda explicitly
        if (lambdaDenominator > 0 && lambdaNominator > 0)
        {
            if (lambdaDenominator < lambdaNominator) 
                lambda = 1.1; //needs to be > 1.0, particle stays in cell
            else // travelling along the face   
                lambda = 1.0; // assume we can move to the end position (to machine precision)
        } 
        else if (lambdaDenominator < 0 && lambdaNominator < 0)
        {
            if (lambdaDenominator > lambdaNominator) 
                lambda = 1.1; //needs to be > 1.0, particle stays in cell
            else // travelling along the face   
                lambda = 1.0; // assume we can move to the end position (to machine precision)
                
            
        } 
        else 
        { 
            //moving away from face, needs to be < 0
            lambda = -1.0;
        }
    }
    else
    {
        lamdba = 1.1; // not passing through this face
    }       

} else {
    lambda = lambdaNominator/lambdaDenominator;
}

return lambda;
of-bug.C (1,225 bytes)   

user8

2011-06-16 18:00

  ~0000443

The tracking algorithm in OpenFOAM 2.0.0 has been rewritten to use the old algorithm, but applied to a tet-decomposition of the cells.

The handling of lambda was tightened up in the process, along the lines that you identify.

Re-report or reopen the bug if you think that this doesn't address the issue fully. Thanks for reporting.

Graham

user4

2011-07-20 17:05

  ~0000578

Most likely fixed in version 2.0.0.

Issue History

Date Modified Username Field Change
2011-02-23 07:11 user137 New Issue
2011-02-23 07:11 user137 File Added: of-bug.C
2011-03-01 14:22 user4 Assigned To => user8
2011-03-01 14:22 user4 Status new => assigned
2011-06-16 18:00 user8 Note Added: 0000443
2011-06-16 18:00 user8 Status assigned => closed
2011-06-16 18:00 user8 Resolution open => fixed
2011-07-20 17:05 user4 Note Added: 0000578
2011-07-20 17:05 user4 Status closed => resolved
2011-07-20 17:05 user4 Fixed in Version => 2.0.x