[Aeronautics El. K.]

Hi all,

After much time, I decided to appeal for some help so many thanks in advance.

Physical problem:
Flow around wind turbine blade. Modelling 1/3 of the geometry and using periodic boundaries 120 degrees apart (rotational).

Approach:
There's an inlet and an outlet (obviously) and the sides are set to periodic boundaries. There is a rotating region (where the blade and the hub are) and a non-rotating (or stationary if you will) area. I hope the attached pictures will help you form a better picture of the topology. I have highlighted the regions with different colours. Red are the periodic boundaries that are stationary. Orange are the periodic boundaries that are rotating. I've also posted two pictures where the rotating and stationary volumes are highlighted. Maybe I should also mention that all the periodic boundaries are point-to-point matched.

Maybe I should mention that I used Pointwise for the mesh and in particular the mesh created in one of Pointwise's webinars (http://www.pointwise.com/videos/HybridMeshing/). Obviously I changed the solver to OpenFOAM.

I created two volume conditions; one is the rotational bit and the other is the stationary (please see the attached pics again). I set the option as volumeToCell and I also set Pointwise up to export the cellZones.

So far so good, the mesh was exported and I set up the OpenFOAM directories (I did checkMesh -constant -allGeometry -allTopology and also renumberMesh -overwrite , so we're ok with this).

I will give you all the relevant files to help you see what's going on but I must tell you that I have changed the constant/polyMesh/boundary for the periodic boundaries and set up the MRFProperties dictionary in the constant folder.

The simulation starts but it diverges straight away. The problem, as you may imagine, is that I have no idea why. Could it be the boundary conditions? Could it be the way I have set up the periodic boundaries? Something in the fvSolution or fvSchemes? Is it something I'm missing completely?

I would really appreciate any help you have give!

Many thanks,
Lefteris

PS
In case it's helpful/useful I'm running OpenFOAM on the bash for Ubuntu on Windows. I have 2 processors, 6 physical cores each (24 logical in total) and enough memory so hardware-wise I'm ok.
decomposePar (scotch, 8 domains)
mpirun -np 8 simpleFoam -parallel > log
are the commands I've used.

[betakv]

Have you checked dimensions of a computational domain? The forces are too high.

[Aeronautics El. K.]

Originally Posted by betakv

Have you checked dimensions of a computational domain? The forces are too high.

Yeap, the dimensions are correct - I've triple checked and I've also run the same mesh on fluent with no problems and decent results (qualitatively at this point).

The forces are too high because the velocities and pressures go crazy even in the first iteration (see for example the residual for Ux, Uy, Uz).

Any ideas?

[Aeronautics El. K.]

New information.

I added a line specifying the rotationAngle in the constant/polyMesh/boundary for the cyclicAMI patches.
When I decomposed the case this time, I get warnings similar to the ones in this post cyclicAMI crashes in parallel when processor has faces for only on AMI patch about non consistent patch areas (even though my boundaries are point-to-point matched. The weights though are almost perfect.

I don't understand what I'm missing so any help would be highly appreciated.

[betakv]

It's too hard to give you the right advice. I can give you only a few recommendations.

If you are using simpleFoam, you can use ambient pressure 0.

For U, k, omega or epsilon is better to use inletOutlet boundary condition on outlet and far-field

I'm not sure and I don't know how is defined MRF cell zone. I expected that nonrotating patches are not stat_left or stat_right. Nonrotating patches should be eg. nonrotating walls.

Originally Posted by Aeronautics El. K.

New information.

I added a line specifying the rotationAngle in the constant/polyMesh/boundary for the cyclicAMI patches.
When I decomposed the case this time, I get warnings similar to the ones in this post

https://www.cfd-online.com/Forums/openfoam-solving/132701-cyclicami-crashes-parallel-when-processor-has-faces-only-ami-patch.html

about non consistent patch areas (even though my boundaries are point-to-point matched. The weights though are almost perfect.

I don't understand what I'm missing so any help would be highly appreciated.

[Aeronautics El. K.]

Originally Posted by betakv

It's too hard to give you the right advice. I can give you only a few recommendations.

If you are using simpleFoam, you can use ambient pressure 0.

For U, k, omega or epsilon is better to use inletOutlet boundary condition on outlet and far-field

I'm not sure and I don't know how is defined MRF cell zone. I expected that nonrotating patches are not stat_left or stat_right. Nonrotating patches should be eg. nonrotating walls.

Hi Vojtech,

thanks for taking the time to reply.

I did change the outlet (and farfield) to inletOutlet yesterday at some point. The numbers changed but the behaviour was the same. Silly residuals and the continuity one was something to the power +35 in the 3rd iteration already so something is fundamentally wrong in my setup I suppose.

I wonder whether it is what you just said about the non-rotating patches.
If it's any help, I followed the example given in this video on youtube from Pointwise and Applied CCM: https://www.youtube.com/watch?v=7grE62n5t4g (minute 27:00 onwards for the OF setup) but I might as well improvise at this point.

[wyldckat]

Quick answer: Got your PM, and although I'm a bit late on this, I believe that the only way to properly help with this is if the instructions here: How to give enough info to get help - are followed.

Even if you cannot share the mesh of the geometry itself, it's fairly simple: remove the blade geometry from within the mesh and leave only the rest of the mesh and case-setup. This way it's easier for anyone to take a proper look at the mesh within the case and try to diagnose what's wrong with the mesh in the AMI patches.

[Edgar Alejandro Martínez]

Shouldn't you assign the AMI boundaries to one processor? You're running the case in parallel, right?