[oschi]

Hello,
how would I implement a slip and noslip boundary condition on a dynamic, deforming mesh?

I have a small test case, which models the water flow inside a "bouncing cube", a rectangular mesh growing/shrinking periodically in the horizontal/vertical direction.
The motion of the walls is not transferred to the water, whatever boundary condition I use (slip, no slip, fixedValue (0 0 0 )).

Is it possible to implement a boundary condition that takes the boundary velocity into account and lets me set the relative fluid velocity, so that (0 0 0) translates into a "real" noslip condition?

I am testing with rhoPimpleDyMFoam of OpenFOAM 2.4.0. You will definitely help me as well, if you know of a solution using another solver or OpenFOAM version.

Greetings
Olaf

[tomf]

Hi,

For dynamic mesh cases a no-slip wall is defined as movingWallVelocity, have a look here:
http://cfd.direct/openfoam/user-guide/boundaries/

Also have a look at the tutorials.

I would not know is there is a slip velocity for a moving wall.

Regards,
Tom

[oschi]

Thank you Tom,
but movingWallVelocity does not work correctly. I think it is using only the wall motion at the first simulation time step and assumes that the wall motion doesn't change.

I have attached a tiny modification of the compressible/pimpleDyMFoam/movingCone tutorial. The only change I have made is a time-dependent table for the movingWall velocity in 0/pointMotionUx:

...
boundaryField
{
    movingWall
    {
        //type            uniformFixedValue;
        //uniformValue    constant 1;
        type            uniformFixedValue;
        uniformValue    table (
          (0. 1.)
          (0.00149 1.)
          (0.00151 -1.)
          (0.003 -1.)
        );
    }...

If you run "blockMesh && pimpleDyMFoam" on this case, you will see, that the fluid attached to the movingWall is always flowing at (1 0 0) m/s, although it must change to (-1 0 0) m/s after 1.51ms.

Do you know, how to correct this bug in movingWallVelocity? Or is it a bug in the dynamicMotionSolver?

Greetings
Olaf

[JNSN]

Hi Olaf,

in the attached case you have set the boundary condition for U to fixedValue. This is wrong. If you change to movingWallVelocity, then the velocities at the wall are updated according to the mesh motion, i.e. changing from 1 to -1.

Best regards,
Jan

[oschi]

Hi Jan,
you are absolutely right.

I am sorry, I have tested so many settings that I got confused. movingWallVelocity works fine for both pimpleDyMFoam and rhoPimpleDyMFoam.

Another question:
My confusion started, because pointMotionUx translates only the boundary, not the internal points, if I use groovyBC to express arbitrary, time dependent motions:

// 0/pointMotionUx:
boundaryField
{
    movingWall
    {
        type        groovyBC;
        valueExpression "toPoint(1)"; //"toPoint(cos(pi*time()/0.003))";
    }...

This problem is still around, independent from the (now solved) relative fluid velocity question.
Do you know, why a groovyBC does not allow to move the internal mesh points, whereas e.g. uniformFixedValue works correctly?

Greetings
Olaf

[JNSN]

Hi Olaf,

I have no experience with groovyBC. Maybe codedFixedValue does what you want. I have used it once and it worked well. See the example code for a sinusodial motion in x-direction:

    movingWall
    {
        type codedFixedValue; 
        value uniform 0; 
        redirectType rampedFixedValue; 
        code 
        #{ 
            scalar t = this->db().time().value();
            scalar om = 0.5;
            scalar a = -1.;
            //Info << "movingWall: " << a*sin(om*t) << endl;
            operator==(a*sin(om*t)); 
        #}; 
    }

Best regards,
Jan

[YUGU]

Hi, Jan


Do you have any ideas about how to add a flowRate to moving boundary?


Best,

Yu