Simulation of NREL UAE Phase VI turbine
 

Hi,

I'm trying to simulate the wind turbine in fluent using MRF. Basically, I'm tyring to recreate the whole experiment (wind tunnel included). However, the problem is that the torque produced on my simulation is about half that of the experiment. I'm not sure what could have gone wrong. I'm using a k- SST model with transition. My inlet is 3 diameters upstream while the outlet is 7 diameters downstream of the turbine. Are there any details I need to especially take note of to ensure an accurate simulation, or has anyone faced such a problem before?:confused:
Thanks in advance!

Hello,

I am working on the same project. I haven't got any torque values out but as soon as I do I will let you know.

Did you get good Cp's?

Thanks,
Fred

One more thing,

I remember reading this problem happening to other people. Maybe you should multiply the value by 2 since you have two blades.

Thanks for your help. While the values are around half of the experimental ones, I don't think it's a matter of multiplying by two, since the cm is about the axis of rotation, and my simulation is not periodic.

Once I've analysed the cp values I'll get back to you.

Well, I've analysed the cp distribution, and integrated the forces along the blade jut to ensure I've got the right torque, and the torque is still about half of what it should be. Checking the force coefficients, the normal force coefficient is much higher in my simulation, while the tangential force coefficient is much lower. I'm not sure what else I can do.

To anyone who reads this, I have changed the turbulence model to k-ω SST without transition to better match the wall y+ of the simulation (with transition requires a y+ of 1 and without requires a y+ of 30 to 300). However, the simulation results have not differed significantly. Inlet TI was 0.5% and viscosity was 10, to match the conditions of the NASA-Ames wind tunnel. outlet condition was outflow, and the wind tunnel walls are wall condition, to match the experiment.

I am now in the process of refining the mesh, to bring the y+ closer to 30. To reduce computational time, I'm cutting it down to half a rotor with periodic condition. If this works, I'll post here so that others having the same problem can try it out.

Hey what documentations have you been using for simulating the NREL? How did you determine the TI at the inlet?
What meshing software are you using?

Fred

I'm using Gambit to mesh (I just imported all the blade cross-sections based on the data given in the NREL UAE Phase VI document). I used the TI that's typical of the NASA-Ames wind tunnel. The TI was stated in http://www.nrel.gov/docs/fy01osti/29494.pdf.

I'm now running several different turbulence models besides k-ω SST to see if those work. The periodic simulations seem to converge faster.

Thanks for the info,

I had that PDF, I must have missed that bit.

I have been trying to remesh my mesh because I get problems when I switch to viscous solutions. I am using ICEM CFD. So far I have used a whole 360 domain but as soon as i can i will do a periodic simulation.

i also could not find the the atmosperic conditions. What are you using for the atm pressure?

Fred

Hey Fred,

I'm just using normal atmospheric pressure. I doubt that there was any specific pressure control in the wind tunnel, and the pressure will not matter that much since it's the gauge pressure that's important. Unfortunately, all the turbulence models came up with similarly inaccurate results. I'm now trying to refine my mesh around the blade, and hopefully not have too many cells. I have read literature that used 11m cells to successfully do a steady-state simulation, but this would require more juice than I have. http://yrc.utcb.ro/2010/p/YRC_2010_THCE_Razvan_Mahu.pdf

also, just to let you know, I've made a new mesh with a prismatic boundary layer. The y+ of the simulation is less than 5, so it will work well in k-ω SST with transitional flows. The results look slightly better, but still far off from experimental. I'm now attempting to incrementally increase the speed to 72rpm (run 100 iterations at incremental values of rpm), and see if it makes any difference at all.

Well, I've got zilch. If there's anyone who could help me, I'd really appreciate it.

Hey thanks for the papers,

how many elements have you got with the last mesh?

I have now been trying to improve my mesh before doing other simulations. What's the height of the first prismatic layer?

fred

my prismatic boundary layer is uniform (not aspect ratio based). The first height is 0.0000675. 20 layers, growth rate of 1.25. I think it's quite a good boundary layer. From studies I've done previously, it's about 3% of chord, so good enough to capture important features of the boundary layer.

my meshes are generally 2.5-3 million cells, with at least 2-2.5 million within the rotor zone alone (the cylindrical volume with the rotor within it). Most of these are concentrated around the rotor.

I have an inkling my usage of the dimensions of the NASA-Ames wind tunnel might be bamboozling the solver, as the sides are only 2-4 rotor diameters in length. Even with a transient, sliding mesh solver, the solution diverges (after about the same number of iterations as the steady state solution. Interesting?)

I have now changed the sides to a circular boundary, with a diameter of 5 rotor diameters. Also, I have changes the upstream and downstream (inlet and outlet) boundaries to 7 diameters from the centre. Let's see if these changes work. I'm attempting different combinations of BCs for the inlet, side and outlet, to see which gives the best result. I'll let you know.

also I cannot exceed by much more than 3m cells, as my computer won't be able to solve it. That's why I'm doing a periodic simulation, which means I have an equivalent of 6 million cells for a full rotor.

This is my setup I have been using now,

Periodic mesh with 4 radius upstream, 5 downstream and 3 on the side.

I am around 1 millionf of elements with 10 prismatic layers with the same parameters as yours.

I am using a single moving reference frame with k-w sst.

As you see in the pic I set inlet velocity, outlet outflow (1), far field as wall, blade as wall (zero velocity at the wall), symmetry for the semi cylinder in the middle and periodic for the two sides.

I first start with low rotational velocity as 1 rpm, then to 3, then to 7.54 at 7 m/s. So far, it has been converging. Before I was using symmetry for the farfield and could not converge and was also getting reversed flow and 'turbulent viscosity ratio limited to....'. So with farfield set as wall it got a lot better.

Now I have been looking at the cp's, but they are well off, they get up to 30-40......the simulatin has not converged properly yet, but I don't think it's going to change a lot. What could the problem be? Maybe the setup for the single moving reference frame or the mesh is not accurate enough...

You know when you setup the inlet velocity, do you leave zero for initial gauge pressure?

Hows are you doing with your problem with the torque?

Fred

Right.....just changed the outlet bc from outflow to pressure-outlet at 0 pa and the cp's are much much better. what turbulence specs did you use for this bc? I just left default, i.e. backflow turb kin energy 1 and backflow specific dissipation rate 1 as well. do you think it's ok.

So i was having a look at the torque, I put moment center 0 0 0 (my origin) and mom axis 0 1 0 (rotation axis is y), select moments and and the blade and get the following (see pic), is the circled valued the one I am looking for right?

Yes, that's the one you are looking for. But the value looks rather low, doesn't it?

Oh yeah it does. So that's the final value evethough I am using periodic?

For periodic you have to multiply by 2, since it will only compute the moment for one blade. Even then the value is low, no? At 7m/s the experimental torque is about 800Nm

Yes im around half the exp value. I am now making my mesh larger downstream and let's see if this make any difference.

Hi Fred,

Actually I've just found out that refining the mesh in the wake increases the accuracy of the simulation. My simulation torque is now 70% of experimental value, a significant increase in accuracy. Unfortunately, I'm unsure if the wake mesh can be refined much more than it already is, since I can't increase the number of cells much more.

HI,

that's quite a good improvement, well done.

I am still quite far from experimental values. I still can't get the cp right, I was comparing the cp's at the three stations 30%, 63% and 95% and at the leading edge I get up to 15-20. The simulation has converged only of 3 orders of magnitude. Do you think I should let it fully converge and see if they get better?

Getting to to fully converge won't change the value much. Only do so when you know it will converge to an accurate value, or you'll be wasting your time. Comparing cp values at individual points is difficult, and I suggest you don't do that. Try to compare the cn and ct values, the normal and tangential force coefficients with respect to the airfoil chord. Then check to see if the cp distribution is similar. However, if your torque isn't the same, all these are not going to be similar. So try first to get your torque and thrust values to match experimental ones.

Since I'm doing mrf, I found that increasing the upstream and downstream boundaries of the cylindrical volume around my rotor increases accuracy, as does having a fine mesh (my mesh throughout this volume is 0.05, but decreasing this size further does not seem to affect the values). I've now attained about 88% accuracy, but I'm still adjusting the mesh to improve that. I have overcome the issue of memory by running a parallel process within the cores of my i7. Apparently each core can use only a certain amount of the RAM resulting in a malloc error if I use one core. I'm still working on it, but I should get an accurate simulation by the end of the week.

Hi Federico

Mesh distribution is basically about distributing the computing resources effectively, i.e balancing time and accuracy of your solution.

The mesh has to be refined (made finer) wherever :
1. the geometry and flow involved is complex.
2. Area of interest. We are usually interested in flow in a particular region.

Higher number of cells means a lot more time and computational resources are required.

In this case, if you are interested in the wake of the turbine, you have to make the mesh cells as small as possible in that area. When distributing the mesh, the change in cell size Must be very gradual to prevent errors and reduction in accuracy.

You would also need a large domain to dissipate the energy, prevent backflow and also so that you can distribute these cells more gradually. i.e the inlet and outlet of the domain, being far up/down stream or away from the main flow (area of interest), can have (relatively) large cells.

You might want to consider breaking up your domain into a structured and unstructured mesh regions. The unstructured mesh can be used to capture complicated geometry as well as part of the wake while the remaining domain can be meshed with structured hex cells which cover the domain a lot better than unstructured tet cells.

Thank you for your insightful post. We are looking at the more specific case of steady-state simulation of a wind turbine, and the simulation results don't seem to match experimental ones for us and many others, judging by posts in the forum. The reason Fred tried to coarsen his mesh is that some people found that too fine a mesh can result in highly unstable and possibly steady-state results, as the solver tries to resolve the inherent unsteadiness in the flow. The problem with our situation is the lack of literature on steady-state simulations of wind turbines. Most people understandably go for the unsteady simulation since it is more guaranteed to give an accurate result. However, the reason for wanting a steady-state result is also understandable, since the rather steady far-wake structure can be expected to be the same, it would be easier to compare the wake with other steady-state models like the actuator disc and it take much less computational time.

Hey there,

how's you work going?

so after getting some help and computing power from another user of the forum, I got a torque at 7 m/s which with less than 10 % error.

Then I tried with a wind speed of 10 m/s but torque slightly decreased with an error that for my case is still acceptable. The troubles really begin when I move on to 15 m/s and higher speeds, for example at 15 the torque decreases to half of the expected value.

Did you encounter this problem too? What could the cause be?

Thanks,
Fred

Hey Fred,

I've had similar results. I used a mesh with 7.7 million cells. 93% accuracy at 7m/s. I'm still running 10m/s. btw, did you have a noisy coefficient of torque output from fluent?

as for the higher wind speeds, the problem lies with the onset flow separation. I don't think you can get accurate results however hard you try. Researchers have been having problems getting accurate results with unsteady simulations, and steady or pseudo-steady state is definitely out of the question. If you really want an accurate result, you definitely need to perform an unsteady simulation, although this will take a lot of time. I'm running my simulations on an 8-core intel xeon (parallel). perhaps you can adjust your study to look at more wind speeds prior to flow separation?

Hey Fred,

I was wondering where you got your cp data from and if you could send it to me. For the post-stall cases, I'm currently running unsteady simulations at 2-degree timesteps. It should take me about 9 days for a decent result. I'll kepp you posted.

Hey Fred,

I'm still running the unsteady cases at 2 degree time steps, but they look promising. What has surprised me is that the 13m/s case i've run at pseudo-steady conditions (1 time step=1 revolution (0.833333s) ) is also showing promising results (although I cant be sure since it has not converged). Maybe you could try a pseudo-steady state simulation for the higher wind speeds? I run with 20 iterations per time step and start collecting results every 10 time steps from 250 to 400 time steps, when the output is noisy but consistent. Then I take an average of the parameters I want. While some might want to take the result at each time step, I find this unnecessary since it is not a true time-averaging as the azimuth of the turbine remains constant.

Hi aqstax,

I am doing a similar type of simulation on CFX. I was encountered the same problem ( simulation torque value is half of expected torque value ). My simulation case is tidal turbine instead of wind turbine which are to pair with Prof As. Bahaj tidal turbine experimental data.

I was simulating the whole turbine with channel included, which get me the results of half of the experiment. I see you was doing the same thing and solve the problem by change the simulation to periodic (single blade domain) by basically refine the mesh through the whole region (blades, farfield , everything) right?

I had a question that confused me for few months. When you are performing the periodic simulation, say two blade, 180 degree periodic domain is used right? Then when simulation result converged or what so ever, the value is multiplied by two to get the two bladed turbine torque right? Is that the same if i were to simulate a three bladed device, by modelling 120 degree periodic domain? Get the torque and multiply with three?

Really appreciate and happy to read the thread.

Regards,
Lacer Loh

hi,

yes, you would multiply the torque value you got by three.

Hi Fed,

Thanks for the reply~~ I see the light ~ One last question, are u have any experience with the torque values, if i model a 120deg periodic domain and 180 deg periodic domain? Will they be same?

Regards,
Lacer

Hi Lacer,

That is aboslutely right. The torque from the periodic simulation will give you only the torque produced on one blade. So you need to multiply it by the number of blades. Make sure you have a powerful machine at your disposal, and run fluent in parallel, which will ensure you can run case with many millions of cells (my own case has 7.7m cells, but I believe there are even more accurate ones in literature with 11m cells). The reason for changing to periodic was that the flow is symmetric. so it made more sense to model one blade alone. Your torque values will probably be different if you change from a 2 bladed to 3 bladed rotor. (180 to 120 deg) However, they should be close.

Hi aqstax,

Thanks for the reply man~ really super appreciate ur reply. It already been a bottleneck for me more than two months~~ I using i7 for the simulation, i see u have a good gear :)

Regards,
Lacer

The i7 will allow you a pretty good simulation, although a bit slow. It has 4 cores but 8 threads. When you run Fluent in parallel using 4 processors, it will run only 4 threads. This means you will use only 50% of the cpu. If you increase the number of processes, however, what will occur is that the threads sharing the same core will dip into the same memory cache, slowing the pocessing speed of each thread. However I used to first run my simulation on an i7 using 4 processes (i found no increase in speed when I increased the number of processes). It ran fine, although quite slow.

I understand how getting the accuracy of the simulation to a tolerable level can be frustrating, but remember that the meshing process takes longest in almost any cfd endeavor. It is an iterative process involving meshing and simulation, and I myself have made countless of meshes and run countless of simulations before achieving the accuracy I needed. It is important to read as much literature as you can while your simulations run, so that you can make an educated improvement to your mesh rather than trying random things.

Yea, that's true. I had learnt to mesh the turbine and domain for more than half year. By the way, what kind of mesh u are using? I am using hybrid mesh. Boundary layer on the blade, and quite a coarse mesh for other place ( which contribute to the error ,half compare to experiment).

regards,
Lacer

Actually I didn't use a boundary layer mesh at all. The reason was two-fold. One, I had problems with diversion on the turbulence parameters with the boundary layer on. Instead of trying to fix this, I realized the BL took up many mesh volumes. Instead, I kept the mesh as fine as possible close to the blade, and ran the k-ω SST model without transitional flows. This ensured my y+ was suitable for the simulation. For k-ω SST model with transitional flows, the y+ required is 1, requiring a very fine boundary layer.
Thus, I was able to refine the rest of my domain adequately as well, since the boundary layer did not take up that many cells anymore. My mesh was purely tet-unstructured. The results I'm achieving are very comparable to experimental results, and I don't really need a good resolution of the boundary layer, so this worked for me.

Thanks for the reply. So the tet-unstructured work good for you. I shall try on the tet-unstructured as well as hex-structured mesh then. Have a nice day.

Regards,
Lacer