View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001424||OpenFOAM||[All Projects] Bug||public||2014-10-27 09:40||2014-11-10 14:03|
|Platform||Linux||OS||Arch Linux||OS Version||kernel 3.16|
|Fixed in Version|
|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|
mpirun -np 4 simpleFoam -parallel
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|
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.
Thanks Tony - yes it may be related. According to this commit
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.
The evil starts around iteration 60.
It is now handling the processor boundaries consistent with internal faces
Fixed in 55f669e302ba2b7166c19ee92f036e20484143d7
By the way,
converts your mesh nicely into polyhedra. Would probably allow you to use less diffusive schemes.
|2014-10-27 09:40||AlmostSurelyRob||New Issue|
||Note Added: 0003266|
|2014-10-28 11:06||AlmostSurelyRob||Note Added: 0003269|
||Note Added: 0003270|
||Status||new => resolved|
||Fixed in Version||=> 2.3.x|
||Resolution||open => fixed|
||Assigned To||=> user4|
||Note Added: 0003275|