View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001424 | OpenFOAM | Bug | public | 2014-10-27 09:40 | 2014-11-10 14:03 |
| Reporter | AlmostSurelyRob | Assigned To | |||
| Priority | high | Severity | crash | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | Linux | OS | Arch Linux | OS Version | kernel 3.16 |
| Summary | 0001424: pointLinear scheme breaks in parallel | ||||
| Description | I am trying to find a good numerical setup for Delaunay type mesh. I am validating it with a simple, steady state pipe flow. After many trials pointLinear interpolation turned out to be effective at not diffusing the result. The centerline value of parabolic profile remains relatively constant. Unfortunately, when I run with this scheme in parallel I see large discontinuities appearing at processor domain boundaries. These discontinuities grow and eventually crash the simulation. This doesn't seem to be system related. The same error occurred on OpenSUSE of a colleague of mine. I think pointLinear scheme is a very promising way for OpenFOAM to deal with tet meshes. Parallel runs for tet meshes are a necessity as the number of these cells grows very quickly for complex geometries. | ||||
| Steps To Reproduce | Please use the case I uploaded here https://dl.dropboxusercontent.com/u/13129740/DelaunayPipe.tar.gz decomposePar mpirun -np 4 simpleFoam -parallel Finally run sample -latestTime and visualise the centerline velocity The discontinuities begin to appear around step 200. By 500 they're huge. | ||||
| Additional Information | I have originally reported the issue here http://www.cfd-online.com/Forums/openfoam-solving/143382-too-diffusive-result-delaunay-type-mesh-pipe.html It was suggested there that mappings for point classes may be faulty. | ||||
| Tags | No tags attached. | ||||
|
|
We think have found a problem with the faceToPointInterpolate function at cyclic and processor boundaries (perhaps other derivatives of the coupledFvPatchField class as well) - see the bug report after yours (1425). faceToPointInterpolate apparently does not take account of field values from the neighboring patch. If I am correct you will find that the field values at points on the two patches (processor0 and processor1 for example) are different, while the average is the same as the serial version (at least initially). Note it is the values at the points that are wrong - the cell values are calculated correctly as far as we can tell. Tony |
|
|
Thanks Tony - yes it may be related. According to this commit https://github.com/OpenCFD/OpenFOAM-1.7.x/commit/ddd01afa4115b936f76e588e882918f2e1bb7904 pointLinear approximates from cell centres to vertices and from vertices to face centres, so the bug you mentioned will cause at least one step to go awry. I prepared a little video which shows how magnitude of velocity gradually becomes different on both sides of a processor domain. https://dl.dropboxusercontent.com/u/13129740/velocityOnProcessorBoundaries.avi The evil starts around iteration 60. |
|
|
It is now handling the processor boundaries consistent with internal faces Fixed in 55f669e302ba2b7166c19ee92f036e20484143d7 |
|
|
By the way, polyDualMesh 45 converts your mesh nicely into polyhedra. Would probably allow you to use less diffusive schemes. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2014-10-27 09:40 | AlmostSurelyRob | New Issue | |
| 2014-10-28 05:06 |
|
Note Added: 0003266 | |
| 2014-10-28 11:06 | AlmostSurelyRob | Note Added: 0003269 | |
| 2014-10-28 12:02 |
|
Note Added: 0003270 | |
| 2014-10-28 12:02 |
|
Status | new => resolved |
| 2014-10-28 12:02 |
|
Fixed in Version | => 2.3.x |
| 2014-10-28 12:02 |
|
Resolution | open => fixed |
| 2014-10-28 12:02 |
|
Assigned To | => user4 |
| 2014-10-31 16:56 |
|
Note Added: 0003275 |
