[vagge]

Hello to everyone!

I am very new to CFD and I ‘ve just my first experience with OpenFOAM.

I ‘ve been using version 3.0.

I ‘ve been trying to achieve a steady state solution for the flow around a 3-bladed horizontal axis Wind Turbine rotor.
To this end, I have been studying just 1/3 of the rotor by considering 120° periodicity.

As explained in the attached picture 1, my domain consists of a (1/3)-cylinder type domain with the following patches: “inlet”, “outlet”, “summetryUp” (cyclicAMI), “symmetryDown” (cyclicAMI), “symmetrySide” (outer wall), “blade” (spinner & blade as one body) and “rotor” (baffle so as to create a cell zone within snappyHexMeshDict).

Since the domain is very large compared to the blade, which is the main point of interest, I have preferred to apply the MRF approach by creating a rotational (MRF) zone under/inside the “rotor” baffle patch. I have tried different lengths, heights and even shapes of the MRF zone.

I have chosen to have an intense volume cell refinement close to the blade as well as 9 layers around it with the first one having a height of 0.75mm, so as to be able to “catch” the boundary layer on the blade’s surface. Till a distance of 1.5m away from the blade surface, the mesh refinement level is pretty high. After, that the mesh is super coarse with no refinement applied. The whole computational domain consists of ~12 M cells.

I have deactivated the residual controls.
Although my main focus is on studying the estimated torque and thrust, I have two problems:

1. My simulations crash after around 800 steps/iterations (although I achieve stable satisfactory torque/thrust values already from the first 500 iterations)

2. The wake behind the blade doesn’t seem realistic. It improves after many steps far from the blade, but not in a close distance after it. Especially close to the hub region is like I have no wake at all, while close to the tip I even get a flow acceleration right after the blade (please see pictures (2-4) attached). Plotting normal-to-blade-height planes (example pictures 5-6) shows that there is a wake right after the blade Moreover, right on the imaginary boundary of the MRF zone, I get a sudden change of the flow velocity (obvious line on picture 4).

Regarding the crashing, by following the steps before it happens on paraFoam, I have realized that something fishy happens on the blade (please, see start of the problem on pictures 7-8 attached), especially close to the tip where the layering is not that good. Please see the checkMesh results attached.

Regarding the wake, I have tried to refine a larger region around the blade (5m) or even refine the expected wake region, but I the outcome has been just a faster crash. Trying many different MRFZones’ sizes and shapes hasn’t helped at all. Trying longer or shorter domains (in the direction of freestream velocity) hasn’t helped either.

The freestream velocity is 10 m/s.

Please, find attached the boundary conditions’ p and U fields files and the fvSolution/fvSchemes files.

I would really appreciate any advice on which direction I should work on.

If anyone has done something similar and wants to share the differences, I would be glad to see them.

Thank you all in advance!

[KateEisenhower]

Hello Evangelos,

I had a brief look at your files. What makes you set both the pressure and the velocity at the outlet patch? Maybe that is the reason for your simulation crashing.

Have you solved your problems already?

Best regards,

Kate

[vagge]

Dear Kate,

At first, thank you for your consideration!

I initially thought of the inletOutlet BC for the outlet but I actually tried to force the outlet to have recovered to the inlet state.

With this BC and this mesh, I am able to run an undisturbed (in a sense of no fluctuation on the produced forces) simulation for ~800 steps. I think I can thrust the forces results since nothing changes close to the blade during those steps. However, I want to achieve a good wake as well.

I have managed both to delay the crashing (~1000 steps more) and to produce a realistic wake by shortening the whole domain and the MRF zone, restricting it close to the blade (-25 m before and 30 m after it), This time I used a searchable cylinder instead of the rotor.stl . However, the better wake (see picture attached) that I have produced is on the cost of the forces which values are now decreased a lot.

In both cases (short and long MRF) I have tried both the BC that I initially had as well as the “freestreamPressure” BC for the inlet, outlet and symmetrySide patches. The wake and forces results have not been affected at all by this change.

Now something fishy happens with the mesh: I have tried different lengths of the MRF cylinder. The produced mesh in all of my trials is perfect (not even one face off the limits). Every other setting is exactly the same. For some of the tried MRF lengths, though, my simulation fails to start.

So now, the questions change:

1. What makes a shorter MRFzone delay the crashing and produce a more realistic wake and why does this happen on the cost of forces values?

2. Why different lengths of the MRF zone lead to the simulation not being able even to start?

[KateEisenhower]

Hello,

I don't know the answers for your new questions.
Let's go back to your first post. I can't see very much at picture 7 and 8. Can you upload more detailed versions?
I can see that your minimum x-velocity is 4 m/s. It should clearly be zero. Or did you set a custom scale?

Best regards,

kate

[vagge]

Dear Kate,

Thank you once again for your time.

Actually the velocity should also be negative, since there are recirculation bubles, especially behind the spinner.

This is not a problem. The screenshots that I had uploaded had a custom range.

Below, you may find attached the same shots zoomed as well as with the real range.

By the way, I have tried different values of k and omega too, without any success.
I also used the formulas in the link below (same as my CFD book: H K Versteeg and W Malalasekera) to calculate their values:

http://www.cfd-online.com/Wiki/Turbu...ary_conditions

that leads to k=0.375 and omega=0.037268 which simply leads to early crash. Guess that a larger dissipation rate is needed to damp the created turbulence (which should not be necessary for my solution though).
Please, let me know if you have any comments on that.

[KateEisenhower]

You're welcome.

1) Ok, does your simulation crash, when you are running it without turbulence?
2) Pictures of the mesh, especially the first layer at the blade, might be helpful.

Kate

[vagge]

Dear Kate,
Sorry for my late reply.
The lack of turbulence made no actual difference. I was able to run for more steps but I got a crashing as well.
You were right about the mesh. So far I had checked it only on a few random heights across the span direction, but by looking at more heights I have realized that the leading edge part is not OK (check screenshots attached) and might be the one causing the crash.
However, I ‘m not sure anymore if I should look at the wakes. I read the slides of Håkan Nilsson (Rotating machinery training at OFW11):
https://drive.google.com/drive/folde...-Q&usp=sharing
where he states that unphysical wakes should be expected (page 30). However, I don’t fully understand why. What I ‘ve thought so far is that the MRF approach provides a snapshot of a developed wake. Even if that’s not the case, then what still remains unexplained is that I get a more realistic wake when I shorten the MRFzone region.
Moreover, I don’t really understand the fourth bullet at page 33 of his presentation: “Always make sure that the interfaces between the zones are perfectly axi-symmetric”

Any loud thoughts are welcome.
Thank you for the consideration so far!