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.