View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001459 | OpenFOAM | Bug | public | 2014-12-12 09:57 | 2014-12-17 11:08 |
Reporter | tniemi | Assigned To | henry | ||
Priority | normal | Severity | minor | Reproducibility | sometimes |
Status | resolved | Resolution | fixed | ||
Summary | 0001459: Particle tracking hangs sometimes in particle::trackToFace | ||||
Description | I have encountered a couple of cases where lagrangian particle tracking suddenly hangs. (solver MPPICFoam) With gdb I managed to isolate the problem to Foam::particle::trackToFace function, where the code gets stuck. I didn't use a debug build, so I don't know all the details. However, the only way I can see this happening is that the code is stuck in the do-while loop. Unfortunately, I don't have a suitable mesh to attach to this report and the problem is not easily reproducible as it happens only occasionally. However, the meshes I have used were made with snappy and passed the default quality criteria (eg. minTetQuality=1e-15). I was wondering would it be possible to add some sort of an additional tracking rescue, or loop limit to the trackToFace, so that it would abort the do-while after some reasonable amount of trying? I can try to get a better picture with a debug build, when I have time. However, with the debug build I'm having a problem with the line MPPICCloud.C:292, const scalar nPack = n*alphaMax/alpha()[cellI];. If n=0, then alpha()[cellI] is also 0, which gives 0/0. With normal build this works (I guess it gives -nan), but I think there should be a check for this case, as it is very typical. | ||||
Tags | No tags attached. | ||||
|
I have just pushed a fix for the n=0 case in MPPICCloud.C but the issue with the tracking is a general problem which needs a general solution. Could you check your mesh for negative-volume tets using checkMesh -allGeometry |
|
No negative-volume tets, but some warped faces and faces with concave angles, so the quality of the meshes should probably be improved. However, the meshes have passed the default snappy quality checks and fluid solution works ok. |
|
|
|
|
|
|
|
I've now managed to get a debug simulation to hang. What happens is that the particle endPosition seems to be a point, for which the findTris finds a triangle for neighboring tets. So the particle keeps on switching tets and never escapes the loop, even though it has reached endPosition, because tris.empty() is false every time. Tracking rescue doesn't help, because position_ == endPosition and tetLambda returns GREAT from line 128. I don't understand the tracking algorithm very well, but is there a reason why we can't escape the do-while loop after hitting lines 514 and 516? I guess usually it doesn't hurt to go through the loop, as we should be able to escape at line 414, but in this case it causes the hang issue. Anyway I have attached pictures of the mesh and the problematic cell. In this case the mesh is quite ugly, as the layer addition has gone bad, so maybe one needs to have a bad mesh to hit this issue. However, the cell itself doesn't look entirely horrible. |
|
I agree, for this particular case it would be better to return 1 after line 516 rather than wait until line 414. Could you test this change on your case? I will test it on some case here. We are working on a more robust tracking algorithm which handles these ill-posed cases better and also handles negative-volume tets without the need for ad hoc recovery schemes. However, this is a substantial undertaking and will take a lot of development and testing time before it is ready to replace the current algorithm. |
|
I have pushed this change following testing here. Let me know if this change resolves the problems you are experiencing and I will close this report. |
|
No hang ups after patch, so this issue is likely resolved. Thanks. |
|
Thanks for the bug-report, analysis and proposed fix. Resolved by commit 867858f550d5571ae91d03da733fc83b129d25c4 |
Date Modified | Username | Field | Change |
---|---|---|---|
2014-12-12 09:57 | tniemi | New Issue | |
2014-12-12 11:48 | henry | Note Added: 0003306 | |
2014-12-12 13:09 | tniemi | Note Added: 0003308 | |
2014-12-16 12:41 | tniemi | File Added: problem.png | |
2014-12-16 12:41 | tniemi | File Added: cell.png | |
2014-12-16 12:41 | tniemi | File Added: cell2.png | |
2014-12-16 12:43 | tniemi | Note Added: 0003322 | |
2014-12-16 14:45 | henry | Note Added: 0003323 | |
2014-12-16 20:49 | henry | Note Added: 0003324 | |
2014-12-17 10:39 | tniemi | Note Added: 0003325 | |
2014-12-17 11:08 | henry | Note Added: 0003326 | |
2014-12-17 11:08 | henry | Status | new => resolved |
2014-12-17 11:08 | henry | Resolution | open => fixed |
2014-12-17 11:08 | henry | Assigned To | => henry |