[gtg258f]

Dear all,

I running a simulation with a moving mesh an periodic boundary conditions. For the mesh motion I am using the moveMesh method from elasticNonLinULSolidFoam.

After a few iterations, the code crashes because the periodic patches have moved by a different amount. While I understand that this mismatch makes the code crash, I was wondering why it happens, since I thought that cyclic patches would have the same displacement field.

face 14 area does not match neighbour 29 by 0.0145797% -- possible face ordering problem.
patch:XPERIODIC my area:0.0209228 neighbour area:0.0209197 matching tolerance:0.0001

Looking into the code, I was wondering if the problem could come from performEdgeCorrectedVolPointInterpolation.H
I see that there is a part in there about coupled boundaries that is commented out.

From what I understand (but I could be really wrong), the displacement field at the boundary points is extrapolated from the internal field gradient (gradDU). For cyclic boundaries, should the displacement field in coupled patches (say patch 1 and 2) be computed as a mean of the extrapolations on patch 1 and patch 2? Should I uncomment the following lines?

[CODE]
// Update coupled boundaries
/*
forAll (pfCorr.boundaryField(), patchI)
{
if (pfCorr.boundaryField()[patchI].coupled())
{
pfCorr.boundaryField()[patchI].initAddField();
}
}
forAll (pfCorr.boundaryField(), patchI)
{
if (pfCorr.boundaryField()[patchI].coupled())
{
pfCorr.boundaryField()[patchI].addField(pfCorr.internalField());
}
}
*/


Cheers,
Diane

[ngj]

Hi Diane,

I am facing the same problem, and as far as I have found out, the reason is the following:

1. If you are using the mesh motion, which solves in the finite volume sense (the methods that come with the OpenCFD releases), then the motion is computed for the cell centres, and the motion is subsequently interpolated to the internal points and extrapolated to the boundary points. This extrapolation, however, does not take the nature of the boundaries into consideration, and the mesh motion on the cyclic patches are not enforced to be identical.

2. If you want to try to solve for the mesh motion using the tetFem-decomposition technique, then you will find that no such thing as a cyclic boundary condition exists (at least up to the most recent update I have of the OF-1.6-ext framework).

Unfortunately, I do not have any quick solution for you, and it seems to require a substantial programming effort to make a solution, which work inside the OF-framework, but you might be able to come up with a hack, but the hack needs to be placed in the mesh motion library before the patch-check for cyclic boundaries is conducted.

Good luck,

Niels

[levka]

hi guys,
i am trying to apply cyclic BC to the domain with mesh motion and can not succeed.
Mesh solver (Laplaciancomponent or Displacement) works wonderful with the same domain but when inlet and outlet are some fixed values or zero gradients. But when i change them to cyclic with help of CreatePatch utility mesh solver starts working not corrected. I explain correct - when only object inside domain moves; non correct - when whole domain moves...

Any hit is much appreciated