CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Running, Solving & CFD

Abnormal result of dynamic mesh motion at the between bottom and side boundary.

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   June 17, 2020, 21:39
Default Abnormal result of dynamic mesh motion at the between bottom and side boundary.
  #1
New Member
 
Chaewoong Ban
Join Date: Jun 2013
Posts: 18
Rep Power: 11
blue8803 is on a distinguished road
I'm trying to solve Exner equation (mass conservation equation of sediment phase) using FAM and mesh move is implemented using dynamic mesh motion. My test case is U-shape open channel flow composed of bottom wall (patch name: bed), side wall (patch name:sidewall), inlet, outlet. First, only flow is simulated until flow is fully developed (it is not problem). After that, turn on my implemented code, morphological changes start. At the beginning, it seems good, but some time later problem occur at the vicinity of the sidewall near the bed (please refer to attached picture). It seems that the sidewall is correctly moved in the mesh motion stage. What causes the problem..?
Thank you for any questions or answers!

Here is boundary condition for motionU.

dimensions [0 1 -1 0 0 0 0];

internalField uniform (0 0 0);

boundaryField
{
inlet
{
type fixedValue;
value uniform (0 0 0);
}
outlet
{
type fixedValue;
value uniform (0 0 0);
}
sidewall
{
type slip;
value uniform (0 0 0);
} /// I think it is right..

bed
{
type fixedValue;
value uniform (0 0 0);
}
atmosphere
{
type fixedValue;
value uniform (0 0 0);
}
}




I'm now suspicious of relTol....



solvers
{
motionU
{
solver PCG;
preconditioner DIC;
tolerance 1e-09;
relTol 0.001;
}
}






In the dictionary file dynamicMeshDict, what means the twoDMotion??


dynamicFvMeshLibs ("libdynamicTopoFvMesh.so");

//- Select the type of dynamicFvMesh
dynamicFvMesh dynamicMotionSolverFvMesh; //dynamicTopoFvMesh;

twoDMotion yes;

//- Select the type of motionSolver
//solver laplace;
/*
RBFMotionSolver /dynamicMeshDict/movingPatches
displacementComponentLaplacian
displacementInterpolation /dynamicMeshDict/displacementInterpolationCoeffs
displacementLaplacian /0/pointDisplacement
displacementSBRStress /0/pointDisplacement
laplace
mesquiteMotionSolver /dynamicMeshDict/mesquiteMotionSolver
pseudoSolid /dynamicMeshDict/pseudoSolid
refVelocityLaplacian /0/pointMotionU
velocityComponentLaplacian
velocityLaplacian /0/pointMotionU
*/
solver laplace;
diffusivity quadratic inverseDistance;

distancePatches 1 (bed);

frozenDiffusion off;

//





I reseachred some source code but,, i didn't reach understanding.


src/dynamicMesh/dynamicMesh/motionsolver/motionSolver.H
// Member Functions
//- Return true for 2-D motion
bool twoDMotion() const
{
return twoDPointCorrector_.required();
}


src/meshTools/twoDPointCorrector/twoDPointCorrector.C
/*Description
Class applies a two-dimensional correction to mesh motion point field.
The correction guarantees that the mesh does not get twisted during motion
and thus introduce a third dimension into a 2-D problem.*/


// * * * * * * * * * * * * * * * * Constructors * * * * * * * * * * * * * * //

twoDPointCorrector::twoDPointCorrector(const polyMesh& mesh)
:
mesh_(mesh),
required_(mesh_.nGeometricD() == 2), ///??????????????
planeNormalPtr_(nullptr),
normalEdgeIndicesPtr_(nullptr)
{}
Attached Images
File Type: jpg Screenshot from 2020-06-18 12-29-15.jpg (139.0 KB, 18 views)
File Type: jpg Screenshot from 2020-06-18 12-28-49.jpg (176.7 KB, 19 views)

Last edited by blue8803; June 18, 2020 at 03:35.
blue8803 is offline   Reply With Quote

Old   June 18, 2020, 06:19
Default
  #2
Senior Member
 
Santiago Lopez Castano
Join Date: Nov 2012
Posts: 354
Rep Power: 14
Santiago is on a distinguished road
which solver is this?
Santiago is offline   Reply With Quote

Old   June 19, 2020, 08:30
Default
  #3
New Member
 
Chaewoong Ban
Join Date: Jun 2013
Posts: 18
Rep Power: 11
blue8803 is on a distinguished road
I used the solver I made based on the interDyMFoam or pimpleDyMFoam.
blue8803 is offline   Reply With Quote

Old   June 19, 2020, 08:58
Default
  #4
Senior Member
 
Santiago Lopez Castano
Join Date: Nov 2012
Posts: 354
Rep Power: 14
Santiago is on a distinguished road
Quote:
Originally Posted by blue8803 View Post
src/meshTools/twoDPointCorrector/twoDPointCorrector.C
/*Description
Class applies a two-dimensional correction to mesh motion point field.
The correction guarantees that the mesh does not get twisted during motion
and thus introduce a third dimension into a 2-D problem.*/


// * * * * * * * * * * * * * * * * Constructors * * * * * * * * * * * * * * //

twoDPointCorrector::twoDPointCorrector(const polyMesh& mesh)
:
mesh_(mesh),
required_(mesh_.nGeometricD() == 2), ///??????????????
planeNormalPtr_(nullptr),
normalEdgeIndicesPtr_(nullptr)
{}
I think the description of the class is rather clear: the grid nodes will not twist for a 2D problem.

The statement:

Code:
 mesh_.nGeometricD() == 2
Is asking whether the GRID is 2D. Obviously the 2D correction algorithm doesnt make much sense in 3D grids, specially in bed erosion problems. I assume you are following Xiafeng Liu's work then, unless you are running a 2D case (where you have wedges/empty patches), setting
Code:
twoDMotion yes;
is not correct.

The motion solver seems correct to me, not very convinced of you BCs for motionU but, in order for me to give you an informed opinion, I need to see the implementation of the finiteArea model + the faMesh...
Santiago is offline   Reply With Quote

Old   June 22, 2020, 01:59
Default
  #5
New Member
 
Chaewoong Ban
Join Date: Jun 2013
Posts: 18
Rep Power: 11
blue8803 is on a distinguished road
Quote:
Originally Posted by Santiago View Post
I think the description of the class is rather clear: the grid nodes will not twist for a 2D problem.

The statement:

Code:
 mesh_.nGeometricD() == 2
Is asking whether the GRID is 2D. Obviously the 2D correction algorithm doesnt make much sense in 3D grids, specially in bed erosion problems. I assume you are following Xiafeng Liu's work then, unless you are running a 2D case (where you have wedges/empty patches), setting
Code:
twoDMotion yes;
is not correct.

The motion solver seems correct to me, not very convinced of you BCs for motionU but, in order for me to give you an informed opinion, I need to see the implementation of the finiteArea model + the faMesh...
Many thanks for your reply.

This is the piece of my code.
Code:
(bedload calculation)
...
(solving Exner equation)
...


(solving mesh motion)

tetPointVectorField& motionU = 
const_cast<tetPointVectorField&>
(
  mesh.lookupObject<tetPointVectorField>
  (
    "motionU"
  )
);

fixedValueTetPolyPatchVectorField& motionUaPatch =
refCast<fixedValueTetPolyPatchVectorField>
(
  motionU.boundaryField()[aPatchID]
);

tetPolyPatchInterpolation tppiAPatch
(
  refCast<const faceTetPolyPatch>
  (
    motionUaPatch.patch()
  )
);

primitivePatchInterpolation patchInterpolator (mesh.boundaryMesh()[aPatchID]);
scalarField faceVal = patchInterpolator.faceToPointInterpolate(deltaH);

vectorField dH (Psize);
forAll(dH, i)
{
  dH[index].x() = 0;
  dH[index].y() = 0;
  dH[index].z() = faceVal[i];
}

motionUaPatch == tppiAPatch.pointToPointInterpolate (dH/mesh.time().deltaT().value());
//motionUaPatch == tppiAPatch.pointToPointInterpolate (dH);

meshChanged1 = mesh.update();
reduce(meshChanged1, orOp<bool>());

(sand-sliding)
...
(interFoam)
...
Also, I have tested some factors.
(i) relTol in dynamicMeshDict
0, 1e-3
(ii) diffusivity in dynamicMeshDict
inverseDistance, inverseFaceDistance, inversePointDistance with linear manipulator
inverseDistance, inverseFaceDistance, inversePointDistance with qudratic manipulator
(iii) twoDMotion in dynamicMeshDict
yes, no
In fact, there is no significant impact on final results considering above different factors..

Now I made a case rather simple. only one face are upward in constant motionU velocity (in code deltaH(somewhere on face) = 0.2), and found that at the sidewall upper layer of the cell moving upward converged each others (see picture).
blue8803 is offline   Reply With Quote

Old   June 22, 2020, 02:11
Default pic
  #6
New Member
 
Chaewoong Ban
Join Date: Jun 2013
Posts: 18
Rep Power: 11
blue8803 is on a distinguished road
I really don't know why they are converged
--------------------------------------
Attached Images
File Type: jpg InkedScreenshot from 2020-06-22 17-05-50_LI.jpg (154.3 KB, 15 views)
File Type: jpg Screenshot from 2020-06-22 17-11-41.jpg (172.7 KB, 20 views)
blue8803 is offline   Reply With Quote

Old   June 22, 2020, 05:01
Default I may narrow the resoans for problem
  #7
New Member
 
Chaewoong Ban
Join Date: Jun 2013
Posts: 18
Rep Power: 11
blue8803 is on a distinguished road
With turning off the sand-sliding features, mesh motion is works fine. However, I think it is not the problem of the sand-sliding model I made, but the iterative positive/negative values of motionU are the major reasons.
Because there is no steep slope that activate sand-sliding model in the first simulation (U-shape channel flow). So, i dig into this perspective
Attached Images
File Type: jpg Screenshot from 2020-06-22 19-39-34.jpg (115.7 KB, 12 views)
File Type: jpg Screenshot from 2020-06-22 19-39-42.jpg (115.7 KB, 11 views)
File Type: jpg Screenshot from 2020-06-22 19-39-44.jpg (116.5 KB, 12 views)
blue8803 is offline   Reply With Quote

Old   July 2, 2020, 05:46
Default (solved)
  #8
New Member
 
Chaewoong Ban
Join Date: Jun 2013
Posts: 18
Rep Power: 11
blue8803 is on a distinguished road
Many thanks.
blue8803 is offline   Reply With Quote

Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
[snappyHexMesh] Help with Snappy: no layers growing GianF OpenFOAM Meshing & Mesh Conversion 2 September 23, 2020 08:26
Difficulty in calculating angular velocity of Savonius turbine simulation alfaruk CFX 14 March 17, 2017 06:08
Gambit problems Althea FLUENT 22 January 4, 2017 03:19
Domain Imbalance HMR CFX 5 October 10, 2016 05:57
Solver error message!!! IoSa CFX 1 September 14, 2006 04:48


All times are GMT -4. The time now is 11:20.