[NickG]

Three time steps that is, not iterations!

[NickG]

I think that I've worked out the problem - the mesh is in metres not mm so is 1000 larger than wanted, causing the speed at the edge to be a lot larger than expected. Does anyone know if I can change the mesh size simply by just dropping a factor of some sort into the points file?

[rieuk]

Good to hear. Should be easy to do - if you import from Gambit then you can put a scaling factor as an argument to gambitToFoam

[NickG]

I'm coming from pointwise straight as an openfoam mesh, so in future I'll need to sort it out there. In the end I copied and pasted into OpenOffice, factored it down and copied it back, which works until about the 19th step when the velocity shoots up and I get another floating point error. Any suggestions from the case files?

Thanks

Nick

[flo]

Hi Nick,
use transformPoints –scale ‘(0.001 0.001 0.001)’ to scale m to mm
Have a good day,
Flo

[NickG]

Thanks flo it certainly saves some time

Nick

[alberto]

Great job! :-)

[rieuk]

Hey guys,

How do use GGI for a variable rotation rate (sinusoidal)?

Cheers

[Simon Lapointe]

You can easily modify the mixerGviFvMesh class to specify an oscillating motion instead of a fixed rpm.

[A.Devesa]

Dear all,

i'd like to ask for some advice for two small questions concerning interDyMFoam and GGI.
My case is a sort of mixer, full to 1/3 of it with water, the rest being air. I have a moving element far away from my phase frontier, quite at the bottom of the mixer, modeled with GGI. Everything except my GGI interfaces is defined as wall.

1- I observe quite high velocities (1m/s) in the vicinity of the interface between the two phases, after just one time step, which is quite surprising since everything is at rest at the beginning. The problem is that those high velocities close to the interface stay there afterwards, if i simulate longer. Can anyone tell me where does this come, and how to circumvent that if possible?

2- I would expect to find velocities close to my "rotor" of the order of the velocity introduced by the rotor motion itself. Instead of that, they remain ~3 orders of magnitude smaller than those, as if the liquid were not pushed or put in motion by the rotation movement... Is there a direct link with my density ratio, due to false definition of my fluids? Do i do something false concerning the BC in the moving region, of my walls? Did i miss something to set up for GGI multiphase simulations?

Since these are my first multiphase simulations, and almost my first GGI ones, i would be grateful for any idea, comment,...! Thanks!

[NickG]

Hi Antoine

1. - If I didn't have a fine enough mesh I found my velocity went up quickly and kept going until I got a floating point exception. With finer meshes it went up to start with but then settled back down after a several degrees of rotation. ...so have you tried a finer mesh?

2. - If you imported your mesh - have you checked that is in mm not m?

Also is your time step small enough.

You may have to play around a bit but I hope this helps.

Nick

[rieuk]

@Antoine

also make sure the ggi part and the static parts of the mesh are being merged properly ie. Make sure you created them such that they fit together perfectly

[A.Devesa]

Thanks Nick for your quick answer.

1- My mesh is indeed quite coarse but, still i would except that those peaks in velocity close to the interface vanish after some time, or am i just being too optimistic? In my case they are staying there and remain about the same order of magnitude...

2- My mesh was indeed imported, but the units are ok. The velocities i except are anyway based on the radius, so whatever the units may be, these should remain representative of the rotor motion. Don't you think?

Mh, do you have from your experience with all that - GGI + interDyMFoam - other suggestions? Thanks!!!

[A.Devesa]

Thanks for your reply James,
in fact, my GGI moving and sliding interfaces are fitting very perfectly (not only visually, but my ggiCheck shows it as well), i have roughly the same number of elements on them and the motion corresponds exactly to what i want.
My point 2 is: it's just as if the rotor were turning at the good velocity, but having no coupling on the fluid, which is rather very strange, and i can't explain...

It seems that my points 1 and 2 are due to very different things, but since it's related to GGI and interDyMFoam, i wanted to post them at the same time....

[A.Devesa]

Just as precision concerning point 1/:
i tried to simulate with sigma 0, and i still observe these high velocities in the vicinity of the interface, and mostly close to the walls.

May this precision give some ideas to you!...

[alberto]

I do not know much of GGI, but what you are experiencing seems to be related to the interpolation across the interface. I had a similar problem in my multiphase code (euler-euler, not VOF).

A (partial) solution to the problem in my case is to include the rapidly changing source terms (pressure gradient, buoyancy, other body forces, phase interaction terms) in the Rhie-Chow formula.

Best,

[A.Devesa]

I'm sorry, i've been flooding this thread a bit yesterday.
Mostly because the possible answer to my 2nd point was already written in the question + in the previous posts of this thread: i changed my BC for my rotor from wall to movingWallVelocity. It looks much more realistic now, though i still doubt if i really need to do that. I thought that the GGI treatment was not only to move the cells of the moving regions, but as well to adapt the boundary conditions.

Is it so, that i must not conserve my wall BC in the moving region and change them to movingWallVelocity? Isn't the code then trying to apply twice the wall conditions?

To my question about high velocities at the phase interface, i've been having no success with it yet, but i'll keep trying or flooding another thread since it's nothing to do with GGI...

[A.Devesa]

@Alberto

Originally Posted by alberto

A (partial) solution to the problem in my case is to include the rapidly changing source terms (pressure gradient, buoyancy, other body forces, phase interaction terms) in the Rhie-Chow formula.

Best,

Grazie for this hint. In my case, i'm starting with everything at rest, so there should be no rapidly changing terms or gradients in the momentum equations. And since this behaviour is already after one time step to observe, i'm rather tiping on a problem with my BCs close to the phase interface (walls) or my schemes:

    div(rho*phi,U)   Gauss limitedLinearV       1;
    div(phi,gamma)   Gauss limitedLinear01      1;
    div(phirb,gamma) Gauss interfaceCompression  ;
    div(phi,omega)   Gauss upwind                ;

[alberto]

Originally Posted by A.Devesa

Grazie for this hint. In my case, i'm starting with everything at rest, so there should be no rapidly changing terms or gradients in the momentum equations.

Not so quickly. If the density gradient across the interface is big enough, and you have gravity turned on, that's rapidly changing.

And since this behaviour is already after one time step to observe, i'm rather tiping on a problem with my BCs close to the phase interface (walls) or my schemes:

Isn't there where you have the highest velocity gradient?

Best,

[NickG]

Alberto

How do you turn gravity on/off? Is it on by default?

I'm trying to rotate an empty 2D mesh 'cylinder' inside a tunnel with an inlet at one end and outlet at the other in order to find out the minimum ggi interface spacing needed. Like Antoine it blows up after ~20 timesteps even with a courant No. of 0.1. This is due to the rotation of the mesh creating a non-physical rotational velocity across the interface. Am I using the wrong method? Really I want the rotation of the mesh to have no effect on the cross flow as it is free of any obstructions (walls).

Nick