View Issue Details

IDProjectCategoryView StatusLast Update
0001424OpenFOAM[All Projects] Bugpublic2014-11-10 14:03
ReporterAlmostSurelyRobAssigned Touser4 
PriorityhighSeveritycrashReproducibilityalways
Status resolvedResolutionfixed 
PlatformLinuxOSArch LinuxOS Versionkernel 3.16
Product Version 
Fixed in Version 
Summary0001424: pointLinear scheme breaks in parallel
DescriptionI 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 ReproducePlease 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 InformationI 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.
TagsNo tags attached.

Activities

user1015

2014-10-28 05:06

  ~0003266

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

AlmostSurelyRob

2014-10-28 11:06

reporter   ~0003269

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.

user4

2014-10-28 12:02

  ~0003270

It is now handling the processor boundaries consistent with internal faces

Fixed in 55f669e302ba2b7166c19ee92f036e20484143d7

user4

2014-10-31 16:56

  ~0003275

By the way,

    polyDualMesh 45

converts your mesh nicely into polyhedra. Would probably allow you to use less diffusive schemes.

Issue History

Date Modified Username Field Change
2014-10-27 09:40 AlmostSurelyRob New Issue
2014-10-28 05:06 user1015 Note Added: 0003266
2014-10-28 11:06 AlmostSurelyRob Note Added: 0003269
2014-10-28 12:02 user4 Note Added: 0003270
2014-10-28 12:02 user4 Status new => resolved
2014-10-28 12:02 user4 Fixed in Version => 2.3.x
2014-10-28 12:02 user4 Resolution open => fixed
2014-10-28 12:02 user4 Assigned To => user4
2014-10-31 16:56 user4 Note Added: 0003275