dynamicOversetFvMesh with displacementLaplacian/velocityLaplacian does not preserve zeroGradient on overset patches
Summary
Steps to reproduce
The bug can be observed by making a minor modification to $FOAM_TUTORIALS/incompressible/overPimpleDyMFoam/cylinder
:
- Change the boundary condition for the
walls
patch incylinderAndBackground/0/pointDisplacement
to-
walls { type oscillatingDisplacement; amplitude (1 0 1); omega 3.14; value uniform (0 0 0); }
-
I have attached this case (bug.cylinder.displacementLaplacian.tgz) below.
Incorrect behaviour can also be produced using the velocityLaplacian motion solver on this case instead of the displacementLaplacian solver; to reproduce this behaviour, make the following modifications to the same cylinder
case:
- rename
cylinderAndBackground/0/pointDisplacement
tocylinderAndBackground/0/pointMotionU
- In the header of
cylinderAndBackground/0/pointMotionU
, update theobject
tocellMotionU
- In
cylinderAndBackground/0/pointMotionU
, change thewalls
boundary condition to:-
walls { type fixedValue; value uniform (1 0 1); }
-
- In
cylinderAndBackground/constant/dynamicMeshDict
, replacedisplacementLaplacian
withvelocityLaplacian
- In
cylinderAndBackground/system/fvSolution
, replacecellDisplacement
withcellMotionU
I have also attached this case (bug.cylinder.velocityLaplacian.tgz) below.
Example case
As noted above, here are the two cases:
What is the current bug behaviour?
As the mesh boundary condition for the overset patch is zeroGradient
(overset { patchType overset; type zeroGradient; }
), I expect the overset mesh region around the cylinder to rigidly translate over the background mesh. However, in the two cases above, you will see that the overset mesh patch is not acting as zeroGradient
. For the displacementLaplacian case, it seems to act as zero fixedValue
, whereas, for the velocityLaplacian case, it seems to act as a normal overset patch (i.e. coupled to the background mesh).
As a result, in both cases, the simulation crashes due to extreme mesh deformations in the overset region.
What is the expected correct behavior?
The expected behaviour in both cases is that the overset mesh region rigidly translates over the background mesh and the background mesh does not move.
Relevant logs and/or images
Here is an image of the mesh just before crashing in the displacementLaplacian case, where the overset patch mesh condition seems to act like fixedValue
:
Here is an image of the mesh just before crashing in the velocityLaplacian case, where the overset patch mesh condition seems to act like a normal overset
condition:
With the user-fix proposed below, the correct behaviour is observed for both cases:
Environment information
- OpenFOAM version : v2212
- Operating system : I have chedk ubuntu and macOS but it should be the same on all OSes
- Hardware info : N/A
- Compiler : I checked gcc (on Ubuntu) and clang (on macOS) but it should be independent of the compiler
Possible fixes
The problem seems to come from the construction of the boundary conditions for the cellDisplacement
field in the displacementLaplacian class and the cellMotionU
field in the velocityLaplacian class. The zeroGradient
condition on the overset mesh patch does not seem to be correctly copied from the pointDisplacement
and pointMotionU
fields.
A simple user workaround is to provide the cell mesh motion fields in the case, including the correct boundary conditions on the overset patch. These user-provided fields are used because the cell fields are READ_IF_PRESENT
in the displacementLaplacian and velocityLaplacian motion solvers.
For example, to fix the displacementLaplacian
case, add the following cellDisplacement
file to cylinderAndBackground/0/
:
FoamFile
{
version 2.0;
format ascii;
class volVectorField;
object cellDisplacement;
}
dimensions [0 1 0 0 0 0 0];
internalField uniform (0 0 0);
boundaryField
{
overset
{
patchType overset;
type zeroGradient;
}
walls
{
type cellMotion;
value uniform (0 0 0);
}
".*"
{
type uniformFixedValue;
uniformValue (0 0 0);
}
}
Similarly, to fix the velocityLaplacian
case, add the following cellMotionU
file to cylinderAndBackground/0/
:
FoamFile
{
version 2.0;
format ascii;
class volVectorField;
object cellMotionU;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
dimensions [0 1 0 0 0 0 0];
internalField uniform (0 0 0);
boundaryField
{
overset
{
patchType overset;
type zeroGradient;
}
walls
{
type cellMotion;
value uniform (0 0 0);
}
".*"
{
type uniformFixedValue;
uniformValue (0 0 0);
}
}
Here are the two modified cases:
This user fix is a simple workaround; however, it would be better if this was fixed within the code, such that zeroGradient
conditions on overset patches are correctly mapped from point fields to cell fields.