View Issue Details

IDProjectCategoryView StatusLast Update
0001459OpenFOAM[All Projects] Bugpublic2014-12-17 11:08
ReportertniemiAssigned Tohenry 
PrioritynormalSeverityminorReproducibilitysometimes
Status resolvedResolutionfixed 
Product Version 
Fixed in Version 
Summary0001459: Particle tracking hangs sometimes in particle::trackToFace
DescriptionI 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.
TagsNo tags attached.

Activities

henry

2014-12-12 11:48

manager   ~0003306

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

tniemi

2014-12-12 13:09

reporter   ~0003308

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.

tniemi

2014-12-16 12:41

reporter  

problem.png (33,152 bytes)
problem.png (33,152 bytes)

tniemi

2014-12-16 12:41

reporter  

cell.png (7,501 bytes)
cell.png (7,501 bytes)

tniemi

2014-12-16 12:41

reporter  

cell2.png (7,269 bytes)
cell2.png (7,269 bytes)

tniemi

2014-12-16 12:43

reporter   ~0003322

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.

henry

2014-12-16 14:45

manager   ~0003323

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.

henry

2014-12-16 20:49

manager   ~0003324

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.

tniemi

2014-12-17 10:39

reporter   ~0003325

No hang ups after patch, so this issue is likely resolved. Thanks.

henry

2014-12-17 11:08

manager   ~0003326

Thanks for the bug-report, analysis and proposed fix.

Resolved by commit 867858f550d5571ae91d03da733fc83b129d25c4

Issue History

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