View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000145 | OpenFOAM | Bug | public | 2011-02-23 07:11 | 2011-07-20 17:05 |
Reporter | Assigned To | ||||
Priority | normal | Severity | minor | Reproducibility | always |
Status | resolved | Resolution | fixed | ||
Platform | Linux | OS | Debian, Ubuntu (OS independent) | OS Version | sid, 10.04 |
Summary | 0000145: Corner cases in ParticleI.H - lambda calculation. | ||||
Description | In 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 Reproduce | simulation with large numbers of particles, where edge cases are more likely to occur. | ||||
Additional Information | For 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) | ||||
Tags | No tags attached. | ||||
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; |
|
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 |
|
Most likely fixed in version 2.0.0. |
Date Modified | Username | Field | Change |
---|---|---|---|
2011-02-23 07:11 |
|
New Issue | |
2011-02-23 07:11 |
|
File Added: of-bug.C | |
2011-03-01 14:22 |
|
Assigned To | => user8 |
2011-03-01 14:22 |
|
Status | new => assigned |
2011-06-16 18:00 |
|
Note Added: 0000443 | |
2011-06-16 18:00 |
|
Status | assigned => closed |
2011-06-16 18:00 |
|
Resolution | open => fixed |
2011-07-20 17:05 |
|
Note Added: 0000578 | |
2011-07-20 17:05 |
|
Status | closed => resolved |
2011-07-20 17:05 |
|
Fixed in Version | => 2.0.x |