Linearization off shore wind turbine

Jason.Jonkman · November 30, 2022, 6:34pm

Here are my responses:

Regarding your steady-state solution, it looks like response is converging (or at least not diverging), but very slowly, suggesting that the platform damping is very small. You could address this by, e.g.:

adding platform damping, e.g, through AddBLin
setting better initial conditions, i.e., by using the mean value of the response you are seeing as the initial conditions for the platform degrees of freedom
increasing the tolerance, TrimTol

Following your suggestion, I changed NLinTimes=36 to NLineTimes=0 and extended the simulation time to TMax=7000.

Presumably you mean you changed NLinTimes = 1; correct?

Regarding your comments on TrimCase, I agree.

Regarding your comments on initial conditions, I agree that it is always useful and sometimes imperative to set properly initial conditions for the blade pitch and rotor speed based on the mean hub-height wind speed you are simulating. I would generally figure these out when you first develop an OpenFAST model and use them in subsequent simulations.

Best regards,

Jian.Zhang · December 1, 2022, 7:21am

Dear @Jason.Jonkman

Thank you for your suggestion. Correct, I set NLineTimes=1 rather than NLineTimes=0.
Firstly I changed the initial condition (the mean values of the platform in six directions). The warning still existed, and the displacements/rotations in six DOFs are shown below.

Then I changed the TrimTol=0.05 instead of the TrimTol=0.001, and the OP was found at around 847.18 s.

According to my knowledge, I have several problems:

Because the variables “DispTol and VelTol” depicted in FAST V7 have been deleted, I wonder if these convergence criteria still exist in the latest version but are not shown or if two variables are not employed.
Regarding TrimTol, I want to know any guidance to define its value? The only thing is that the smaller the matter, the tighter the convergence.
Besides, “TrimTol” is set for the rotor speed. Why it plays a role in the convergence justification for the parked wind turbine?
The “AddBLin” is usually employed the tune the damping based on the wave tank because the radiation damping is not precisely simulated. If there is no experimental data, any guidance?

Thank you very much.

Best regards,

Jian.Zhang · December 1, 2022, 10:24am

Dear @Jason.Jonkman

Another error is related to the TLP platform. The error information is

E:\wake_offshore_Floating_2 Linearity (WindC)\1-1 Turbine_CoheU_TI8_PK\TLP_TrimC=0.001> openfast_x64.exe 5MW_TLP_DLL_WTurb_WavesIrr_WT.fst

**************************************************************************************************
OpenFAST

Copyright (C) 2022 National Renewable Energy Laboratory
Copyright (C) 2022 Envision Energy USA LTD

This program is licensed under Apache License Version 2.0 and comes with ABSOLUTELY NO WARRANTY.
See the "LICENSE" file distributed with this software for details.
**************************************************************************************************

OpenFAST-v3.2.1
Compile Info:
 - Compiler: Intel(R) Fortran Compiler 1900
 - Architecture: 64 bit
 - Precision: single
 - OpenMP: No
 - Date: Aug 01 2022
 - Time: 11:40:35
Execution Info:
 - Date: 12/01/2022
 - Time: 17:30:47+0800

OpenFAST input file heading:
    FAST Certification Test #23: NREL 5.0 MW Baseline Wind Turbine with MIT-NREL TLP
    Configuration, for use in offshore analysis

Running ElastoDyn.
Nodal outputs section of ElastoDyn input file not found or improperly formatted.
Running HydroDyn.
  Setting WaveTMax to 0.0 since WaveMod = 0
 Reading in WAMIT output with root name ".\5MW_TLP/HydroData/tlpmit".
 Computing radiation impulse response functions and wave diffraction forces.

Using SS_Radiation Module, with 20 of 20 radiation states

MAP++ environment properties (set externally)...
    Gravity constant          [m/s^2]  : 9.81
    Sea density               [kg/m^3] : 1025.00
    Water depth               [m]      : 200.00
    Vessel reference position [m]      : 0.00 , 0.00 , 0.00

Running ServoDyn.
 Time: 6999 of 7000 seconds.  Estimated final completion at 17:50:56.

 Performing linearization 1 at simulation time 0 s. (RotSpeed=0 rpm, BldPitch1=0 deg)
interval 0 Update_state: MAP_FATAL[59] : Approached a geometric limitation that the MSQS model is unable to solve. LMax = 151.414148 [m].
MAP_FATAL[59] : Approached a geometric limitation that the MSQS model is unable to solve. Line segment 1.
MAP_FATAL[88] : Line failed.

time 0.000000 Calc_output: MAP_FATAL[59] : Approached a geometric limitation that the MSQS model is unable to solve. LMax = 151.414148 [m].
MAP_FATAL[59] : Approached a geometric limitation that the MSQS model is unable to solve. Line segment 1.
MAP_FATAL[88] : Line failed.

interval 0 Update_state: MAP_FATAL[59] : Approached a geometric limitation that the MSQS model is unable to solve. LMax = 151.414148 [m].
MAP_FATAL[59] : Approached a geometric limitation that the MSQS model is unable to solve. Line segment 2.
MAP_FATAL[88] : Line failed.

time 0.000000 Calc_output: MAP_FATAL[59] : Approached a geometric limitation that the MSQS model is unable to solve. LMax = 151.414148 [m].
MAP_FATAL[59] : Approached a geometric limitation that the MSQS model is unable to solve. Line segment 2.
MAP_FATAL[88] : Line failed.

interval 0 Update_state: MAP_FATAL[59] : Approached a geometric limitation that the MSQS model is unable to solve. LMax = 151.414148 [m].
MAP_FATAL[59] : Approached a geometric limitation that the MSQS model is unable to solve. Line segment 3.
MAP_FATAL[88] : Line failed.

time 0.000000 Calc_output: MAP_FATAL[59] : Approached a geometric limitation that the MSQS model is unable to solve. LMax = 151.414148 [m].
MAP_FATAL[59] : Approached a geometric limitation that the MSQS model is unable to solve. Line segment 3.
MAP_FATAL[88] : Line failed.

interval 0 Update_state: MAP_FATAL[59] : Approached a geometric limitation that the MSQS model is unable to solve. LMax = 151.414148 [m].
MAP_FATAL[59] : Approached a geometric limitation that the MSQS model is unable to solve. Line segment 4.
MAP_FATAL[88] : Line failed.

time 0.000000 Calc_output: MAP_FATAL[59] : Approached a geometric limitation that the MSQS model is unable to solve. LMax = 151.414148 [m].
MAP_FATAL[59] : Approached a geometric limitation that the MSQS model is unable to solve. Line segment 4.
MAP_FATAL[88] : Line failed.

interval 0 Update_state: MAP_FATAL[59] : Approached a geometric limitation that the MSQS model is unable to solve. LMax = 151.414148 [m].
MAP_FATAL[59] : Approached a geometric limitation that the MSQS model is unable to solve. Line segment 5.
MAP_FATAL[88] : Line failed.

time 0.000000 Calc_output: MAP_FATAL[59] : Approached a geometric limitation that the MSQS model is unable to solve. LMax = 151.414148 [m].
MAP_FATAL[59] : Approached a geometric limitation that the MSQS model is unable to solve. Line segment 5.
MAP_FATAL[88] : Line failed.

interval 0 Update_state: MAP_FATAL[59] : Approached a geometric limitation that the MSQS model is unable to solve. LMax = 151.414148 [m].
MAP_FATAL[59] : Approached a geometric limitation that the MSQS model is unable to solve. Line segment 6.
MAP_FATAL[88] : Line failed.

time 0.000000 Calc_output: MAP_FATAL[59] : Approached a geometric limitation that the MSQS model is unable to solve. LMax = 151.414148 [m].
MAP_FATAL[59] : Approached a geometric limitation that the MSQS model is unable to solve. Line segment 6.
MAP_FATAL[88] : Line failed.

interval 0 Update_state: MAP_FATAL[59] : Approached a geometric limitation that the MSQS model is unable to solve. LMax = 151.414148 [m].
MAP_FATAL[59] : Approached a geometric limitation that the MSQS model is unable to solve. Line segment 7.
MAP_FATAL[88] : Line failed.

time 0.000000 Calc_output: MAP_FATAL[59] : Approached a geometric limitation that the MSQS model is unable to solve. LMax = 151.414148 [m].
MAP_FATAL[59] : Approached a geometric limitation that the MSQS model is unable to solve. Line segment 7.
MAP_FATAL[88] : Line failed.

interval 0 Update_state: MAP_FATAL[59] : Approached a geometric limitation that the MSQS model is unable to solve. LMax = 151.414148 [m].
MAP_FATAL[59] : Approached a geometric limitation that the MSQS model is unable to solve. Line segment 8.
MAP_FATAL[88] : Line failed.

time 0.000000 Calc_output: MAP_FATAL[59] : Approached a geometric limitation that the MSQS model is unable to solve. LMax = 151.414148 [m].
MAP_FATAL[59] : Approached a geometric limitation that the MSQS model is unable to solve. Line segment 8.
MAP_FATAL[88] : Line failed.



FAST_Linearize_T:FAST_Linearize_OP:map_JacobianPInput:MAP_FATAL[59] : Approached a geometric
limitation that the MSQS model is unable to solve. LMax = 151.414148 [m].
MAP_FATAL[59] : Approached a geometric limitation that the MSQS model is unable to solve. Line
segment 1.
MAP_FATAL[88] : Line failed.

map_JacobianPInput:MAP_CalcOutput:MAP_FATAL[59] : Approached a geometric limitation that the MSQS
model is unable to solve. LMax = 151.414148 [m].
MAP_FATAL[59] : Approached a geometric limitation that the MSQS model is unable to solve. Line
segment 1.
MAP_FATAL[88] : Line failed.

map_JacobianPInput:MAP_FATAL[59] : Approached a geometric limitation that the MSQS model is
unable to solve. LMax = 151.414148 [m].
MAP_FATAL[59] : Approached a geometric limitation that the MSQS model is unable to solve. Line
segment 2.
MAP_FATAL[88] : Line failed.

map_JacobianPInput:MAP_CalcOutput:MAP_FATAL[59] : Approached a geometric limitation that the MSQS
model is unable to solve. LMax = 151.414148 [m].
MAP_FATAL[59] : Approac

 OpenFAST encountered an error at simulation time 7000 of 7000 seconds.
 Simulation error level: FATAL ERROR

 Aborting OpenFAST.


E:\wake_offshore_Floating_2 Linearity (WindC)\1-1 Turbine_CoheU_TI8_PK\TLP_TrimC=0.001>

The error seems to relate to the linearization of the MAP module. I checked the default value of UnstrLen, and the length of 151.73m seems to be enough. Do you have any suggestions? Many thanks

Best regards,

Jason.Jonkman · December 1, 2022, 4:24pm

Dear @Jian.Zhang,

Regarding the tolerance used in linearization, TrimTol is documented here: https://openfast.readthedocs.io/en/main/_downloads/34ccdeedadaf5bb6cc3af05369c33b8b/DevelopmentPlan-SetPoint-Linearization.pdf.

Regarding AddBLin, I agree that it is often used to calibrate against wave tank data. But in this case, I was just suggesting to apply a small amount of damping to improve the steady-state convergence.

Regarding the MAP++ errors, these are likely generated because the perturbations used in the finite-differencing to calculate the Jacobians of MAP++ are too large for the TLP you are simulating. When the perturbations are too large, the perturbation could cause the line to go slack and invalidate the catenary equations used by MAP++. The solution would be to reduce the perturbation size used in the MAP++ linearization, requiring a recompile of OpenFAST.

Best regards,

Jian.Zhang · December 2, 2022, 3:38pm

Dear @Jason.Jonkman

I read the shared documentation, and I want to confirm one thing:

as the convergence is justified by the mean squared relative error of the output vector at the azimuth positions, ϵ_y^2 [j]=1/n_y ∑_i((y_0 [i]-Y_0 [i,j])/(y_ref [i] )) I want to confirm the output vector here are the parameters specified in different module outputs when LinOutputs=2?

Another thing is changing the perturbation size; I checked the MAP_Fortran_Types.f90 file and found the following part determines the perturbation size. As I am not familiar with source code, I want to know if it is complicated to change the perturbation size.

REAL(R8Ki)  :: du      !< determines size of the translational displacement perturbation for u (inputs) (fortran-only) [-]

Best regards,

Jason.Jonkman · December 2, 2022, 6:42pm

Dear @Jian.Zhang,

Regarding TrimTol, the set of outputs included in the relative error metric are not the user-selected outputs (write outputs) specified through the various OutLists. Instead, the set of outputs included in the relative error metric are the internal module-level outputs that are used to derive the module-level inputs in the module-to-module coupling. The number of outputs in this set is dictated by the modules enabled and the spatial discretization of those modules.

Regarding the perturbation sized used in MAP++, I agree that du is the variable, but you should never change a _Types.f90 file, which is auto-generated by the FAST Registry. Rather, du is defined in SUBROUTINE MAP_Init_Jacobian() of map.f90. You can change du there.

Best regards,

Jian.Zhang · December 3, 2022, 9:43am

Hi, Jason

Regarding the link slack error, the problem is solved by changing
from
p%LinParams%du=0.2_R8KiD2R * max(p%depth, 1.0_R8Ki)
to
p%LinParams%du=0.1_R8KiD2R * max(p%depth, 1.0_R8Ki)

However, the warning information “Linearization was forced at simulation end” still appeared with newly compiled OpenFAST with the simulation time of Tmax=7000s and the convergence tolerance of TrimTol ranging from 0.001 to 1.0. The time-marching results with TrimTol=0.001 are shown below

The results showed the issue might be caused by the slow attenuation process at the heave and yaw DOFs. Therefore, I tried to increase additional linear stiffness as C33=10000N/rad, C66=10000N-m/rad (AddCLin in HydroDyn). The warning information “Linearization was forced at simulation end” still appeared.

I want to confirm whether 1) you encountered such a problem for the TLP linearization without reducing the perturbation size in MAP++ and 2) any suggestions for finding the steady state without the above error.

Thank you very much.

Best regards,

Jason.Jonkman · December 3, 2022, 2:33pm

Dear @Jian.Zhang,

Yes, we’ve had issues with linearization of TLP models before and your solution is correct.

Did the addition of AddCLin(3,3) and (6,6) improve the attenuation? Perhaps you simply need to increase the damping even more.

Best regards,

Jian.Zhang · December 3, 2022, 3:07pm

Dear @Jason.Jonkman

Thank you for your explanation.

I will checked the simulation results late as I am not in the office.

One thing I am concerned is that If I choose to increase the AddCLin (3,3) and (6,6)，any suggestion to the upper values？ Or limited influence could be observed at the large value according to your simulation experience？

In theory，it might have no influence on the undamped free frequency，however the damped frequency will change with introduction of the platform damping force.

Another thing is that whether I need to add the relevant dampings to the platform in the nonlinear dynamic response？The default AddCLin matrix elements are zero in examples given in the r-test folder.

Many thanks.

Best regards，

Jason.Jonkman · December 3, 2022, 4:32pm

Dear @Jian.Zhang,

I would add a small amount of damping in heave and yaw only to ensure a steady-state response for linearization (but I haven’t tried to estimate the magnitude for your specific case). Again, you may be able to get around this by choosing better initial conditions in heave and yaw. If the damping is small, I would expect not expect it to have much impact on the eigensolution. You shouldn’t need to add this damping in nonlinear time-domain simulations.

Best regards,

Jian.Zhang · December 23, 2022, 3:04am

Dear @Jason.Jonkman

After a period of trial and error, the linearization of the 5MW wind turbine atop three different platforms has been finished, and some results are summarized below:

The influence of the initial conditions is critical to the convergence. The initial assumed values are usually ineffective, and the average values obtained from the first calculation might make sense.
Compared to the Semi and TLP platform, the spar cases find the steady state easier, whether under fixed rotor speeds or wind speeds.

Still, I have some questions:

how to determine the convergence value “TrimTol” in the .fst file.
In my cases, I adjusted the values to find an operating point. For example, the values for Semi, Spar, and TLP under the fixed rotor speeds were set as 0.01, 0.001, and 0.005, and for the various wind speeds, the counterparts were 0.001, 0.001, and 0.005.
how to consider the wave exciting load in the linearization process
After reading the paper “Verification of floating offshore wind linearization functionality in OpenFAST,” I realized the wave excitation force had been finished, and I ran well with your shared codes. However, in the current version, the “WaveMode=0 (still water)” is required in the linearization process. Thus, to my knowledge, the wave exciting force is not coupled in the linearized model. If so, is there any plan to implement this function?
how to deal with the warning related to the visualization
When I tried the visualization function with the following setting parameters

3   WrVTK           - VTK visualization data output: (switch) {0=none; 1=initialization data only; 2=animation; 3=mode shapes}
          1   VTK_type        - Type of VTK visualization data: (switch) {1=surfaces; 2=basic meshes (lines/points); 3=all meshes (debug)} [unused if WrVTK=0]
true          VTK_fields      - Write mesh fields to VTK data files? (flag) {true/false} [unused if WrVTK=0]
         50   VTK_fps         - Frame rate for VTK output (frames per second){will use closest integer multiple of DT} [used only if WrVTK=2 or WrVTK=3]

The warning related to the mooring module appeared. I did not know whether it made sense and whether it had a critical effect on the results.

I appreciate your help.
I wish you a Merry Christmas and a prosperous New Year.

Best regards,

Jian

Jason.Jonkman · December 23, 2022, 3:33pm

Dear @Jian.Zhang,

Here are my responses:

I don’t have an explicit answer regarding TrimTol. Naturally, if the time series is converging to a steady-state solution, a smaller value of TrimTol would take more time before a steady-state solution is identified and the solution would be a better representation of a steady-state condition than a larger value of TrimTol. Setting too large a value of TrimTol may allow a solution to be identified that is not really in steady state.
Setting WaveMod = 0 is required to ensure a steady-state condition is reached, but does not preclude wave-excitation loads from being included in the linearized solution. To include wave-excitation loads in the linearized solution, set ExctnMod = 2, which will introduce hydrodynamic states associated with wave excitation and a wave-elevation perturbation disturbance input (relative to the still-water condition) within the linearized model.
I’m actually not familiar with this error. Are you still able to generate the mode-shape visualization?

Best regards,

Abdelrahman.Hussein · March 3, 2023, 10:52am

Dear @Jason.Jonkman ,

Point 2 when enabling ExctnMod = 2, the file Barge.ssexctn is missing. Would you help me to generate that?
Thank you

Jason.Jonkman · March 3, 2023, 1:49pm

Dear @Abdelrahman.Hussein,

I’m not aware that NREL has generated a .ssexctn file for the ITI Energy barge.

The state-space wave-excitation data (.ssexctn) file can be generated by the SS_Excitation_Fitting toolbox, which is similar to the MATLAB-based SS_Fitting toolbox for wave-radiation, but for the wave-excitation solution. SS_Excitation_Fitting has been discussed on the OpenFAST issues page: Wave Excitation model generation in state-space (*.ssexctn input file) · Issue #397 · OpenFAST/openfast · GitHub. This issue suggests reaching out to Alan Wright for access to the toolbox. Unfortunately, Alan Wright has recently retired from NREL. I’m not sure why the SS_Excitation_Fitting was never released publicly, but I’ve now sent you the alpha release via WeTransfer.

Best regards,

Topic		Replies	Views
Problem in running Linearisation for Test13 Computer-Aided Engineering Software Tools	26	12892	March 23, 2017
Question about linearization FAST V7 Computer-Aided Engineering Software Tools	3	2704	March 31, 2021
Modeling of linear foundation for onshore turbine Structural Analysis	28	11642	October 10, 2024
Linearization with OpenFAST, off-diagonal elements of the mass and stiffness matrix Structural Analysis example	1	410	August 30, 2023
OpenFAST: Linearization of NREL 5MW Onshore Turbine Computer-Aided Engineering Software Tools	28	6341	January 20, 2022

Linearization off shore wind turbine

Related topics