Error in executing IEA-15-240-RWT-UMaineSemi on OpenFast 3.4.1

Wind & Water Systems Engineering Software Tools
21

Dear @Muhammad.Sharjil,

Just a couple comments:

  • I would first recommend increasing the precision of the linearization output because an eigenanalysis is very sensitive to the precision of the matrices. We typically recommend using OutFmt = ES20.11E3 when linearizing.
  • The negative damping is showing in modes that have a damping of +/-1, which suggests that the modes are actually rigid body modes (with zero or close-to-zero frequency). This is likely for the generator azimuth state, unless you’ve removed that state from the state “A” matrix. It could also come from the platform degrees of freedom if the mooring stiffness is negligible, or due to numerical round off from my previous response.

Best regards,

22

Hi Jason
I increased the precision as suggested in below rated case, but the unstable poles are still there. There are unstable underdamped poles with damping for example -6.25e-02, -3.00e-04 etc.
Even after removing

  • Generator Azimuth State
  • Platform roll DOF,
    there are a lot of unstable poles (both real and real + imaginary poles. I couldnt figure out how to resolve this issue!!
    I have another query. How to check for mooring stiffness as I couldnt found any tab for Mooring variables in OutlistParameters.xlsx file.

Can you kindly suggest any debugging scheme to sort out the unstable poles, s.

Thanks

23

Dear @Muhammad.Sharjil,

I’m not sure I fully understand what you are saying. Are you saying that you removed the generator azimuth state and disabled the platform-roll degree of freedom (DOF) and unstable poles still remain?

I would suggest simplifying the model to better understand what is going on. Do you get unstable poles if the generator and all platform DOFs are disabled? Do you get instabilities in certain platform DOFs if you enable one at a time?

I now see that you have MoorDyn enabled (CompMooring = 3), although I don’t see MooDyn states in your linear model. Can you confirm? It may be easier to switch to MAP++ when linearizing to avoid having modes associated with the mooring line flexibility appearing in your linearized system.

Outputs associated with MAP++ or MoorDyn are discussed in their respective documentation:
https://moordyn.readthedocs.io/en/latest/inputs.html
https://map-plus-plus.readthedocs.io/en/latest/index.html

Best regards,

24

Hi @Jason.Jonkman
I tried multiple things but the unstable poles were quite good in number.
The first thing tried:
While running fst file, all DOF were ON

DOF_15MW_umaine
DOF_15MW_umaine724×369 11.4 KB

I excluded the GenDOF while making linear statespace model from postproLin_OneOP.m , AvgA, AvgB, AvgC, AvgD.
But I still got unstable poles (a lot of them with -1 damping, and also with damping less than -1)

Another thing I tried was to disable the platform DOF (sway, surge, heave, platform -roll, pitch, yaw). The resulting statespace linear model from AvgA, AvgB, AvgC , AvgD matrices was stable.

25

Regarding your suggestion
“… I now see that you have MoorDyn enabled (CompMooring = 3), although I don’t see MooDyn states in your linear model. Can you confirm? It may be easier to switch to MAP++ when linearizing to avoid having modes associated with the mooring line flexibility appearing in your linearized system.”
I was using the default setting of the file. Thanks for highlighting, I will try Map++ instead of Moordyn.
Thanks

26

Dear @Muhammad.Sharjil,

If the unstable poles dissappear after disabling the ElastoDyn platform DOFs, you should be able to isolate which DOFs are triggering the unstables poles (e.g., by running separate simulations for each platform DOF).

Best regards,

27

Hi @Jason.Jonkman
Using CompMooring = 1, solved the instability issue.
The poles are stable. The states are only 42 now.
Thanks for the response and highlighting the prime source of instability. :slight_smile:

1 Like
28

Hi @Jason.Jonkman
I am facing a strange issue
I am trying to linearize 15MW FOWT at

  • Wind = 10m/sec, RPM = 5
    I am using these settings
    TrimTol = 0.01,
    Trimcase = 2.

The simulation is completing without errors, but instead of linearizing at RPM = 5, the linearization is being performed at 5.58 rpm.
Kindly advice me on how to resolve this.
Thanks

dos-window
dos-window777×473 6.28 KB

RPM
RPM1203×675 14.8 KB

fst
fst1155×708 59.2 KB

elastodyn
elastodyn1080×731 49.6 KB

29

Dear @Muhammad.Sharjil,

What is TMax set to? OpenFAST will linearize at the end of the simulation if a steady-state solution has not been reached.

Best regards,

30

Hi Jason
Tmax was set to 8000 sec.
I have changed the TrimTol. Its linearizing at around this value.

1 Like
31

Hi @Jason.Jonkman
I changed

  • the simulation ending time to 20000 sec,
  • TrimTol = 0.005
  • RPM = 5
    However,
    The linearization was at 16725 sec (RPM = 5.06)

dos-window
dos-window865×1007 19.2 KB

fst
fst1312×1271 107 KB

RPM
RPM2127×1172 64.1 KB

RPM_zoom
RPM_zoom2092×561 22.2 KB

Kindly guide me on this as to why the model is not linearizing at around 5±0.005.

Thanks

Best Regards,
Muhammad Sharjil

32

Dear @Muhammad.Sharjil.

The convergence tolerance TrimTol is not the rotor speed error in rpm. Rather, TrimTol is a tolerance on the mean squared relative error of the output vector between the current revolution and the previous one. See the following trim implementation plan for more information: file:///C:/Users/jjonkman/Downloads/DevelopmentPlan-SetPoint-Linearization-1.pdf.

FYI: Considering how long it is taking for your trim solution to reach a steady-state solution, I would suggest increasing TrimGain to speed up the process.

Best regards,

33

Hi @Jason.Jonkman
As far as I have understood, the results are fine. The operating rpm can be bit different than the desired rpm (in fst file)
I have reduced the trim gain since having more gain value adds up small oscillation in the rpm.
I will try changing the gains.

Best Regards
Muhammad Sharjil

34

Hi @Jason.Jonkman
I am trying to run Run_OpenLoop.m using IEA-15-240-RWT-UMaineSemi.fst on windows 10 x64.
I am using the following files provided with OpenFast version 3.5.0

  1. OpenFast version 3.5.0
  2. FAST_SFunc.mexw64 & OpenFAST-Simulink_x64.dll

I ran an OpenFast simulation in standalone mode (using with command prompt), using the option PCMode = 5, VSContrl = 5 (user-defined from Bladed-style DLL), as provided in the IEA-15-240-RWT package.

After successful termination of simulation in standalone mode, I am trying to pass the following data to the OpenLoop.mdl (making appropriate changes in Servodyn.dat file i.e. PCMode = 4, VSContrl = 4 (user-defined from Simulink/Labview)

  1. Generator Torque (N-m) & Power (W)
  2. Blade Pitch Angles (deg)

However, I am facing following issues

  1. Complete mismatch in Generator Torque i.e. between Generator Torque as input to the simulink model and the output from simulink model
  2. Complete mismatch in Generator Power
  3. Initial mismatch in Blade Pitch Angle i.e. between Blade Pitch Angle as input to the simulink model and the output from simulink model
    simulink_input_output
    simulink_input_output2095×1209 104 KB

    simulink_input_output_zoomed
    simulink_input_output_zoomed1257×709 54.1 KB

    simulink_model
    simulink_model1047×906 57.7 KB

    simulink_model1
    simulink_model2

Kindly guide me on this.
Thanks

Regards,
Muhammad Sharjil

35

Dear @Muhammad.Sharjil,

If I understand correctly, you are taking the generator torque, generator power, and blade-pitch angles from one simulation with PCMode = VSContrl = 5 and inputting them to the OpenFAST S-Function of a separate simulation in Simulink with PCMode = VSContrl = 4. And while the blade-pitch angles generally look OK, the generator torque and power are off.

I’m not sure why the latter is so far off. Have you confirmed that the inputs are correct?

The extrapolation of the inputs to the OpenFAST S-Function in Simulink could be related to the small mismatch at the beginning of the simulation, as discussed in the following forum topic: S-Function input output signal mismatch.

Best regards,

36

Hi @Jason.Jonkman
I have checked into inputs and found some anomalies. I adjusted the inputs and able to get improved results.

improved1
improved12142×1209 121 KB

However, some initial mismatch in blade pitch angle, generator torque is observed.

improved1-1
improved1-12142×1223 94.2 KB

The RPM and thrust are having differences

improved1-2
improved1-22215×1212 198 KB

improved2
improved22087×1229 93.1 KB

I want to have a comment on the results as if they are fine?
Thanks

37

Dear @Muhammad.Sharjil,

I’m glad that you are now getting improved results. The small differences over the first few time steps appear to be related to the extrapolation of the inputs to the OpenFAST S-Function from Simulink. Further along in the simulation, other small differences are leading to small differences in rotor speed (and thus likely azimuth angle, not shown), but overall, the comparison is quite decent I would say.

Best regards,

1 Like
38

Hi @Jason.Jonkman
I am using the AeroDyn_Driver for ad_BAR_CombinedCases in r-test.
I want to generate Cp, Ct and Cq curves against TSR and Blade Pitch Angle.
I have certain queries regarding the results.

aerodyn_driver
aerodyn_driver2125×1192 113 KB

Why is there a pattern in Cp and why it is not a fixed line?
What value to use for Cp for generating the Cp curve against TSR and Blade Pitch?
Same is the query for TSR and Power.
The images of file settings I have used are in the images.
aerodyn_driver_drvfile
aerodyn_driver_drvfile2115×1272 210 KB

aerodyn_driver_drvfile1
aerodyn_driver_drvfile11942×1275 159 KB

Thanks

39

Dear @Muhammad.Sharjil,

From your AeroDyn input files, it looks like you have a few settings that will result in periodicity, including shear, shaft tilt, surge oscillation, and tower potential flow. For computing equivalent “steady state” values, I would suggest taking average values over a full revolution of the rotor.

Best regards,

40

Hi @Jason.Jonkman
Thanks for the response.
I this time used
WakeMod = 1 (instead of 2)
TwrPotent = 0 (instead of 1)
This time, there is no oscillation in the response.

aerodyn_driver
aerodyn_driver2159×1178 148 KB

The steadystate value for Cp with the option TwrPotent = 0 is not the average or mean of the case with TwrPotent = 1.
Can you comment on which value to used to buildup a Cp surface w.r.t TSR and Blade Pitch Angle.

I have another query, how can I average the periodicity in Cp curve with azimuth to get a mean value.
Thanks