View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003712 | OpenFOAM | Bug | public | 2021-08-13 22:25 | 2021-08-18 14:41 |
| Reporter | peksa | Assigned To | will | ||
| Priority | normal | Severity | minor | Reproducibility | sometimes |
| Status | resolved | Resolution | fixed | ||
| Platform | Linux | OS | Centos | OS Version | 7 |
| Product Version | dev | ||||
| Fixed in Version | dev | ||||
| Summary | 0003712: Infinite loop in lagrangian move function due to stuck parcels | ||||
| Description | I have experienced that sometimes my lagrangian spray simulations (reactingFoam / old sprayFoam) hang during the lagrangian computation step. In particular, this seems to take place when Foam::particle::trackToFace() function yields a warning ""Particle #" << origId_ << " got stuck at " << position()". Typically this kind of stuck parcel near the domain boundary tells that your simulation may have other issues but I believe the solver should not result in an infinite loop behavior but at least result in an error after some time of unsuccesfull iteration. To shed some more light on the topic, I utilised recent OpenFOAM-dev (git-rev 41b73ec5788a29f4d1928482c635db6cbe7d8dfe) to debug and present this issue by building a simple spray case (see link below). The case is not the "most proper" from CFD quality stand point in terms ofmesh, injector is close to the boundary and flow solver / numerics setup is just exemplary. The objective is to just achieve a reproducible example. This example case results in a hanging situation after a few time steps. I have debugged this to make a conclusion that there is no break-up in the while loop of the Foam::MomentumParcel<ParcelType>::move() function because p.stepFactor() yields a constant number below unity. stepFactor is not achieving unity due to a stucking parcel indicated by the p.trackToFace() function, which also updates the stepFactor. To me this is not a bug per'se because it appears probably only due to an ill-conditioned CFD setup. However, I'd like to propose that we could add a maximum number of iteration to the while loop (e.g. 10000) after which an error is introduced and solver exits properly. | ||||
| Steps To Reproduce | Download a ready case (~100MB with an existing time step data for a restart to minimize run-time) https://1drv.ms/u/s!AnmySzLmJFhRgohF-qySTppCRcWEzA?e=6JJmoc Extract the spray_hanging_issue_tracker.tar.gz run by executing "reactingFoam" (will start from the latest time folder which is included). Lagrangian solver "hangs" in few time steps. | ||||
| Tags | No tags attached. | ||||
|
|
I agree that it would be better to exit with an error than to hang. The problem with counters is that for them to work properly, they have to be stored as data on the particle. Otherwise any infinite loop situation which crosses a processor boundary won't be broken, as the counter will be reset on each crossing. Adding particle data has a performance penalty. Is it worth making correct cases less efficient in order to improve the failure modes of incorrect cases? Also, the number is completely arbitrary. You suggest 10000, but if we are doing steady tracking or creating long streamlines, is that enough? If not, what is? So, no, I don't see a convincing argument for adding a counter. What I can do is catch the failure modes demonstrated in this case so that they error, rather than hang. This case fails for two reasons... Firstly, because a parcel hits a wall for which no patch interaction has been specified. This is not valid. I have added a error to stop the code if this situation is detected. Secondly, if I add a rebound interaction, the case fails because it is diverging. The velocity increases to 10^15-ish, and the CFL limiter then sets a step fraction which is below round off error. As such, the particle never evolves. I have limited the CFL limiter so that this does not happen. Now in your case, Lagrangian spits a lot of "stuck" warnings, but completes without failure, and it is the subsequent finite volume solution that then fails. With these changes I consider the issue demonstrated by your case to be resolved. https://github.com/OpenFOAM/OpenFOAM-dev/commit/08d6791d81d4ab7d7b54933006417cf52f9e1558 |
