2 phase flow, free surface instability issues
 

Hello Everyone

I'm working to create a 2-phase model of a plate entering water, moving along a predetermined path then exiting the water while rotating independent of its motion. I have solved (after many different tests and trials as to how to get it to work) the issues of its motion/rotation by using two domain. An inside domain that contains the blade and a fine mesh which is big enough to contain the full induced flow (i.e. the inner domain is large enough that the outer domain would not be unnecessary except for the motion). Then i have an outer domain which houses the inner domain with a course mesh which is used to simply absorb the motions of the inner domain.

Everything above seems to work fine. The issue i am having involves applying a free surface. I use an unstructured tetrahedral mesh. When I apply the two-phases, i have trouble trying to solve the free surface. It seems as though because cfx is trying to solve a flat surface through an unstructured mesh, the surface keeps moving up and down as it tries to solve different iterations and timesteps. I'm not to worried about the moving surface as i'm studying the interactions between the plate and the water however the moving surface is causing velocity fluctuations and inducing currents which grow to be over 2% compared to the plate motions that i will apply.

Does any have any suggestions on what i can do to help reduce these fluctuations.

Also please note, this happens when the domain and everything stays still, as in I let the simulation run but apply no motion.

Thank You,

DM

Can you post some images and the output file of a demonstration?

Here are some pictures, I cant attach .out file because it is to large. Even when i try to zip its about 180 kb

Then attach the CCL. It is a small text file.

Can you also do a drawing of what is going on? Where is the water level, what motion does the plate have?

Sorry should have at least explained it.

Finer mesh is an inner domain with an interface defined between the two domains (mesh size matches on both sides of interface).

Blade does not change position relative to inner domain.

Full inner domain will move. Path is about 1m in magnitude forward and down while the outer domain size is 30m diameter (to get you an idea of the scale of it all)

The approximate shape of path is shown in red, however as mentioned the path is much much smaller than what i penciled in relative to the size of the domains. Also the blade is about 0.5m long.

As the inner domain (and the blade with it) moves along that path there is about a 90 degree rotation applied to the full inner domain


With all that being said, in the case shown here these is no motion applied. The case i showed you everything sits still for 0.37 seconds. The velocity contours shown are completely due to free surface instability (from what i can tell at least).

The water surface level is shown by the volume fraction contour in the pictures already posted. Its the faint rainbow that goes across the domain and is about 1-2 cells thick depending on the position and if i were to post over different times, the thickness will change over time as well as it tries to solve the surface.

Hopefully i've been clear in my description, I tend to go on. Just the one important thing is that in the case shown above, there is no motion applied.

Thank You,

DM

Please post the CCL.

Do you include surface tension?

When I did free surface modelling some time ago I set up a little test case (ie a small, simple mesh) where I tested the effects of all the free surface parameters. This allowed me to work out what was important for my model.

Free surface spreading and jiggling can be minimised by appropriate choice of time step size, convergence criteria and free surface settings. You will have to test this your self to optimise for your case.

Sorry i missed the CCL before. I just copied the first part of the output file.

I think i have played with the surface tension settings a little bit but haven't seen much of a change in the results from it. Could be that i dont really know what i'm doing with them and i'm just clicking and praying with some of those settings.

* You are using the inhomogeneous multi phase model. Do you anticipate mixed air/water (eg fine bubble or foam)? The homogeneous model is much simpler and is more appropriate if a distinct interface exists.
* Based on the size of this model surface tension will not be significant. But surface tension puts major restrictions on the numerics so the runn will behave itself much better with surface tension off.
* Your convergence tolerance is loose. Have you checked this is OK?
* This model may work better with double preicison.

I'm a bit unsure as to how the inner domain moves, but could refining the mesh where the water surface is help? If the surface moves a lot and it's too hard to define throughout the simulation fair enough, but the CFX doc's suggest that a fine mesh at the interface could help prevent the issues you're seeing.

The movements really prevent localized refinement at the surface. I dont think this will really help with the issue though, the area affected seems to scale with the mesh size (like the induced flow is within x number of cells from the surface) however the magnitude of the induced flow is the same.

Refining the mesh may help to reduce area and end up helping to reduce the error but it doesn't really help the underline issues which also effect convergence.

When i've read through the cfx help it has suggested some things but seems to say this is a known issue in terms of causing propagating waves and looking to not use residuals as a convergence criteria. I'm just more taking a last ditch effort here in hopes somebody has worked through this problem before.

Re. Glen
I'll look into your suggestions. Initially i was using a homogeneous model but was having some other issues and thats when i switched to non-homo and it seemed to run better. I dont have much entrainment however I do expect some air pockets forming in the water as the plate enters. Right now however i'm more concerned with the force acting on the plate from the water and rough water interactions with the blade so slight errors with how the air pockets form as long as they dont affect the forces should not be an issue. I'll look into non-homo again.

I have tightened up my convergence criteria (max 10 iterations vs. 25) and its had no effect but i'll leave it shorter just to speed up the runs. This was something I had read about before posting which is why i tried it.

Surface tension is currently off and i'll be sure to leave it that way.

I'll try using doubler precision. I've read that before and i may have tested it a bit ago but i'll be sure to try it again.

Reading through the help documents i've tried playing with different options such as the Interface Compression Level but having seen much difference. I'm probably miss using them on account of not fully understanding but i guess i'm hoping for a magical option to fix it...don't think its out there.

Last question i guess is if you know of a way to try to separate the convergence criteria to stay away from the interface. Only thought on how to do that would involve trying to only look at area's where the volume fraction is about or below a specific number. I just dont know if something like that is possible.

The other thought to try to control the surface instabilities would be to try to create an artificial force or resistance to limit momentum transfer between the two phases. Since i'm focusing on the blade and water interaction, I dont think it should effect the results to drastically.

Once again thank you for all your help

The choice between inhomo vs homo is more about what size bubbles you want to model. If they are big enough that the free surface model can resolve them, then go homogeneous. If you are going to get bubbles smaller than the mesh and free surface model can resolve then go inhomogenous.

By convergence I meant the convergence tolerance (currently 1e-4), not the max iterations.

Regarding the wobbling interface - this is hard to avoid in free surface models, especially in ordinary quality meshes like this. Simply put, any small wobble, even a numerical inaccuracy will cause the free surface to move and form waves whcih will propogate. This is why steady state free surface models are very tricky to converge.

Thanks for the help Glenn.

I've tried both homo and non homo and both give the same effect for the free surface "wobbling"

The actual surface itself i could not care about. It really has no effect on what i'm looking at. What matters to me is the induced flow its causing.

I guess i'm just taking one last ditch effort before saying there's nothing I can do about it. I just wondering if there is any way in ansys to either solve the surface better (like using a different method to solve it) or somehow reduce the induced flow caused by the surface fluctuations. For example, a way to just dampen the flow at the surface so the surface waves a much more localized.

I know i always have the option to refine my mesh more but i'm already very close to the limits of what i can use.

A finer mesh will probably result in more wobbles, not less.

These wobbles are very hard to reduce, especially with surface tension models. Your best bet is to improve mesh quality at the interface by putting soem high quality hex elements in that area.

You could always damp the surface region by putting a momentum sink over it but that will damp any real surface motion as well, of course.

Glenn， I am wondering what free surface parameters did you test, and how you evaluate
whether they are important?

What free surface parameters did I test? All of them - I systematically worked through all of them and worked out what each one did. I used a few simple benchmarks such as a drop on a surface, laplacian pressure of a spherical drop and some others and that allowed me to work out what was required for a fast and accurate free surface simulation.

But this was ages ago and I cannot remember the results. I recommend it to anybody working in this area - best to work out for yourself what works and what does not. It takes some time, but it is time well spent.

Thank you so much.
I learnt a lo from you.
Thank you sincerely.

I really dont care about surface motion at all. Even I'm worried that bubbles following the blade entering the water will produce large errors for what i'm actually looking at. For this reason I'm looking now to just eliminate all surface effects and bubble formation from the blade entering by defining the VF at all points in the domain

i.e. specify that at y>0 Volume fraction of air is 1
y<0 Volume fraction of air is 0

I just cant figure out how/where to define that. I think using a step function is the best way to define an equation for this in the same way you define the volume fraction at boundaries
step((y-UpH)/1 [m])
Where UpH is the height of the water surface (in my case 0m)
I just cant figure out where i can apply this in CFX. Like where in CFX is there an option to define the volume fraction throughout an entire domain?

Once again, any help is always appreciated

Thank You,

DM

If you know where the free surface is and it does not move then why model the air at all? put the domain boundary on the free surface and make it an opening with a pressure of 0 Pa on the interface.

If the free surface does move but you know where it moves to you can keep it single phase by using mesh motion to make the opening follow the free surface motion.

Problem is i cant make the boundary at the top of the surface due to the motion of the blade entering and moving through the water.

I need the blade to go from out of the water to in the water. The way i described above with the mesh motion is the only way i have been able to move the blade along the needed path (with the ability to make fine changes to the path) without inducing any unwanted forces. If i move the boundary to the surface, there is no way of moving the blade using the method mentioned above and I dont know of any other way to create the motion.

What are you trying to learn with this model? What is the output from this simulation?

I'm trying to look at the flow around the blade and the lift/drag force acting on it. The output is one of two things. To look at different blade designs, or to compare slightly different motions to see whats more effective. The model is representative of a canoe blade moving through the water during a stroke.

Sounds fun. For your model I would consider using an immersed body to do the motion and run it single phase. This would be much easier if you do not want to consider free surface deformation.

But I suspect you will find that deformation of the free surface is important. Not only trapping of bubbles on the blade at entry and exit, but also the free surface bumps, whirls and eddies in a normal paddle stroke.

Sorry, correct me if i'm wrong, but when doing immersed solids, typically you know for forces acting on the solid and your studying the motion it makes. My model is the other way where i know the motion and want the force.

I'm basically studying two phases of the stroke. First is the catch (as the blade enters) which is very rapid (<0.15s) where the angle of attack is very steep (close to 180 degrees) and the speed is at its peek.

Then the draw phase which last about another 0.2s where the angle of attack is closer to around 90 degrees but the speeds are much less. At this point there is also a very large rate of rotation of the blade compare to its movement which is why a transient study is important over a quasi-steady approach.

While I do feel the surface effects will definitely play a good part, I'm more worried that without having a really good way to validate things such as bubble formation, any error associate to bubbles will dominate other things such as pressure profiles when comparing slightly different cases. For example, if the blade enters with a 5 degree angle of attack vs 10 degrees, if one case produces a bubble that wouldn't normally be there, the bubble could effect the profile more than the change in angle of attack.

In the end i know this isn't ideal but i'm at least trying to find a good place to start then hopefully be able to add onto.

You can prescribe the motion and measure the force in immersed solids.

You can describe much more complex motions with immersed solids, and the mesh is a simple hex mesh covering the region so mesh quality is excellent. But you will loose some boundary layer fidelity on the blade and the other simplifications associated with the approach.

But I would definitely start with immersed solids. You will get up and running (well, paddling :) ) much quicker. And while it is running you can work on developing the free surface model version.

Haha, regardless of how everything turns out, I'm just happy you said paddling not rowing.

Not to beat a dead horse or try to nag however, if for nothing else but to try to satisfying a supervisor, do you know of any way to specify the volume fraction throughout the domain?

Some ideas of specifying volume fraction:
* Specify a volume fraction initial condition, and use the "solve vf" expert parameter to turn solution of the VF equation off. This is a bit dodgy as the simulation might want to have a normal velocity on the interface but this will freeze the interface and will probably lead to convergence issues.
* Make viscosity high around the interface. So this will model the interface, but the viscosity will damp everything out and hopefully make it easy to converge.
* Coarsen the mesh at the interface - has a similar effect to high viscosity, adds lots of damping. This will also speed convergence.
* Use a source term to magically make fluids disappear and appear to keep the surface where you want it. I think you can make this numerically stable so this shoudl work.

BTW: A company I used to work for was developing a rowing oar a while ago. The project was canned before it got too far, but I did help Stu with a few things and we did do some CFD on rowing oars - I could put you in contact with Stu if you like. http://www.freepatentsonline.com/WO1999058397.html

I've taken a look at these options and this is what i have so far.

Turning off the "Solve vf" - I found solve VolFra and set that to f. I assume this is what you were mentioning. It causes large convergence issues and in a test cast of an empty square domain, half water, half air, the solver crashes with an overflow error after 2 coefficient loops of the first time step, makes it to the third if i use double precision. So i dont think this is a viable option.

Viscosity - I'm not sure how to isolate the viscosity at the interface in order to do this. That being said, I dont know if this will work. By increasing the viscosity, I believe it will have large effects on how the water moves along the blade as it enters. I.e. the viscosity should act to pull the water down with the blade, leaving an air pocket.

Coarsen Mesh - I have an issue of not being able to isolate the mesh at the surface because the mesh moves with the motion of the blade (translates and rotates)

Source Terms - This idea seems like the best approach assuming i can get it to work. The issue i have is just not know how to do this. I know there are difference source term options for boundaries as well as if i create a subdomain i can enter domain source terms but I dont know which, if any, of these options can be used to create this type of effect. I have the feeling that none of the standard options will, I will have to create something new but really dont know how to approach this.

Other Idea
While reading the CFX documents and going through the different options in CFX trying to figure out how to apply the above cases, I have noticed the ability to add directional losses through source terms applied to sub domains. I am thinking this may be a good way to go about damping the flow in the direction normal to the surface (Y in my case) around the boundary. My idea is to create a loss in the streamwise direction (will set streamwise as Y) and have no loses in the transverse direction.
I can then apply Permeability and quadratic loss coefficients that depend on y such that Permeability is about 0 at surface and approaches infinity away from surface. The quadratic loss coefficient will be such that it is about 0 away from the surface and approaches infinity at the surface.

Your comments are pretty much what I expected. The Source term approach is the bets bets of my suggestions and your directional loss idea might work as well.

For the source term approach you need to make a subdomain (which can be the same mesh region as your domain) and set a fluid source on it.

After reading your post i realized my error when looking at the fluid source terms. I was treating them similar to boundary source terms and thinking of them as momentum sources.

I have tried to do this however it seems to cause convergence issues (doesn't resolve residuals passed 10^-3) and causes the fluid to just dip in the center. (using a test domain which is just a 2D empty box). Also the fluid boundary becomes much less distinct.

These are the expressions i'm using to define the mass flux

Air Mass Source: if(y>0 [m],(1-Air.vf)*Air.density/TS,-1*(1-Air.vf)*Air.density/TS)

Water Mass Source: if(y<=0[m],(1-Water.vf)*Water.density/TS,-1*(1-Water.vf)*Water.density/TS)

Where TS is my time step.

The one thing mentioned in the help is that using a volume fraction coefficient can help convergence when the source term depends on volume fraction. That being said, from my understanding, the volume fraction coefficient is just used to relate the change in volume fraction to the change in mass source which is what i've done while defining the source equations and using the water.density/TS term.

Another option i tried was to only use a source term for 1 Fluid. As in i defined a source term for water but not air. The result was a giant mountain (very steep and straight sides like a pyramid) appeared after the first couple time steps. Over time the size of this mountain reduced and at the same time the convergence of the solver resolved a bit better but throughout the entire time it did not reach the actual convergence criteria of 10^-4.

Sorry to keep at this, but all help so far has been very useful.

Thank You,

DM

Yes, you will need a source term coefficient to get things like this to converge. But even with that implemented this still might be tricky to get convergence - give it a go and see if it works.