View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002514 | OpenFOAM | Bug | public | 2017-03-29 10:33 | 2017-03-29 23:25 |
| Reporter | phicau | Assigned To | henry | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | GNU/Linux | OS | Ubuntu | OS Version | 15.04 |
| Summary | 0002514: movingWallVelocity BC not working in parallel | ||||
| Description | In 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 Reproduce | Serial 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 Information | I have also tried different decomposition methods (scotch, simple) and number of processors (2, 4), with the same issue arising. | ||||
| Tags | No tags attached. | ||||
|
|
|
|
|
Could you please test with OpenFOAM-4.x or better still OpenFOAM-dev. |
|
|
Currently I do not have 4.x installed, but the problem persists in v4.0 |
|
|
Check the p_rgh BCs; compare with similar tutorials like floatingObject or sloshingTank.* |
|
|
fixedFluxPressure used in all the walls, as in the floatingObject tutorial |
|
|
Does the mesh have to be so huge and fine to demonstrate the problem or does it only occur with this level of refinement? |
|
|
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; } |
|
|
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. |
|
|
Resolved in OpenFOAM-4.x by commit 56a4152a9309af1771db0758c6f4119c0e7316d2 Resolved in OpenFOAM-dev by commit 54506f8307ed615b21707964129b6ff36daf58df |
| 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 |
