I am trying to model a 3 bladed, 50kW upwind turbine. I am having an issue with the dynamic stall mode. I used airfoilprep to extend the airfoil data from -180 to 180 degrees. (It might be worth mentioning that I have data for each airfoil in my blade for only one Re. The Re numbers I see are in the 1e6 to 2e6 range except for close to the root where it is probably closer to 5e5). I get reasonable numbers as long as I set StallMod in the Aerodyn input file to Steady. But when I change it to Beddoes, the power output doubles and I get some crazy numbers for RotorCp!
I am running a really simple case with no yaw and steady wind with no shear. I also looked at the element data for a few elements and the angle of attack remains steady after the transients have died out. I would have thought that under these conditions turning the Beddoes option on shouldnt really affect the power. I want to make sure that my model and airfoil data is correct before I tackle more complicated cases. If anyone can offer any suggestions on what might be causing the issue, I would really appreciate it. Thank you.
I’m not sure why the power would double, but I can tell you that Cp output from a dynamic simulation is not the same as it is for a steady-state performance code such as WT_Perf. Because of rotor inertia and flexibility, it is possible to get high instantaneous values. Set all DOFs to False in FAST and blow a constant wind on it if you want to see more-realistic Cp values.
Always test aerodynamics first with a rigid turbine.
Thank you for the quick response. I am sorry, I forgot to mention that all the DOF were set to false except comp aero. I was comparing the Cp values with all DOFs, and with and without Beddoes. I had corresponded once before with Jason about the instantaneous Cp values and he had explained how they can be misleading and it would be better to use some sort of averaging. I apologize if I didnt state the facts clearly. I guess the real question for me is whether an error in Beddoes coefficients can lead to such a dramatic change in power, everything else remaining the same?
Is the problem with Rotor Power or the Cp calculation, which is rather squirrelly and only marginally useful? The better way to calculate Cp would be to postprocess the FAST output with MCrunch, Crunch, or GPP. Use them to generate a calculated channel of instantaneous power available in the wind. Then, generate statistics and divide the average rotor power by the average power available in the wind. Instantaneous Cp is rather meaningless.
The problem is with the power. I have averaged the power for both cases and the one with Beddoes is twice as much as the one without. I am not that concerned about Cp…yet. And since you mentioned calculated channels, I have another question. Since I am new to the forum, I am not sure if I am violating ettiquete by asking something unrelated.If I am, I apologize.
I have noticed that when you turn off all degrees of freedom except CompAero, the RotTorq channel seems to ouput the aerodynamic torque. However if I have GenDOF enabled, and I turn the generator off after a certain period of time during simulation, the RotTorq goes to zero. Is there an output channel in FAST to ouput the aerodynamic power and torque being experience by the accelerating rotor in such a situation? The reason I ask is I am trying to estimate how much braking torque will be required by the emergency brake in case of grid loss. Thank you.
I have not responded because I really don’t know how FAST works in that sort of detail. I was hoping Jason would respond. It’s his code.
Thanks for responding. I assumed you were busy and hadnt had time. I was corresponding with Jason on another topic posted by another user and mentioned this thread to him. I hope he finds some time to respond. Once again thanks for your help.
I’ve not heard of the problem that you are reporting with the dynamic stall model before. The response you are getting is clearly not correct, but I’m not sure where the problem is. When you looked at the element data available throughh AeroDyn’s PRINT option, did you look at how the lift and drag data were affected by dynamic stall relative to the static data? What in the element data changes between when StallMod is STEADY and BEDDOES? What other FAST outputs are affected by the dynamic stall (thrust, torque, etc.)? You will need to debug this problem yourself.
If the reaction torque is eliminated, than the aerodynamic torque will balance with the accelerating drivetrain (rotor + generator) inertia. As the RotTorq output in FAST is computed as the difference between the applied and inertia rotor torques, RotTorq should equal the accelerating generator inertia in this case. (RotTorq is the torque within the low-speed shaft that would be physically measured on a real turbine. RotTorq would only be zero in this case if the generator inertia was zero.) At this time, the aerodynamic-only torque is not a load that can be output directly from FAST. In your case, however, you could calculate it with knowledge of the rotor accleration, rotor inertia, generator acceleration, and generator inertia:
RotTorq = AeroTorq - RotInerRotAccel = GenInerGenAccel
AeroTorq = RotInerRotAccel + GenInerGenAccel
“GenIner” is an input to FAST and “RotAccel” and “GenAccel” are outputs (their units will have to be converted from deg/s^2 to rad/s^2 in this calculation). “RotIner” is computed and output to the FAST summary (.fsm) file. However, if the rotor is not rigid, “RotIner” will change with blade deflection and/or rotor teeter during the course of a FAST simulation, so this calculation will only be exact for a rigid rotor (for a flexible rotor, the calculation will work when averaged over some length of time). If the drivetrain is also modeled rigidly, GenAccel will equal RotAccel*GBRatio^2, where “GBRatio” is the gearbox ratio input to FAST. In this case:
AeroTorq = ( RotIner + GenIner*GBRatio^2 )*RotAccel
Thanks for the response. I will try to debug the Dynamic stall model.
The explanation on Aero Torq calculation was really helpful. I was able to calculate it based on the methodology you suggested. Just out of curiosity, is the AeroTorq output from aerodyn at everytime step? If so can the FAST code be modified to port this to an output channel? This is for future reference only since I am not at a point where I am comfortable modifying the source code yet (I hope to be someday). This would eliminate the uncertainty that would be introduced due to the flexibility of rotor and drivetrain. Thank you once again for all the help.
AeroDyn calculates new aerodynamic loads at every aerodynamic time step, determined by input DTAero in AeroDyn’s primary input file.
Regardless, AeroTorq is not an output of AeroDyn that is sent to FAST. Instead, AeroDyn sends FAST the aerodynamic loads from each blade element. These would have to be integrated across the rotor to find the overall aerodynamic torque.