CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Running, Solving & CFD (https://www.cfd-online.com/Forums/openfoam-solving/)
-   -   Free slip moving wall BC (https://www.cfd-online.com/Forums/openfoam-solving/105274-free-slip-moving-wall-bc.html)

Claudio July 26, 2012 12:41

Free slip moving wall BC
 
I'm trying to solve the sloshing tank 2D problem, but would like the walls to be free slip.
However, if I change the BC for U from "movingWallVelocity" to "slip", I get a solution with a flat free surface, and the velocity at the walls are shown as zero, not the same as the wall.

Any idea on how to solve this?

THanks

ngj July 27, 2012 03:18

Hi Claudio

I sounds like you need to make your own boundary condition, which is a merge of (i) slip and (ii) movingWallVelocity, i.e. enforcing the slip condition tangential to the plane but keeping the movingWallVelocity in order to have the velocity of the wall enforced into the momentum equation.

Good luck,

Niels

Claudio August 13, 2012 12:28

Hi Niels,

Thanks for your reply.
I have very limited knowledge of C/C++ (grew up with Fortran)., so I was wondering if you or somebody else out there would be willing to give a hand in writing the "movingfreeslipwall" BC for OF.

Claudio

louisgag January 10, 2014 11:14

I'm working on the same BC...

hk318i August 22, 2014 14:20

Quote:

Originally Posted by louisgag (Post 469477)
I'm working on the same BC...

I am working on the same BC too for a while. I tried the concept for 2D cases, it worked fine but it seems that it is not working for 3D.
Did you managed to implement it? any ideas?

louisgag September 8, 2014 03:21

Hello Hassan,
I did implement the BC. If you are interested I will post the code here.
-Louis

hk318i September 8, 2014 05:02

Quote:

Originally Posted by louisgag (Post 509450)
Hello Hassan,
I did implement the BC. If you are interested I will post the code here.
-Louis

Indeed, please post here it will be really helpful for me. I was working on it and I have a serious doubts about my implementation.

louisgag September 8, 2014 05:15

1 Attachment(s)
Hassan,
try including this in your 2.3.x personal folder and compiling it, I think all the files are there.
Code:

    wallName
    {
        type            myMovingWallSlip;
        value          uniform (0 0 0);
    }

Cheers.
-Louis

hk318i September 8, 2014 05:55

Quote:

Originally Posted by louisgag (Post 509465)
Hassan,
try including this in your 2.3.x personal folder and compiling it, I think all the files are there.
Code:

    wallName
    {
        type            myMovingWallSlip;
        value          uniform (0 0 0);
    }

Cheers.
-Louis

Thank you very much. It is similar to what I was recently wrote but didn't test it. Also it proves that my old implementation was totally wrong.

BTW in the new version 2.3.x, the if condition (mesh.changing()) changed to (mesh.moving()), I think it was even changed in the latest version of 2.2.x. It was reported as a bug because for some cases if you have auto mesh refinement with moving dynamicMesh, the boundary condition will be updated with mesh refinement not with mesh movement only.

Thanks again for your help!

louisgag September 11, 2014 11:02

1 Attachment(s)
You're welcome Hassan and thanks for pointing out the new function call for mesh.moving().

I've updated my code so if anyone else is reading get this new version...

Cheers


-Louis

SailorLiu January 13, 2015 09:39

2 Attachment(s)
Hi Louis,

Thank you very much for sharing your own code. I am currently peroforming some simulation which need exactly this moving wall with slip boundary condition. I have successfully downloaded and compiled this library and run the simulation with my wall set to myMovingWallSlip without any errors and warnings.
However, when I check the velocity at the wall surface in ParaView, something strange happens to me. Since my wall moves only in z direction in the sinusoidal form, I think all the velocity vectors should point at the same direction whether upward or downward at the same instant. When using the normal movingWallVelocity BC, this is what you will expect.
I attach two images to show the difference. The first one shows the velocity vector using Glyph filter in ParaView when the normal movingWallVelocity BC is used while the second one is the result when the newly compiled myMovingWallSlip is used.
One more question, what BC should be used for the pressure field? Will it be the same as the one for movingWallVelocity? Currently I am using zeroGradient or fixedFluxPressure.
I will really appreciate it if you can kindly help me clear out my confusion.

Best wishes,

Yuanchuan
Quote:

Originally Posted by louisgag (Post 509989)
You're welcome Hassan and thanks for pointing out the new function call for mesh.moving().

I've updated my code so if anyone else is reading get this new version...

Cheers


-Louis


louisgag January 13, 2015 11:35

Dear Yuanchuan,

I have experienced the same problem in paraview, but from further investigation I concluded that this was a problem from the rendering due to the fact that paraFoam does not know about this boundary condition. You could verify this by looking with paraFoam/paraview output at the first cells next to the wall instead of those on the wall.

As for the pressure condition, I personally use zeroGradient because I want a wall behavior.

Thanks for the feedback and keep us updated,


-Louis

SailorLiu January 14, 2015 10:44

3 Attachment(s)
Hi Louis,

Thank you for answering my questions. However, I do not quite understand what you mean by "You could verify this by looking with paraFoam/paraview output at the first cells next to the wall instead of those on the wall." Do you mean if I check the velocity at the first cells next to the wall I will notice that these velocity vectors should share a same direction?

I attach an image to show the velocity distribution in Z direction near the wall when the whole body is moving upward in the sinusoidal form as I mentioned earlier. As you can see, the distribution is not uniform. What is more confusing is that there are even vortices around those corners as you can see from the second image attached. This should not happen since I have already set viscosity to zero.

Initially I want to study the effects of viscosity, so I set the viscosity to zero while at the same time I set the velocity BC to slip. The result is very unlikely because as time goes by the fluid field is totally quiescent meaning velocity field does not change at all even if the body is oscillating in the Z direction. This is similar to what Claudio said in the first post of this thread.

To simplify the problem, I made a comparative study on the effects of BC for velocity at wall as well as viscosity using the wingMotion case (an airfoil) located at the directory: tutorials/incompressible/pimpleDyMFoam/wingMotion/wingMotion2D_pimpleDyMFoam. The motion is specified as a sinusoidal function in vertical direction (y direction for this 2D case) with the amplitude of 0.2865 and omega of 1 rad/s using the solidBodyMotion function (the whole domain rather than only the wing will move while preserving the mesh quality). Incoming current speed is reduced to 0.01 m/s to keep Re small. Turbulence model is set to laminar. The preliminary results are summarized here:

1. As long as the movingWallVelocity BC is used, there will always be vortices when there is or is not current and viscosity does or does not exist.
2. When slip BC is used, if there is current, no vortices will exist whatever the viscosity value is. The fluid field acts like an ideal one solved by Euler equation. Streamlines flow past the wing body smoothly.
3. When slip BC is used, if there is NO current, the fluid field will stay unchanged regardless of the value of viscosity, i.e. velocity and pressure is zero everywhere at every instant.
4. When the newly compiled myMovingWallSlip BC is used, when there is no current and zero viscosity, there will also be vortices near both the leading and trailing edges as shown in the third image.

It seems to me that when current is involved, the slip BC originally provided by OpenFOAM is sufficient to model inviscid flow problems. But if the body moves in initially still fluid, using slip will not alter the field. Besides, the value of viscosity (zero or nonzero) does not seem to affect the presence of vortices in the movingWallVelocity BC cases, which is also quite weird to me. The newly compiled myMovingWallSlip BC, on the other hand, acts more like the original movingWallVelocity BC.

I also uploaded the wing case where the newly compiled BC is used and the results at time = 1s are also included in case you want to take a look and examine what goes wrong here. You can download it via this link: https://drive.google.com/file/d/0BwX...ew?usp=sharing

Thank you very much for reading this.

Best wishes,

Yuanchuan

louisgag January 14, 2015 12:08

Dear Yuanchuan,

Quote:

Originally Posted by SailorLiu (Post 527494)
Do you mean if I check the velocity at the first cells next to the wall I will notice that these velocity vectors should share a same direction?

I mean that, in my case, the fluid in the domain near the walls behaved as expected even though the wall itself was misrepresented by paraFoam.

As for viscosity, I am not familiar enough with that part of the OpenFoam code to tell you what happens when nu = 0; I can tell you that I've also noticed a strange behavior when trying to set viscosity to zero but in my case the presence of viscosity was not a problem itself (I removed it only to speed up the calculation).

As for vorticity, have you tried displayed both cell and point based rendering in paraFoam to see if the influence of the wall may be playing a role here ?

I will try to look at your case in more details at the end of next week, I have some deadlines coming up now. In the meantime, I hope you can progress and keep us updated !

Regards,


-Louis

hk318i January 14, 2015 14:28

Hello,

Regarding your results, I have few comments, hopefully could help you to reach better conclusion.
1- You have to make sure that the solver is suitable as Euler solver just by adding zero viscosity specially if pressure based solver which uses kinematic viscosity not the dynamic viscosity.

2- Regarding your general expectations for the flow behaviour, please note that Euler equations for rotational inviscid flow, therefore the vorticity isn't zero. It isn't potential flow.

3- It is expected in the airfoil case which is attached that myMovingWallVelocity introduces more vortices around the tips because it allows the flow to slip over the surface, unlike the original movingWallVelocity which imposes the tangential velocity to be equal to the wall velocity.

I know that I didn't give you a complete answer but I hope that these points give you some hint.
Keep us updated
Best wishes
Hassan

SailorLiu January 15, 2015 07:57

1 Attachment(s)
Hi Louis and Hassan,

Thank you very much for your comments. I really appreciate it.

Louis, rendering vorticity in Paraview using either cell or point shows similar results, meaning that the vortices are really there. It will really very nice if you can spare some time to take a look at my case only when you are free.
I have one small irrelevant question. I am just curious that under what circumstances other than modeling inviscid flow you will also want to use this myMovingWallSlip BC for velocity. For viscous flow problems, should not the velocity BC for walls be always no-slip?

Hassan, your comments made me seriously think about my conclusion again. In response to what you said, I also have something to say and questions to ask:

1. For the wing motion cases, since it is adapted from a tutorial case provided in OpenFOAM, I use the original pimpleDyMFoam solver without any change. On the case side, as far as I am concerned, in order to make it simulate an inviscid case, I need to set the kinematic viscosity nu in constant/transportProperties to zero as well as change velocity BC imposed on the wing body from movingWallVelocity to slip as the BC movingWallVelocity indicates a no-slip condition. Other modificatiions include decreasing velocity, adjusting motion pattern and turning off turbulence model by setting it to laminar. Actually, as long as there is current, the slip BC works as expected. I attached an image to show the streamlines passing around the wing. What confuses me is how the flow looks like when there is NO current where streamlines are totally different and vortices show up.

2. You are right when you say Euler equations are for rotational inviscid flow. Rotation is possible when you use a solver based on Euler equations to solve a fluid field but only if there is already rotation exsited from the beginning. If no rotation thus no vortices exist initially, as simulation continues, no vortices should be generated according to Helmholtz’s third theorem. Of course I also learnt from others saying that there might be numerical diffusion which is able to generate vortices but this is not the case here considering the magnitude of the velocity being disturbed. I compared the maximum magnitude of velocity for the two cases. For the first case where current speed is 0.01 m/s and slip BC is used, this value is 0.0135 m/s at time = 5s. While for the second case where there is no current and myMovingWallSlip is used, it soars up to almost 1 m/s at time = 5s.

3. Indeed if I compare the maxUmag for myMovingWallSlip case and movingWallVelocity case when there is no current and no viscosity, the value for the first (0.983) is larger than the second (0.8). While for the second case, if I further specify a current speed of 0.01 m/s, the value does not change much only the minUmag increases a bit from 0.000114 to 0.000389. Maybe the current speed is too small to make a difference.

I think for now there are three questions to be answered:
1. Why does not the value of nu make a difference whatever BC I use. It seems to me from my tests that it is the BC that matters most rather than viscosity.
2. Slip works well at least from the standpoint of streamlines when there is current but fails (flow field remains still) when there is not current. In both cases the wing is moving. Again, the value of viscosity does not matter.
3. The new myMovingWallSlip seems to work most like movingWallVelocity although it might slightly introduce more vortices around the tips. But it always looks strange. After all, this new BC is supposed to impose a slip condition while movingWallVelocity imposes a no-slip BC.

BTW, Louis, when you created this new BC, did you find the one here? I looked into it. This one is similar to what you have done except that it inherits from the basicSymmetryFvPatchVectorField class rather than fixedValueFvPatchField used by you. It is a shame to say that I still have not understood the underlying theory to implement such a new BC.

Best wishes,

Yuanchuan

louisgag April 3, 2015 07:56

Dear Yuanchuan,

sorry for taking so long to reply.

Thanks for the link to the other moving wall slip BC. I remember vaguely coming across such a function before, but because it applied to an old/different version of the code (extend version) I didn't want to go through the challenge of solving the coding issues that would come up...

As for the case example you posted, my paraFoam shows something that looks like a proper slip condition in the x direction. I'm afraid I can't dig further into this problem as it may go beyond my knowledge.

Regards,


-Louis

louisgag March 1, 2017 11:02

Dear Everyone,
I've created a GitHub repository with the updated version of the code for OpenFOAM-4.x
https://github.com/louisgag/OpenFOAM-moving-wall-slip
Enjoy,
-Louis

ashokmoravaneni August 30, 2017 06:47

Quote:

Originally Posted by louisgag (Post 639048)
Dear Everyone,
I've created a GitHub repository with the updated version of the code for OpenFOAM-4.x
https://github.com/louisgag/OpenFOAM-moving-wall-slip
Enjoy,
-Louis

Hi Louis,
As written in Read me file I have copies the FiniteVolume folder into my case directory and ran wmake. But when I write wall type as below,
type myMovingWallSlip;
value uniform (0 -0.66 0);
valueFraction 0.7;

I am getting an error message that such type is unavailable and available types list.

What should I do ? I wanna implement slip valueFraction to my moving wall. Thanks in advance. Waiting for your Reply.

louisgag September 4, 2017 07:41

Hi Ashok,

This likely means something went wrong during the compilation.
I usually compile in a folder located as such: /home/louis/OpenFOAM/louis-4.x/finiteVolume but that shouldn't be an issue as long as your library ends up being built in the $FOAM_USER_LIBBIN folder it should work.

Are you using OF4.x?

Were there any error messages during compilation of the library?

You specified the type in the U file, right? Such as:

"yourWall.*"
{
type myMovingWallSlip;
value uniform (0 0 0);
}

Regards,

-Louis


All times are GMT -4. The time now is 11:59.