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