View Issue Details

IDProjectCategoryView StatusLast Update
0002514OpenFOAM[All Projects] Bugpublic2017-03-29 23:25
ReporterphicauAssigned Tohenry 
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
PlatformGNU/LinuxOSUbuntuOS Version15.04
Product Version 
Fixed in Version4.x 
Summary0002514: movingWallVelocity BC not working in parallel
DescriptionIn this case, water movement is driven by a moving boundary (at X=0, with oscillatingDisplacement BC). The rest of the boundaries are walls and the atmosphere.

The mesh moves without trouble in serial and parallel. However, water is only reacting to that movement in the serial case. In parallel, only small velocities appear at the interface.

Differences can be noticed as early as the first time step.
Steps To ReproduceSerial case:

blockMesh
cp -r 0.org 0
setFields
interDyMFoam


Parallel case:

blockMesh
cp -r 0.org 0
setFields
decomposePar
mpirun -np 2 interDyMFoam -parallel
Additional InformationI have also tried different decomposition methods (scotch, simple) and number of processors (2, 4), with the same issue arising.
TagsNo tags attached.

Activities

phicau

2017-03-29 10:33

reporter  

interDyMFoamFailure.tar.gz (3,489 bytes)

henry

2017-03-29 10:42

manager   ~0007986

Could you please test with OpenFOAM-4.x or better still OpenFOAM-dev.

phicau

2017-03-29 10:52

reporter   ~0007987

Currently I do not have 4.x installed, but the problem persists in v4.0

henry

2017-03-29 11:06

manager   ~0007988

Check the p_rgh BCs; compare with similar tutorials like floatingObject or sloshingTank.*

phicau

2017-03-29 12:47

reporter   ~0007989

fixedFluxPressure used in all the walls, as in the floatingObject tutorial

henry

2017-03-29 13:41

manager   ~0007991

Does the mesh have to be so huge and fine to demonstrate the problem or does it only occur with this level of refinement?

will

2017-03-29 22:43

manager   ~0007994

faceOnlySet::calcSamples sets the mesh to stationary so that the internal tracking it uses isn't affected by the mesh motion. It doesn't set the motion active again on one of it's return paths.

A possible fix is as follows, though we probably want to find a way of controlling post-processing tracking like this without const_cast-ing the mesh...

diff --git a/src/sampling/sampledSet/face/faceOnlySet.C b/src/sampling/sampledSet/face/faceOnlySet.C
index 9dbeee3db..0f2dbe433 100644
--- a/src/sampling/sampledSet/face/faceOnlySet.C
+++ b/src/sampling/sampledSet/face/faceOnlySet.C
@@ -166,6 +166,7 @@ void Foam::faceOnlySet::calcSamples
         // Pout<< "calcSamples : Both start_ and end_ outside domain"
         // << endl;
 
+ const_cast<polyMesh&>(mesh()).moving(oldMoving);
         return;
     }

henry

2017-03-29 22:59

manager   ~0007995

Yes I also traced the problem to faceOnlySet, and there is another occurrence of the same issue. I am testing the fix and will push shortly.

henry

2017-03-29 23:25

manager   ~0007996

Resolved in OpenFOAM-4.x by commit 56a4152a9309af1771db0758c6f4119c0e7316d2

Resolved in OpenFOAM-dev by commit 54506f8307ed615b21707964129b6ff36daf58df

Issue History

Date Modified Username Field Change
2017-03-29 10:33 phicau New Issue
2017-03-29 10:33 phicau File Added: interDyMFoamFailure.tar.gz
2017-03-29 10:42 henry Note Added: 0007986
2017-03-29 10:52 phicau Note Added: 0007987
2017-03-29 11:06 henry Note Added: 0007988
2017-03-29 12:47 phicau Note Added: 0007989
2017-03-29 13:41 henry Note Added: 0007991
2017-03-29 22:43 will Note Added: 0007994
2017-03-29 22:59 henry Note Added: 0007995
2017-03-29 23:25 henry Assigned To => henry
2017-03-29 23:25 henry Status new => resolved
2017-03-29 23:25 henry Resolution open => fixed
2017-03-29 23:25 henry Fixed in Version => 4.x
2017-03-29 23:25 henry Note Added: 0007996