Hi, Happy Easter to everyon
 

Hi,

Happy Easter to everyone!

If you're not busy egg hunting, I have a couple of questions for you:

1) what happens to the end points shared by 2 contiguous patches, when one patch moves and the other one next to it does not?
Is the displacement of the shared points a blend of the moving patch and the still patch?

2) Does the movingWallVelocity BC for U have a destabilizing effect on the computation?

In my case, playing around with icoFsiFoam, the computation blows in a few time steps when using movingWallVelocity, but it does not when using a fixedValue of (0 0 0) (which is a physically-wrong BC for a deforming patch though).

Isn't one better off by writing the displacement velocities of the deforming patch in a non uniform list after the fixedValue BC, instead of using movingWallVelocity?

3) Will Zeljko's updated Lagrangian finite volume method solver be released in a near future in OpenFOAM-dev? (the current icoFsiFoam relies on a small strain deformation solver -- stressedFoam -- so any large deformation in the solution is to be interpreted with caution)

Cheers,

Patrick

Hello Patrick, 1) You have
 

Hello Patrick,

1) You have a problem with consistency of a boundary condition in mesh motion: a "lower" (eg. slip), will be over-ridden by the "higher" (eg. fixed value).

2) No need: moving wall velocity is an absolutely consistent version of a fixed value velocity. It is done because the code can calculate the wall-normal motion flux better than anything else.

Have a look at the flux field for the boundary - do you have a non-zero flux for it?

3) Yes, we are writing some papers about it. This is the main reason I am reluctant to release the tutorial, 'cause the new code from Zeljko is so much better. This will definitely come out in SVN at some stage, but the Eccomas, Commodia and journal papers are not out yet.

This is what I propose to do: I will give you a tutorial for icoFsiFoam as it stands without checking it in. Please find flappingConsoleSmall_HJ_21Mar2008.tgz in

http://powerlab.fsb.hr/ped/kturbo/OpenFOAM/run/

It runs for me... but not too many questions please.

Enjoy,

Hrv

Hrv, thanks for the swift r
 

Hrv,

thanks for the swift reply.
The flappingConsole case runs fine for me as well :-)

I understand now why my computations were diverging:
The case I was trying to run with icoFsiFoam (aeroelastic deformations of a gliding dragonfly wing section) was actually well set-up, but because of the low stiffness and density I specified in the mechanicalProperties file (well, can't do otherwise with membrane wings), the weak coupling algorithm became unstable. So, the movingWallVelocity BC had nothing to do with the unstability (which was delayed by switching to fixedValue BC). I should have not doubted it!

At some point, I am going to redo those "insectaneous" FSI simulations with a strong coupling algorithm.

Cheers,

Patrick

I am working on a moving mesh
 

I am working on a moving mesh problem for transonic flow using sonicFoamAutoMotion. I would like to run a inviscid case. In that case how to I ensure that my movingWallVelocity BC permits slip?
Thanks
Anant

Hello everyone,

I hope this is the right place to post an issue I have concerning the movingWallvelocity boundary condition. Sorry to bring up a question about this BC again - Prof. Jasak writes that it's consistent and I believe that.

So here's what bothers me. My project is concerned with blood flow inside compliant vessels. I'm using a modified version of icoFsiFoam - basically added an outer iteration loop to be able to tackle strongly coupled systems. The solver seems to perform well when I increase the density of the fluid.

But at a certain point there seems to be a problem with fluid leaking out of my vessel (see image 1 - I didn't visualize the solid part which covers the fluid top & bottom), when I use the movingWallVelocity BC. It's strange and I checked the data sets - phi is zero at the the fluid-solid interface as should be ... still something must be wrong.

I ran the same case again using fixedValue BC at the fluid-solid interface (see image 2), which yields a much nicer flow pattern - here of course phi is not zero at the boundary.
I use a fixedValue velocity inlet and a totalPressure BC for the outlet in both cases.

Does anybody have an idea what is going wrong here? Is this problem possibly connected to the outer iterations I introduced - like, do I have to compensate or adapt anything with respect to the movingWallvelocity BC?

I would be glad if somebody could help or comment on that issue.

Cheers,
Wolfgang

hey
it is great to hear that you worked in FSI for a membrane wing.
actually i am a new stater in OpenFOAM. if you dont mind, could you explain how to do FSI in openfoam in short
regards

Hey Wolfgang,

I have the same confusion as you proposed for the movingWallVelocity boundary condition. I'm wondering have you figured it out?

Thanks,

I have two question.
1)does movingWallVelocity have anything more for impermeability of wall so that phi be zero.
if we use zeroGradient for T and p and wall velocity for U does it do the same work that movingWallVelocity does?
2)how to find phi value on a patch?

Hi ehsan,

you can find the phi value in the time dic;
do you think the fixedValue boundary condition will give the wall velocity for U, which means this boundary condition define a relative velocity for wall?

hi dear Teng
thanks.but then how is it possible to see values of phi on a patch?it doesn't appear in paraView.
I want to know if we set values as I told ((zeroGradient for p and T) and also fixedValue for wall is it different to movingWallVelocity? where's the impermeability for wall in movingWallVelocity BC?

Hi Teng,

The difference is that the movingWallVelocity gives you the absolute velocity of the wall, however, when e.g. solving for the turbulence, you are merely interested in the velocity (face fluxes) relative to the mesh motion. This is why the dynamic solvers have these fvc::makeRelative and fvc::makeAbsolute scattered throughout the code (movingWallVelocity on a static grid gives you zero velocity on the boundary).

This also means that if your boundary is moving, then the velocity at this boundary is non-zero - the physical flux of fluid on the other hand is 0.

You can make a quick test to convince yourself: Make a box of fluid with a boundary that allows for the water to flow in and out, e.g. the top boundary. Then start moving the lower boundary and specify either

or

It is only in the case of movingWallVelocity that you will see any velocities in the domain.

Kind regards,

Niels

I'm still looking forward to know about questions I propounded.

dear Niels I can't figure out what you have said.especially your last sentence in your example.do you mean that movingWallVelocity allow fluid to move through it?
also I have questions propounded at above post.
thanks.

Quite late but then movingWallVelocity actually does maintain the zeroGradient of the wall but then corrects the velocity with relative velocity since it is not absolute U (velocity) but relative U to the mesh motion. I am also interested in the topic. If we see phi which is the flux, we would find it is zero on moving walls.