View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002376 | OpenFOAM | Patch | public | 2016-12-06 18:36 | 2018-07-10 11:15 |
Reporter | DustExplosion | Assigned To | henry | ||
Priority | low | Severity | major | Reproducibility | always |
Status | closed | Resolution | suspended | ||
Platform | GNU/Linux | OS | Ubuntu | OS Version | 14.04 |
Fixed in Version | dev | ||||
Summary | 0002376: Lagrange particles do not move on a mesh with micrometric resolution | ||||
Description | As stated in the summary, Lagrange particles were not moving on a high resolution 1 dimensional mesh. Note that the particle size is smaller than the grid resolution, but the cells also have a ~5:1 aspect ratio. I followed the tetAreas renormalization in trackToFace suggested in this thread https://www.cfd-online.com/Forums/openfoam-programming-development/123442-documentation-tracktoface-subroutine.html and that seems to fix the problem. However, I also see particles having problems leaving the outflow boundary (they get stuck at the outflow). I do not currently have a test case or fix for this. | ||||
Steps To Reproduce | Run the attached test case with coalChemistryFoam | ||||
Tags | No tags attached. | ||||
|
|
|
Have you tested the proposed changes on a range of cases? I see some serious inconsistencies with the tracking functions in particleI.H: if (mag((to - from)) < tol/mag(n)) { // 'Zero' length track (compared to the tolerance, which is // based on the cell volume, divided by the tet face area), not // along the face, face cannot be crossed. return GREAT; } and as far as I can see support for moving meshes would be totally compromised: n0 = tet0.Sa(); . . . vector dN = n - n0; here n and n0 would be completely inconsistent. Before such a fundamental change could be make it is essential that a wide range of cases are tested, different sizes, different meshes, different physics and mesh motion. |
|
No I have not tested it across other cases, so that is a good point. Unless you can see an easy way to fix it and maintain consistency, it might make sense to drop it. It is not a common problem and their are forms explaining an (apparently incomplete but working!) solution. |
|
The proposed patch is fundamentally incorrect; even the dimensions of the comparison tests would be incorrect and I expect that many if not most Lagrangian cases which currently work would fail. Clearly there is an issue with the tracking on very small cases but having studied the code and behavior of the proposed patch I am convinced that the issue is not these functions but elsewhere in the code and it just happens that the issue is not triggered if the tolerance checking is compromised by this patch. I would be very helpful if someone could analyse the issue further and provide a correct patch which is formally correct and works at least on all the current tutorial cases as well as cases with very small geometry. |
|
Pending a corrected patch. |
Date Modified | Username | Field | Change |
---|---|---|---|
2016-12-06 18:36 | DustExplosion | New Issue | |
2016-12-06 18:36 | DustExplosion | File Added: SingleParticleInFlame.tar.gz | |
2016-12-06 18:36 | DustExplosion | Tag Attached: #Lagrange #trackToFace | |
2016-12-06 22:18 | henry | Note Added: 0007424 | |
2016-12-07 14:00 | DustExplosion | Note Added: 0007426 | |
2016-12-07 14:21 | henry | Note Added: 0007427 | |
2016-12-08 15:09 | henry | Assigned To | => henry |
2016-12-08 15:09 | henry | Status | new => closed |
2016-12-08 15:09 | henry | Resolution | open => suspended |
2016-12-08 15:09 | henry | Fixed in Version | => dev |
2016-12-08 15:09 | henry | Note Added: 0007430 | |
2018-07-10 11:15 | administrator | Tag Detached: #Lagrange #trackToFace |