Learizing Baseline 5MW Wind Turbine with FAST

Hi Jason,

By Activating GenDOF, 2 row/column is added to the state space matrices. Could you please explain what are the units of this variables?
for examle, in the output “.lin” file it says:
Row/column 3 = Variable speed generator DOF (internal DOF index = DOF_GeAz)
I suppose it is the generator speed. but since given state matrices contain:
Row/column 4 to 6 = First derivatives of row/column 1 to 3,
I wonder how derivative of speed (angular acceleration) can be a state? There is also no explanation for word “DOF_GeAz” in the User Manual. I would be grateful if you kindly explain to what states these two variables are associated.

Thanks,
Elham

Dear Elham,

DOF_GeAz is an internal parameter of FAST v7 identifying the index of the generator DOF within the internal equations of motion. The generator DOF is enabled when GenDOF is set to True in the FAST input file.

When the GenDOF is enabled, 2 states are added to the FAST v7 linearization output:

  • The azimuth angle of the generator DOF, in radians
  • The first derivative of the azimuth angle of the generator DOF i.e. the generator speed, in rad/s

I hope that helps.

Best regards,

Dear Jason,

Thank you for your quick reply.
So as I understand, if the first derivative of the azimuth angle of the generator is the generator speed (lets call it Omega), then azimuth angle of the generator DOF (i.e. Theta ) would be the angle of generator’s rotor angle? please correct me if I am wrong.
If so, why the generator’s rotor angle should affect other states? When the generator speed (Omega) is constant, then Theta will ramp up to infinity which means the system is internally unstable if other states are affected by theta.
For example this are the results I have got for linearizing WindPACT 1.5 MW Baseline @ 18 m/s wind speed:

Row/column 1 = 1st tower fore-aft bending mode DOF (internal DOF index = DOF_TFA1)
Row/column 2 = 1st tower side-to-side bending mode DOF (internal DOF index = DOF_TSS1)
Row/column 3 = Variable speed generator DOF (internal DOF index = DOF_GeAz)
Row/column 4 to 6 = First derivatives of row/column 1 to 3.

A = [ 0 0 0 1.0000 0 0
0 0 0 0 1.0000 0
0 0 0 0 0 1.0000
-6.5200 0.0008 0.0034 -0.2615 -0.0635 -1.7890
-0.0015 -6.5630 0.0009 -0.0243 -0.0189 -0.0254
-0.0023 0.1356 0.0009 -0.0583 -0.0107 -0.5168]

Here column 3 with non zero elements of A(4,3),A(5,3) and A(6,3) are the coefficients associated to Theta. which means some of the states will be affected by Theta.
Please let me know if I am missing something here. Thank you very much.

Best Regards,
Elham

I put a screenshot of matrices for convenience.

Dear Elham,

That is correct.

Please recall that the linearization output of FAST v7 involve periodic matrices (periodic with the rotor azimuth angle). To derive a linear time-invariant model, as I suspect you want, one would normally apply MBC for 3-bladed rotors: (nwtc.nrel.gov/MBC), followed by azimuth-averaging. Of course, in your case you don’t have any states or inputs in the rotating frame, so MBC is not needed and you can simply azimuth-average the matrices. After doing so, I suspect you’ll find that the column associated with the generator azimuth angle will be zero, allowing you to eliminate the generator azimuth angle as a state.

Best regards,

Dear Jason,

Thank you for your reply. I downloaded the MBC and gave it the .lin file I had. “GetMats” reads the file and fetches the FAST linearization output file information. However mbc3, states that there are no rotating states (The green box in the screen shot).
I set the NAzimStep = 1000, and Tolerences on 0.0001. It calculates the average A,B matrix, but as you can see the vector associated with Generator Azimuth is although very small but not still zero (See the Red box).
By increasing NAzimStep those values shrink, but they asymptote on these values. So I am wondering, am I using mbc3 code correctly?
Thanks for your helps.
Elham

Dear Elham,

Yes, your model has no states in the rotating frame; in your case, you only need to azimuth-average the matrices without first applying MBC (applying MBC would do no harm as it would have no influence at all).

The very small numbers remaining are the result of numerical round-off in the numerical solution and output. Using FAST compiled in double precision and/or outputting matrices in higher precision would likely reduce the values even further, but my guess is they would still not be exactly zero unless the linearization was formed analytically and all digits of precision were kept in the output. However, for all practical purposes, the values are zero (7 orders of magnitude less than the most dominant term) and you can safely eliminate the generator azimuth angle as a state.

Best regards,

Hello Jonson
If I understand well, according to the post Fri May 13, 2016 7:05 am , we should eliminate the third ligne and the third colomn in order to obtain the system [3x3] correspond to the three DOF enbled (Rotspeed, GedSpeed DrTr)
You have said in the post of Wed Sep 17, 2014 2:24 pm

Can you explain plus

Dear Ali,

By saying, “Δωt = Δωg + Δδtg” (using the nomenclature from the original post: Fast Linearized Models - #13 by Jason.Jonkman), I simply meant that the rotor azimuth state is the sum of the generator-azimuth state and the drivetrain-torsion angle state.

I hope that helps.

Best regards,

Dear Sir
The linearization of the CART wind turbine model, as mentioned by Wright, with FST V7 by considiring three DOF (generator speed, drive train flexibility and the balde falpwise bending moment as system with eight states is generated which are the deflexion and the velocity for each DOF. In the control system the author have remplaced the flapwise DOF for the two baldes with the symetric flapwise bending, and thus the matrix states is given by:
Amod = [[0,0,0,1,0
0,0,0,0,1
AvgAMat(5,2),2AvgAMat(5,3),AvgAMat(5,5),AvgAMat(5,6),2AvgAMat(5,7)
AvgAMat(6,2),2AvgAMat(6,3),AvgAMat(6,5),AvgAMat(6,6),2AvgAMat(6,7)
AvgAMat(7,2),(AvgAMat(7,3)+AvgAMat(7,4)),AvgAMat(7,5),AvgAMat(7,6),(AvgAMat(7,7)+AvgAMat(7,8))]]
I am demanding some clarifications:
Why considering the symetric flapwise mode rather than the flapwise mode for the two baldes
How the new state matrix is obtained from the origine state matrix given by FAST V7
If we apply the same process a three balde WT how about the satate mtrix when considering the asymmetric flapwise
If i want to extract the two parameters ( symetric flapwise deflexion and velocity) in Simulink, how to do

Dear Ali,

I don’t have any experience with this approach myself, so, I won’t answer your questions directly. But Alan Wright discusses his 5-state model in section 5.4 of his Ph.D. thesis-turned NREL report: nrel.gov/docs/fy04osti/35816.pdf.

Best regards,

Thank you very much for your reply

When linearizing the WT around an operating point and switching on the Genspeed on we found the matrix AvgMatC=926.3 which corresponds to the generator speed as output
I am wondering what is the unit of the Genspeed (rpm or rad/s)?
and also the unit of the state (which is I think the rotor)

SINCERELY YOURS

Dear Ali,

The GenSpeed output has the units of rpm. The speed of the generator degree of freedom (expressed as the rotation of the low-speed shaft on the generator side of the shaft has the units of rad/s.

Best regards,

Dear Jason,

I am confused about the value of the rotor inertia of the NREL-5MW turbine. In ElastyDyn and also in the 5MW NREL documentation, it is written that it is

But in the forum here, I found this reply saying that it is 38,759,228 kgm^2. Is the "Hub inertia about rotor axis " is different from the rotor inertia?

Besides, in the two-mass model of the wind turbine (rotor/generator), I am also considering the damping ratio of the rotor and the generator besides the damping and spring constants of the low and high-speed shafts, as you can see in the picture below.
dampings.PNG
Are they considered in the 5MW NREL wind turbine? If yes, where can I find their values, please?

Kindest regards

Younes

Dear Younes,

The rotor inertia is the sum of the hub inertia and the blade inertias about the rotor centerline. In ElastoDyn, the hub inertia is specified independently from the blade mass distribution.

The damping of the rotor and generator are inherently calculated within FAST / OpenFAST, but they are not specified directly as damping constants. The rotor damping comes for aerodynamic loads dependent on structural velocity and the generator damping comes from the torque controller (the damping is the slope of the torque-speed curve).

Best regards,

Dear Jason @Jason.Jonkman
When running the linearization of NREL 5MW wind turbine, I face two problems.
First. One error occured when running the simulation, and it shows like this:

An error occurred while running the simulation and the simulation was terminated
Caused by:
Error in ‘ywt_NREL5MW_ITIBarge_NearRated_ROSCO/FAST Nonlinear Wind Turbine1/S-Function’ while executing C MEX S-function ‘FAST_SFunc’, (mdlUpdate), at time 49.900000000000006.
FatalException

Could you please help me to solve this error?

Second. From the FAST User’s Guide, I see that the PCMode should set to be 0, which represents none pitch control. Can we consider those 0 control modes as open-loop control? If we want to calculate the linearization results for the closed-loop we construct in Simulink, how should we do?

Looking forward to your reply! Thanks in advance for your help!

Dear @Yinghan.Liu,

Regarding the error you are recieving, I’m not sure. The error seems to be generated after the OpenFAST has already been completed. Have the OpenFAST results already been generated before the simulation terminated abruptly?

I agree that linearizing without active control enabled is equivalent to open-loop control. The effect of open-loop blade-pitch angle perturbations will still be included (in the B and D) matrices when LinInputs is set to 1 when linearizing OpenFAST.

OpenFAST does not have the ability to linearize controllers implemented in Simulink and include such terms in the linearized state-space matrices output from OpenFAST. You’ll have to augment the linearized matrices output from OpenFAST yourself to include the linearized effect of a closed-loop controllers.

Best regards,

Dear Jason,

Thank you so much for your quick reply!

The linearization in OpenFAST does conplete before the simulation stop abruptly. And the linearization matrix is all null. It seems like the parameters setting is wrong. I will check this later.

Thanks again!

---- Replied Message ----

From | Jason Jonkman via NREL Forumnotifications@nrel.discoursemail.com |

  • | - |
    Date | 02/29/2024 21:48 |
    To | camille0327camille0327@126.com |
    Subject | [NREL Forum] [Wind & Water/Computer-Aided Engineering Software Tools] Learizing Baseline 5MW Wind Turbine with FAST |

| Jason.Jonkman
February 29 |

  • | - |

Dear @Yinghan.Liu,

Regarding the error you are recieving, I’m not sure. The error seems to be generated after the OpenFAST has already been completed. Have the OpenFAST results already been generated before the simulation terminated abruptly?

I agree that linearizing without active control enabled is equivalent to open-loop control. The effect of open-loop blade-pitch angle perturbations will still be included (in the B and D) matrices when LinInputs is set to 1 when linearizing OpenFAST.

OpenFAST does not have the ability to linearize controllers implemented in Simulink and include such terms in the linearized state-space matrices output from OpenFAST. You’ll have to augment the linearized matrices output from OpenFAST yourself to include the linearized effect of a closed-loop controllers.

Best regards,

Dear @Jason.Jonkman

When doing linerization in Simulink, it seems like there is an unavoidable bug. I would not only get the wrong linearization matrix, but also meet the abrupt stop I mentioned before. However, for the same input files, I can do the linerization correctly by DOS.

Anyway, thank you so much for your help!

Dear @Yinghan.Liu,

Regarding the OpenFAST simulation in Simulink terminating abruptly, can you clarify which version of OpenFAST you are simulating? Do you have this issue with any OpenFAST model that is linearized through Simulink? Does upgrading to the newest version of OpenFAST (currently release v3.5.2) solve the issue?

If not, we should report this as an issue to be fixed via the issues page of the OpenFAST repository: Issues · OpenFAST/openfast · GitHub.

Best regards,