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

difference between moving wall velocity and fixedvalue

Register Blogs Community New Posts Updated Threads Search

Like Tree7Likes
  • 7 Post By Bloerb

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   May 2, 2014, 14:39
Default difference between moving wall velocity and fixedvalue
  #1
Member
 
maryam morta
Join Date: Sep 2013
Posts: 54
Rep Power: 12
mary mor is on a distinguished road
Hi dear all
Can anybody explain for me what's the difference between boundary condition 'fixedValue' and 'movingWallVelocity' for velocity please?


Regards
Maryam
mary mor is offline   Reply With Quote

Old   May 2, 2014, 22:51
Default
  #2
Senior Member
 
fumiya's Avatar
 
Fumiya Nozaki
Join Date: Jun 2010
Location: Yokohama, Japan
Posts: 266
Blog Entries: 1
Rep Power: 18
fumiya is on a distinguished road
Hi,

If a wall moves at a constant velocity, you can assign the 'fixedValue' condition on it.

On the other hand, if the wall's velocity changes with time, the 'movingWallVelocity' condition
is able to impose a non-slip boundary condition on it.

You might want to take a look at the tutorial:
incompressible/pimpleDyMFoam/oscillatingInletACMI2D

Hope this helps,
Fumiya
__________________
[Personal]
fumiya is offline   Reply With Quote

Old   June 6, 2014, 13:50
Default
  #3
Senior Member
 
M. C.
Join Date: May 2013
Location: Italy
Posts: 286
Blog Entries: 6
Rep Power: 16
student666 is on a distinguished road
Hi,

I have another question about it, and that's it:

for a rotating case (like a fan), sometimes I see applied on rotating frame's patches two different BCs.

Code:
rotating_wall
(
type fixedValue
value uniform (0 0 0)
)
while sometimes I see someone using:

Code:
rotating_wall
(
type movingWallVelocity
value uniform (0 0 0)
)
What's the reason? which is the difference?

Thanks
student666 is offline   Reply With Quote

Old   October 27, 2019, 09:55
Default
  #4
Member
 
Obi
Join Date: Jul 2016
Location: Canada
Posts: 45
Rep Power: 9
obiscolly50 is on a distinguished road
Quote:
Originally Posted by student666 View Post
Hi,

I have another question about it, and that's it:

for a rotating case (like a fan), sometimes I see applied on rotating frame's patches two different BCs.

Code:
rotating_wall
(
type fixedValue
value uniform (0 0 0)
)
while sometimes I see someone using:

Code:
rotating_wall
(
type movingWallVelocity
value uniform (0 0 0)
)
What's the reason? which is the difference?

Thanks
I guess this is a bit late, but might help someone. fixedValue is used when simulating using an MRF (frozen rotor) approach. However, movingWallVelocity is used when simulating the actual dynamic movement of the rotor in transient mode.
obiscolly50 is offline   Reply With Quote

Old   October 28, 2019, 02:12
Default
  #5
Senior Member
 
Kmeti Rao
Join Date: May 2019
Posts: 145
Rep Power: 7
Krao is on a distinguished road
Hi Obi, I have actually tried both the BCs on MRF and I didn't find any difference between the simulation results. They were exactly the same. However we should use movingWallVelocity in transient simulations.
Krao is offline   Reply With Quote

Old   October 13, 2021, 18:46
Default
  #6
New Member
 
mo suepe
Join Date: Jul 2020
Posts: 2
Rep Power: 0
studente is on a distinguished road
Hi all, I have done a simulation of a Darrieus wind turbine, where I imposed those BCs on the airfoil, just to compare the results. All other parameters and conditions were set the same. Have a look at my attachments, there you can see a big difference in calculation of the Tangential force and Normal force between those two. The one with BC type movingWallVelocity shows a better agreement in comparison to experimental data. Apparently, the type no_slip overpredict the forces.

In another image, we could also see the difference between those two, what you see there is, the vortical structures behind the airfoil. The one with movingWallVelocity type (right) shows a more realistic vortices wake than the one of no slip (left)
Attached Images
File Type: jpg moving_wallvsnoslip.jpg (22.5 KB, 112 views)
File Type: jpg Force_comparison_noslip_vs_mWall_bisT2880.jpg (61.3 KB, 87 views)
studente is offline   Reply With Quote

Old   October 19, 2021, 13:11
Default
  #7
Senior Member
 
Join Date: Sep 2013
Posts: 353
Rep Power: 20
Bloerb will become famous soon enough
movingWallVelocity and fixedValue are both fixedValue conditions. For fixedValue the wall velocity is obviously set to the value you are imposing. movingWallVelocity however looks up the velocity from the movement of the wall itself.
Hence
Code:
type fixedValue;
value (1 0 0);
will set your wall velocity to 1 m/s in x direction.
Code:
type movingWallVelocity;
value (1 0 0);
won't set it to 1m/s in x. It will only use that value in the first time step and calculate the real velocity from the speed at which the mesh moves:

In other words, if your mesh is not fixed, but moving it applies this:


Code:
    if (mesh.moving())
    {
        const fvPatch& p = patch();
        const polyPatch& pp = p.patch();
        const pointField& oldPoints = mesh.oldPoints();

        vectorField oldFc(pp.size());

        forAll(oldFc, i)
        {
            oldFc[i] = pp[i].centre(oldPoints);
        }

        const scalar deltaT = mesh.time().deltaTValue();

        const vectorField Up((pp.faceCentres() - oldFc)/deltaT);

        const volVectorField& U =
            static_cast<const volVectorField&>(internalField());

        scalarField phip
        (
            p.patchField<surfaceScalarField, scalar>(fvc::meshPhi(U))
        );

        const vectorField n(p.nf());
        const scalarField& magSf = p.magSf();
        tmp<scalarField> Un = phip/(magSf + VSMALL);


        vectorField::operator=(Up + n*(Un - (n & Up)));
    }
Hence it is basically a non slip wall condition for rotating or moving meshes. But if my mesh is moving at 1m/s in x shouldn't it be identical you might ask! Now it does this: Up + n*(Un - (n & Up)). And you might notice that n & Up is identical to Un. Hence the second part is Un-Un=0. And you could simply write the boundary condition as Up (U at the patch which is exactly what fixedValue would do). But in reality this is not the case. This difference is for numerical reasons. Since Un is calculated using the flux field phi and Up is calculated from U. Hence there is a small difference between this and a pure fixedValue condition.The second part is hence purely for numerical stability.
Bloerb is offline   Reply With Quote

Old   August 1, 2022, 10:53
Default
  #8
New Member
 
Join Date: May 2018
Posts: 18
Rep Power: 7
Oliver Meng is on a distinguished road
So if I have a fixed mesh, do you know the difference between these two definitions?

type fixedValue;
value (1 0 0);

and

type movingWallVelocity;
value (1 0 0);


Quote:
Originally Posted by Bloerb View Post
movingWallVelocity and fixedValue are both fixedValue conditions. For fixedValue the wall velocity is obviously set to the value you are imposing. movingWallVelocity however looks up the velocity from the movement of the wall itself.
Hence
Code:
type fixedValue;
value (1 0 0);
will set your wall velocity to 1 m/s in x direction.
Code:
type movingWallVelocity;
value (1 0 0);
won't set it to 1m/s in x. It will only use that value in the first time step and calculate the real velocity from the speed at which the mesh moves:

In other words, if your mesh is not fixed, but moving it applies this:


Code:
    if (mesh.moving())
    {
        const fvPatch& p = patch();
        const polyPatch& pp = p.patch();
        const pointField& oldPoints = mesh.oldPoints();

        vectorField oldFc(pp.size());

        forAll(oldFc, i)
        {
            oldFc[i] = pp[i].centre(oldPoints);
        }

        const scalar deltaT = mesh.time().deltaTValue();

        const vectorField Up((pp.faceCentres() - oldFc)/deltaT);

        const volVectorField& U =
            static_cast<const volVectorField&>(internalField());

        scalarField phip
        (
            p.patchField<surfaceScalarField, scalar>(fvc::meshPhi(U))
        );

        const vectorField n(p.nf());
        const scalarField& magSf = p.magSf();
        tmp<scalarField> Un = phip/(magSf + VSMALL);


        vectorField::operator=(Up + n*(Un - (n & Up)));
    }
Hence it is basically a non slip wall condition for rotating or moving meshes. But if my mesh is moving at 1m/s in x shouldn't it be identical you might ask! Now it does this: Up + n*(Un - (n & Up)). And you might notice that n & Up is identical to Un. Hence the second part is Un-Un=0. And you could simply write the boundary condition as Up (U at the patch which is exactly what fixedValue would do). But in reality this is not the case. This difference is for numerical reasons. Since Un is calculated using the flux field phi and Up is calculated from U. Hence there is a small difference between this and a pure fixedValue condition.The second part is hence purely for numerical stability.
Oliver Meng is offline   Reply With Quote

Reply


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
BC set at fixedValue (0 0 0), but I get a non-zero velocity @ wall squadron OpenFOAM Running, Solving & CFD 9 May 31, 2018 10:47
rotating wall inside of an MRF zone - fixedValue or movingWallvelocity? evrikon OpenFOAM Running, Solving & CFD 3 April 30, 2015 03:51
Correct velocity boundary condition for a wall in a rotating mesh zordiack OpenFOAM Running, Solving & CFD 2 March 4, 2014 10:11
Problem where FixedValue Inlet meets noSlip Wall VSass OpenFOAM Pre-Processing 0 May 31, 2013 05:13
initial velocity field with a pressure difference sven82 OpenFOAM Running, Solving & CFD 2 July 23, 2009 05:05


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