Challenges in designing TMD controller

Hi Jason,
We are trying to control the terrestrial NREL-5MW’s tower fore-aft vibrations through a kind of Tuned Mass and Damper (TMD) tool. You know there are blade pitch and generator torque controllers, which may be coupled with our TMD and worsen the performance.
What do you recommend to design and verify our TMD controller? Should we neglect your designed pitch and torque controllers from the model and investigate our TMD controller lonely? Or we must verify our controller in the presence of your or other complicated controllers?
What if the terrestrial turbine be replaced by an offshore one?

Dear Mehdi,

The objective of the torque and pitch controller is the regulate the rotor speed whereas I suspect the objective your TMD is to damping the tower vibrations, so, I would think you would need to verify your TMD together with the controller (otherwise, the rotor speed would not be regulated when verifying the TMD). Is the TMD active or passive? If active, you’ll have to decide if the TMD controller and pitch/torque controller are designed in one single controller or are independent control loops.

I hope that helps.

Best regards,

Hi Jason,

My name is Zhang Yinghao. I am a researcher in China. Recently I have been working on active structural control of floating wind turbines by OpenFAST.

Today, I ran into some problems. The OpenFAST software provides sub-modules for structural control, and passive structural control can be achieved. I have no idea how to achieve active control through these submodules.

Could you please give me some suggestions or examples that can be made public for reference. Thanks a lot.

Best regards.

Dear YingHao.Zhang,

The current Structural Control (StC) submodule of ServoDyn (as of OpenFAST v3.0) supports passive and semi-active contrl (StC_CMODE = 0 and 1), but active control (StC_CMODE = 2) is not supported. Are you referring to semi-active structural control?

Best regards,

Hi Jason,

I am very glad to receive your reply. First of all, please accept my apologies. Because I am not particularly skilled in using the forum, I failed to reply you in time.

I want to achieve active structural control. If the structural control submodule does not support active control, can I achieve active control by modifying the source code?

If yes, What files do I need to modify? If no, What are some ways to use OpenFAST for active structural control. Could you please give me some suggestions for reference. Thanks a lot.

Best regards.

Dear YingHao.Zhang,

The existing Structural Control (StC) submodule of ServoDyn is documented on OpenFAST readthedocs, including inputs, theory basis, and references: openfast.readthedocs.io/en/main … index.html.

Can you clarify what type of “active control” you are intending? I’m sure the source code can be modified if necessary, but it would help to know what you have in mind.

Best regards,

Hi Jason,

Thank you for your information, which is really helpful to me.

My idea is to put a TMD in the nacelle of the wind turbine(Only X degrees of freedom). To Design a controller(Logic of controller such as PID). The controller receives some state parameters of the wind(e.g. Tower-top fore-aft acceleration), an additional force is applied to TMD by an actuator such as a motor. To change the original motion state of TMD, so as to achieve active control effect.

What source code files do I need to modify to make my idea? Could you please give me some suggestions for reference. Thanks a lot.

Best regards.

Dear YingHao.Zhang,

Well, there is a placeholder in the source code for an external user-defined force. This is called F_ext in the StC theory documentation (openfast.readthedocs.io/en/main … heory.html) and stored as MiscVar F_ext in the StC source code (StrucCtrl.f90), which is allocated and set to zero by default. You can use this variable to define your force. It should not be too hard to implement controls logic directly in StrucCtrl.f90, but if you want to define the controls logic within ServoDyn, in the external DISCON controller, or in Simulink, this would involve changing many lines of code in various source files to pass the data from one place to another. This is the functionality that has not yet been implemented to support active control (StC_CMODE = 2).

Best regards,

Hi Jason,

Thank you very much for your advice, which is really helpful to me.

Now, I’m going to draw my idea as a flow chart, as a result, I don’t know the feasibility of the following ideas,

First, to provide input to control logic (Logic of controller such as PID), I need to extract the state parameter value of wind turbine from each time step, e.g. Tower-top fore-aft acceleration, as input to closed loop control. I don’t know if this can be done directly by modifying the source code in StrucCtrl.f90.

Then, for the output of control logic, the active control exerted on TMD, active structure control can be realized to directly optimize the state parameter values of wind turbines (e.g. Tower-top fore-aft acceleration). The size of this active control force depends on the optimal solution given by the control logic according to the input. In StrucCtrl.f90, can I design a parameter optimization algorithm to optimize the parameters (Such as kp or ki in PID) of the control logic so that it can quickly find the most appropriate F, that is, the optimal solution?

Could you please give me some suggestions for reference. Thanks a lot.

Best regards.

Hi Jason,

This picture shows my design idea

Best regards.

Dear YingHao.Zhang,

The tower-top acceleration is already known in the StC source code for a nacelle-based structural controller because that is a module-level input passed to StC by the calling program through the TranslationAcc field of the input point mesh. So, all you should need to do is implement the control logic you want to calculate the external force (F_ext) from this acceleration input.

Best regards,

Hi Jason,

Now I am modifying the source code. But I have some problems.

Your reply states that the tower-top acceleration has been referenced in the StC source code through the TranslationAcc field of the input point mesh.
I found this in the code—u%Mesh(i_pt)%TranslationAcc(:,1), Is that the tower-top acceleration?

TYPE(StC_InputType), INTENT(IN) :: u

I’m going to introduce u into my code, it’s going to appear error #6451: A dummy argument name is required in this context.

Could you please give me some suggestions for reference. Thanks a lot.

Best regards.

Hi Jason,

I want to add a F_EXT switch in NREloffSHRBsline5MW_servodyn_STC.dat ,

true Use_F_EXT - Use force from user-defined table (flag)

I have changed Input File data and Parameters in StrucCtrl Registry. TXT.

typedef ^^ LOGICAL Use_F_EXT - - - “use F_EXT (flag)” -

And I changed strucctrl.f90

! compute extra force( m%F_ext)
IF (p%Use_F_EXT) THEN
CALL StC_CalcExtraForce(x,p,m%F_ext)
ELSE
m%F_ext = 0.0_ReKi
END IF

But it didn’t work

Could you please give me some suggestions for reference. Thanks a lot.

Best regards.

Hi Jason,

Now I am modifying the source code. But I have some problems.

Your reply states that the tower-top acceleration has been referenced in the StC source code through the TranslationAcc field of the input point mesh.

I’ve introduced type u into my subroutine. Now I see that the acceleration is in the X,Y, and Z directions. Is u%Mesh(i_pt)%TranslationAcc(1,1) the acceleration in the x axis? Whether this variable can be regarded as Tower-top fore-aft acceleration?

Could you please give me some suggestions for reference. Thanks a lot.

Best regards.

Dear YingHao.Zhang,

Yes, u%Mesh(i_pt)%TranslationAcc(:,1) is the tower-top acceleration for a nacelle-based StC, where u%Mesh(i_pt)%TranslationAcc(1,1) is the acceleration in the global X direction, u%Mesh(i_pt)%TranslationAcc(2,1) is the acceleration in the global Y direction, and u%Mesh(i_pt)%TranslationAcc(3,1) is the acceleration in the global Z direction (in the global inertial-frame coordinate system). If you want the tower-top acceleration in a coordinate system local to the nacelle coordinate system rather than in the global coordinate system, premultiply u%Mesh(i_pt)%TranslationAcc(:,1) by u%Mesh(i_pt)%Orientation(:,:,1) as is done now within the StC source code using matmul().

Regarding your error, how did you introduce u into your code? u is already declared, so, you don’t need to declare it again. Simply use the value of u%Mesh(i_pt)%TranslationAcc(:,1) that is already passed.

Regarding adding input file parameter Use_F_EXT, what do you mean it didn’t work? Did you modify the code to read Use_F_EXT from the input file and store it in p%Use_F_EXT?

Best regards,

Hi Jason,

Thank you very much for your advice, which is really helpful to me. I have solved the above problem, which is inseparable from your help.

When I simulate the barge model at 18m/s,and after the TMD is added to the nacelle(only one, StC_X_DOF), the error in the picture will be generated,When I close the following degrees of freedom. I can work normally again. May I ask what is the reason for this? Is there any way to solve them?

False FlapDOF1 - First flapwise blade mode DOF (flag)
False FlapDOF2 - Second flapwise blade mode DOF (flag)
False EdgeDOF - First edgewise blade mode DOF (flag)

Could you please give me some suggestions for reference. Thanks a lot.

Best regards.

WARNING: High VNB velocity encountered during induction factor calculation. Blade number 1, Element number 17
VNW = 18.981, VNB = -109.02
FAST_Solution:FAST_AdvanceStates:ED_ABM4:ED_CalcContStateDeriv:SetCoordSy:Small angle assumption violated in SUBROUTINE SmllRotTrans() due to a large blade deflection (ElastoDyn SetCoordSy). The solution may be inaccurate. Simulation continuing, but future warnings from SmllRotTrans() will be suppressed.
Additional debugging message from SUBROUTINE SmllRotTrans(): 12.8 s
WARNING: High VNB velocity encountered during induction factor calculation. Blade number 1, Element number 14
VNW = 19.033, VNB = -113.11
WARNING: High VNB velocity encountered during induction factor calculation. Blade number 1, Element number 15
VNW = 19.018, VNB = -152.28
WARNING: High VNB velocity encountered during induction factor calculation. Blade number 1, Element number 16
VNW = 18.979, VNB = -184.9
WARNING: High VNB velocity encountered during induction factor calculation. Blade number 1, Element number 17
VNW = 18.984, VNB = -217.96
WARNING: Induced velocity warning written 5 times. The message will not be repeated, though the condition may persist.
FAST_Solution:CalcOutputs_And_SolveForInputs:SolveOption2:AD14_CalcOutput:ELEMFRC:BeddoesModel: ATTACH: Blade #1 element #16 is supersonic! Other elements are likely supersonic as well. Supersonic mach nos. will be set to 0.7 to attempt continuation.
AD14_CalcOutput:ELEMFRC:BeddoesModel:ATTACH: Supersonic condition has subsided with Blade #2 element #4.

Dear YingHao.Zhang,

Do you get this error only with your version of the StC module (where you made changes to the source code), or do you also get the error when using the original version (passive TMD, without your modified source code)? Have you tried reducing the time step (DT in the OpenFAST primary (*.fst) input file).

Best regards,

Hi Jason,

This problem occurs in both the original TMD version and my modified TMD version. I have tried to reduce the time step, but errors still occur. The blade speed is too fast.

Best regards.

Dear YingHao.Zhang,

Well, it looks like your model is going numerically unstable. I would first focus on the model without your source code changes and simplify the model to debug (e.g., by eliminating DOFs in ElastoDyn). Which DOF (or DOF), when enabled, cause the model to go unstable? How large is the TMD mass relative to the nacelle mass?

Best regards,

Hi Jason,

Below is my TMD configuration diagram, The model I’m using is 5MW_ITIBarge_DLL_WTurb_WavesIrr.

Another environmental factor is below:
wind speed 18m/s, turbulence intensity 15%, wave heigh 3.7m. Peak-spectral period of incident waves is 13.7.

In addition, I found that in the above working conditions, the TTDspFA data kept swinging on the positive half axis of X, rather than around the origin, during normal operation (without TMD). I don’t know whether this is the normal situation. When TMD is added, the operation of the fan may be affected due to this tilt.

Best regards.