interFoam has the ability to deal with moving boundary. I modified it to let one boundary move in a constant velocity(say 1cm/s). But the gamma equation seems don't like it. The gamma value at some point near the moving boundary becomes greater than one (like 1.6). That doesn't make any sense.

When I look at the code of interFoam, I didn't find any correction to gamma after the mesh is deformed. The change of control volume should affect the gamma values field. Maybe I am wrong.

Any suggestions?

You need to be careful with the velocity boundary type to get the correct behaviour from moving-mesh cases. gamma -> >1 indicates you are geting a continuity error. What BC on velocity are you using? If you are not already doing so try movingWallVelocity.

The differential operator in OpenFOAM include the effect of moving meshes so standard transport equations do not need any special correction terms.

[liu]

I used movingWallVelocity. But still got problem.
The gamma value is great than one.

I copied the movingInkJetFvMesh class and modified it to let one boundary to have non-uniform deformation.

You can get the source file and test case from:
https://netfiles.uiuc.edu/liu19/OpenFoam/

The document said the interFoam has the ability to deal with moving mesh. Is there any example case to show that? I think the movingInkJetFvMesh and movingPinFvMesh must be used somewhere.

[liu]

The deformation velocity on the bottom is sinusodal. The amplitude is 0.01m/s(That means the maximum deformation velocity on the bottom).
What even worse is that when I increase the amplitude to 0.05m/s, the motion solver said the solution is sigularity. But the interFoam is still running and the mesh seems still valid.

[alajbegovic]

I have a problem running interFoam and rasInterFoam after installing OpenFoam 1.2. When I run interFoam I get

Liquid phase volume fraction = 0 Min(gamma) = 0 Max(gamma) = 0

It appears that the liquid phase is initialized to zero everywhere. I am using default installation and no changes to the tutorial cases. All other cases I tried appear to be working well.

[hjasak]

Hi Ales,

Yes, you need to initialize the fields. Before starting interFoam, please run setFields on the case. In is controlled by the setFieldsDict in system.

Good luck,

Hrv

[alajbegovic]

Thanks Hrvoje, it worked.

[kim]

I try to compile the moveTest.C file in OpenFoam1.2.
moveTest.C is nothing but movingPinFvMesh.C.

But I got an error of motionSolver.

Please tell me how to fix the error or
what the error mean.

moveTest/moveTest.H:56: error: cannot declare field 'Foam::moveTest::ms_' to be of abstract type 'Foam::motionSolver'
/home/pius/OpenFOAM/OpenFOAM-1.2/src/dynamicMesh/lnInclude/motionSolver.H:60: note: because the following virtual functions are pure within 'Foam::motionSolver':

pius

[hjasak]

Hi,

I cannot find the moveTest.H in the standard release - I suspect you got it from one of the packs.

In short, the motionSolver is now a virtual base class and there are 2 choices: laplace and pseudo-solid. Please have a look at the icoTopoFoam example to see how to modify the code.

Enjoy,

Hrv