[Claudio]

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]

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]

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]

I'm working on the same BC...

[hk318i]

Originally Posted by louisgag

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]

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

[hk318i]

Originally Posted by louisgag

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]

Hassan,
try including this in your 2.3.x personal folder and compiling it, I think all the files are there.

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

Cheers.
-Louis

[hk318i]

Originally Posted by louisgag

Hassan,
try including this in your 2.3.x personal folder and compiling it, I think all the files are there.

    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]

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]

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

Originally Posted by louisgag

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]

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]

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]

Dear Yuanchuan,

Originally Posted by SailorLiu

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]

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]

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]

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]

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]

Originally Posted by louisgag

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]

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