Hello forum,
First off, thank you for all the feedback and help given so far. It has all been very helpful. Once again I apologise if I have overlooked something or if the questions is of silly nature.
In various litterature, the drive-train is modelled as the following 3rd order system.
Where the following parameters are used:
Jr = 35444067; [kgm^2]
Jg = 534.116; [kgm^2]
Ng = 97;
Bd = 6215000; [Nm/(rad/s)]
Kd = 867637000; [Nm/rad]
Which I have obtained from the 5MW reference report, except the Jr, which is an approximation based on the hub inertia and the inertia og the three blades. The state vector is defined as x = [omega_r omega_w theta_s], therefore disregard the ordering of the equations in the figure above.
The initial conditions for my simulation are computed as follows, such that they match those of FAST.
x(:,1) = [12.1pi/30 1173.7pi/30 0];
Since the given values are in RPM, and need to be converted to rad/s.
Furthermore, the drive train model is driven by the following torques generated by FAST:
Tr = RotTorq1000;
Tg =GenTq1000; (Both converted from kNm to Nm.)
By comparing the model using the above listed parameters, to the output from FAST there is a clear scaling issue. The configuration of FAST has the default modes enabled (Test18.fst) and is simulated using a non-uniform wind-field.
The above figure shows omega_r generated by the model and the RotSpeed (converted to rad/s) from FAST plotted on top of each other, the same thing goes for omega_g and GenSpeed. Here the scaling issue is not as obvious, as it is on the next figure. Which clearly shows the same peaks in the signal, though with some sort of scaling issue.
Since the rotor inertia is the only parameter that is not directly derived from the reference report, I attempted to vary it. By scaling it by at least 1/100 the model results begin to mimic the ones from FAST. The figure below simulates using the value Jr*(1/3000).
The scaled version of the model is valid for various other wind fields.
I’m unable to identify the source of said scaling, but by decreasing the the value of Jr, the respons improves drastically. Though physically this does not make sense to me.
Does anyone have any input? I’m afraid I’m overlooking something. Thanks for any help in advance. It is greatly appreciated.
Best regards,
Thomas Enevoldsen
Dear Thomas,
Just a few comments:
- The rotor inertia of the NREL 5-MW turbine is calculated by the ElastoDyn module of FAST / OpenFAST and reported in the ElastoDyn summary file as 38677040.613 kg*m^2.
- Your equations that isolate the drivetrain response assume that Tr is the applied aerodynamic torque. However, the RotTorq output from ElastoDyn is the reaction torque within the shaft (including the inertial effects from rotor acceleration/deceleration). You should set Tr equal to AeroDyn output RtAeroMxh, which is the applied aerodynamic torque.
- In FAST, outputs RtAeroMxh and GenTq depend on the rotor and generator speeds, respectively. Because your are prescribing them in your model, if your model has any deviation in rotor or generator speeds from FAST / OpenFAST, the associated change in RtAeroMxh and GenTq will not be captured. Thus, your model may miss some aerodynamic- and control-related damping.
- FAST has many additional DOFs (rotor, tower), not captured by your simplified equations, so, I would expect some level of difference in drivetrain response.
I would guess the second bullet is the one most influencing your results, but the others may have some effect as well.
Best regards,
Dear Jason,
Thank you very much for your response. I really appreciate the help.
The corrected for the rotor inertia has been noted, thank you.
Regarding point 2), by using RtAeroMxh I obtain the results as predicted. I now realize the difference between the AeroDyn and ElastoDyn outputs, I apologize for not realizing this sooner.
Your comments in 3) and 4) is something I am aware of, and the plan is to compensate for this using alternate methods. The above simulation is done in order to validate various model structures/parameters commonly given in litterature for both wind turbines in general and the 5MW reference turbine.
I have two follow-up questions regarding the outputs from FAST.
- I’m unable to find an output variable related to the generator reference, does it exist?
- The values BlPitchC1,BlPitchC2 and BlPitchC3 from ServoDyn, are these equivalent to the the reference signal for the pitch actuator? If so, is the response from reference to the values BldPitch1, BldPitch2 and BldPitch3 very close to instantaneous?
I should mention that my simulations currently use the IPC controller developed by TU-delft. ([url]https://github.com/TUDelft-DataDrivenControl/DRC_Fortran[/url] )
Best regards,
Thomas Enevoldsen
Dear Thomas,
Without modification of the source code, the ServoDyn module does not include built-in actuators for the generator torque and blade-pitch controllers. So, the commanded generator torque and blade-pitch angles instantaneously become the actual generator torque and blade-pitch angles.
Best regards,
Dear Jason,
Thank you very much for your response.
I have a follow-up question regarding some of the FAST Outputs.
Currently I’m looking for the moments that occur on the tower-top/Nacelle, which causes a change in angle of the Nacelle. Since I have no yaw control activated, I assume that the angles recorded in YawPos/YawPzn are the displacements due to the moments from YawBrMzp/YawBrMzn, is this a correct assumption? Also, the angles recorded in YawPos are very small, of the magnitude 0.02 deg, which seems like a very small amount considering the simulations are done using a non-uniform wind field, is this also correct?
I appreciate the help. Have a nice weekend.
Best regards,
Thomas Enevoldsen
Dear Thomas,
Yes, I agree. I don’t know exactly what conditions you simulated, but the yaw spring is quite stiff, so, I would expect small deviations in nacelle-yaw angle even under large yaw moments.
Best regards,
Dear Jason,
Once again, thank you very much for your response, I greatly appreciate it.
The simulations described in this thread is with the default modes from the included CertTest with FASTv8, using Test18.fst, with a different seed for the full-field wind input. Below are three observations I have made.
After taking a closer look at the YawPos and YawBrMzp outputs, it would seem that the one is a scaled version of the other. There is very small variation in the scaling, which I’m not sure if it’s due to numerical errors or not, due to the the value in degrees being so small compared to the torque. Though, it almost seems like there is no dynamics between these two outputs, which is strange to me. See the figure below.
Whilst comparing various outputs, I also noticed that the output data generated by FAST when running it through Simulink is different than that from the generated .out file. I have attached an image showcasing the calculated error between the two signals. I am aware that the output contained in the .out file is using format ES10.3E2, what I’m wondering is whether or not the small variations introduced in the Simulink version is due to numerical differences or due to another precision setting (for increased output precision). If it is the latter, how do I achieve a similar output in the .out file?
Furthermore, the values that are available in the avrSWAP() function, such as the the blade root out-of-plane bending moments in avrSWAP(30:32) (Nm), should these be equal to the equivalent outputs from FAST (Such as RootMyb1, RootMyb2 and RootMyb3 (kNm))? After converting to the same units there is also a clear difference between these signals.
I really appreciate the help.
Best regards,
Thomas Enevoldsen
Dear Thomas,
Regarding YawPos and YawBrMzp, the torque transmitted through the yaw bearing (YawBrMzp) equals the yaw-spring stiffness times nacelle-yaw angle (YawPos) plus the yaw damping times the nacelle-yaw rate. For small yaw rates and/or yaw damping, I would expect YawPos to track YawBrMzp quite well.
Regarding the FAST executable versus Simulink, presumably you are not modifying the model in some way e.g. implementing the controller in Simulink. In that case, I would expect excellent agreement between the results calculated by the FAST executable and Simulink, but there may be small differences due to the compiling and output precision. Regarding the latter, you can either increase the output precision or use binary output format, which intrinsically has more than 4 digits of precision.
Regarding the root moments, avrSWAP(30:32) contain the output-of-plane moments, but you are comparing them to the flapwise moments, which differ by the orientation of the blade-pitch angle.
I hope that helps.
Best regards,
Dear Jason,
Thank you very much for your responses once again. I apologize for incorrectly comparing the wrong moments, I have no corrected this mistake. Please excuse me.
I have been looking at the RtAeroCp values and I see that for most of my simulations they exceed Betz limit. Searching the forum I have found various discussions for how this is calculated, though most of it surrounds FASTv7.
Such as [url]Betz law and RotCp], [url]problem with AeroDYn 15 - #4 by Jason.Jonkman] and [url]Pitch rate in Fast v7 - #13 by Jason.Jonkman].
The following simulations were done using the default setup and baseline controller, with the configuration file from CertTest Test18.fst, with 151 different seeds for the full-field wind files.
I’m uncertain why the simulations are so consistently exceeding the limit. If a the Cp value obtained from FAST is to be used for something practical, should it be saturated to Betz limit or something similar? I also believe that I have read somewhere and seen from other peoples work on the turbine, that the max Cp for the 5mW reference turbine is in the range 0.48-0.5, which is exceeded at a much greater extent than Betz limit.
Once again, I really appreciate that the responses and help.
Best regards,
Thomas Enevoldsen
Dear Thomas,
As discussed in the forum posts you’ve linked to (and others), by nature of their calculation within the aero-elastic solution, I would only use RtAeroCp in a time-averaged sense to avoid apparent violations in the Betz limit that may occur instantaneously as a result of the calculation approach.
Best regards,
