I am using the FAST v8 to simulate the parked turbine under extreme conditions and the OC3-Hywind model is used. According to the user's guide (page. 34), the four feathers, BIPitch, BIPitchF, TpitManS and TpitManE should be set. Three questions are presented as follows.
1)However, I could not find the feather TpitManE in the FAST v8. So Could you tell me how to set the value of TpitManE to 0 according to the suggestion in user’s guide?
2)I am not sure if the parked turbine could be simulated properly when I only set above four feathers (Although I could not find the flag of TpitManE ). Could you give me some suggestions？
In fact, the wind speed at hub height is set to be 35m/s and the significant wave height is set to be 8m in our simulation, with the purpose of investigating the buckling moment of Hywind tower. However, the FAST v8 encountered an error during the simulation. The error information is added at the end. I guess the extreme winds and waves make the simulation broken, but I don’t know how to change the model to simulate the dynamics of parked turbine under extreme conditions.I fail to find the error by my own efforts, so I sincerely seek help. Could you help me？Thank you very much.
The error information:
Timestep: 5 of 600 seconds. Estimated final completion at 22:41:43.
FAST_Solution:CalcOutputs_And_SolveForInputs:SolveOption1:ED_HD_InputOutputSolve:HydroDyn_CalcOutp
ut: Angles in GetSmllRotAngs() are larger than 0.4 radians.
ED_HD_InputOutputSolve:HydroDyn_CalcOutput: Angles in GetSmllRotAngs() are larger than 0.4
radians.
FAST_Solution:CalcOutputs_And_SolveForInputs:SolveOption1:ED_HD_InputOutputSolve:HydroDyn_CalcOutp
ut: Angles in GetSmllRotAngs() are larger than 0.4 radians.
ED_HD_InputOutputSolve:HydroDyn_CalcOutput: Angles in GetSmllRotAngs() are larger than 0.4
radians.
FAST_Solution:FAST_AdvanceStates:AD_UpdateStates:BEMT_UpdateStates(node 5, blade
1):BEMT_UnCoupledSolve:DeterminePhiBounds:There is no valid value of phi for these operating
conditions! Vx = -2.50578E+05, Vy = 5.50555E+06, rlocal = 13.818, theta = 1.3634
FAST encountered an error at simulation time 5.9625 of 600 seconds.
Simulation error level: FATAL ERROR
The TPitManE input parameters for each blade have been replaced in FAST v8 with the PitManRat inputs, representing the pitch rates of the pitch maneuvers.
Regardless, to model a parked rotor in FAST v8, you should disable the generator DOF (GenDOF = False), disable active pitch control (PCMode = 0), initialize the rotor speed to zero, and initialize the blade-pitch angles to equal feathered pitch (usually 90 degrees). Then, the override pitch maneuvers are unused.
My guess is you are obtaining such large platform motion because you haven’t properly feathered the blades–see item (2) above.
I see that you are receiving an error related to the BEM solve in AeroDyn. However, normally the wake (induced-velocity) calculation should be disabled when modeling a parked rotor i.e. set WakeMod = 0 in AeroDyn v15.
I’m simulating the parked DeepCwind Semi (FAST Certest Test25) in no wave, no current and wind only condition (3m/s, steady wind, wind direction -90 deg(propagate to the positive y direction)).
My intention is to check the yaw characteristic of the DeepCwind Semi wind turbine. Therefore, I made the following settings:
I made the parked rotor setting as you mentioned in the above item (2) to Mr.Yichau.
I set all PtfmDoFs to false except yaw, thus the platform can only be able to rotate in yaw.
I set CompMooring=0 in Test25.fst to exclude the effect of mooring (this mean no mooring line will exist, am I correct?).
I change TwrShadow, TwrAero and Wakemod to false in the AeroDyn15 input file to turn off aerodynamic forces on the blades and tower.
My professor told me that even in such a case, the wind turbine will still have a yaw motion, until the wind turbine is facing the wind (which means the absolute value of PtfmYaw will be finally around 90 deg), due to the effect of nacelle drag, etc.
I ran this case, but got the following result which conflicts with above knowledge.The yaw motion exceeds 90 deg finally and is still increasing beyond 10000s.
I’m not sure if it is correct or not. Could you help confirm this? Am I wrong in some places of settings?
(For your references, I also attached the FAST input files.)
I briefly reviewed your input files, and my only concern is that you’ve kept the unsteady airfoil aerodynamics (UA) model (AFAeroMod=2) enabled in AeroDyn. This model is likely only valid for low to moderate angles of attack, but your simulation likely involves high angles of attack (AeroDyn is probably warning you about this and disabling UA at high angles of attack).
Regardless, while the initial platform-yaw rotation is likely reasonable for this simulation set-up, I doubt FAST would end up with a platform-yaw rotation of -90 degrees. Please keep in mind that the platform pitch, roll, and yaw rotational DOFs in the ElastoDyn module of FAST v8 (or the structural model of FAST v7) employ small-angle approximations (with no sequencing of rotations). While nonlinear corrections are included to maintain orthogonality, the platform rotational transformation loses considerable accuracy for rotation angles greater than about 20 deg. (The nacelle-yaw DOF has no such limitation and large angles are allowed.) ElastoDyn should be warning you about this. Thus, I wouldn’t trust the accuracy of the simulation for platform-yaw angles much beyond -20 degrees.
So could I confirm several points to check if my understanding is correct or not:
in steady wind I should disable unsteady airfoil aerodynamics (UA) model (change to AFAeroMod=1) in AeroDyn, and in turbulent wind I should enable the model (change to AFAeroMod=2).
Yes you are right, I’m receiving errors of ‘small angle approximation’ from FAST in the calculation. Is it possible to substitute the small angle approximation by large angle approximation? eg., like the following transformation matrix:
Should I disable the Nacelle DoF in the current model? I think my professor was referring to the fixed Nacelle yaw model when he said the conclusion. And where can I find the setting of Nacelle DoF in the FAST input files?
If everything is ok, I mean if I set AFAeroMod=1, disable Nacelle DoF and also change small angle approximation into large angle approximation in the FAST code. Should FAST end up with a platform-yaw rotation of -90 degrees? I mean, is my professor’s understanding (even nacelle drag in the -90 deg wind will finally make the platform free yaw to -90 deg motion) correct?
You don’t need to disable UA because of steady wind. Instead, UA should be disabled if the angles of attack are large, where the UA model is invaled (e.g. higher than 45 degrees angle of attack in absolute value).
We originally considered using Euler angles (or the like) in FAST for the platform rotations, but decided it would be sufficient (and simpler) to use small rotations. (Although with the correction for an orthonormal rotation matrix, any of the three angles can be moderate (about 20 degrees) before the approach loses considerable accuracy.) If you wish to modify the source code to use larger angles, you could introduce e.g. Euler angles, but this will effect more than just the rotation matrix – you’ll also have to change the platform rotation states and the associated way in which the rotational velocities and accelerations are calculated. And if you are using the coupling of FAST to the various offshore modules (SubDyn, HydroDyn), you would need to make changes there as well because these modules also assume small rotations. My guess is this would be a quite extensive change to the source code.
You could disable the nacelle-yaw DOF, but this is not necessary. The nacelle-yaw DOF is enabled in the NREL 5-MW turbine to simulate the small amount of compliance in the yaw drive. The nacelle-yaw DOF is enabled/disabled in the ElastoDyn primary input file.
I agree with your professor that in reality the platform would likely yaw to -90 degrees when the rotor is parked with the blades feathered under steady wind directed along the y axis.
Thanks to your comments, I modified the source code, mainly two subroutines (I share two examples of them in the attached file), to allow for large rotation angles. The two subroutines are: SmllRotTrans and GetSmllRotAngs (for readers please take notice of the variants R, D, DD). To simplify the modification, I haven’t changed the names of these subroutines.
I’m not quite sure whether I have made sufficient modifications on the code to resolve this problem. Because I’m not quite sure about what you have mentioned:“you’ll also have to change the platform rotation states and the associated way in which the rotational velocities and accelerations are calculated. And if you are using the coupling of FAST to the various offshore modules (SubDyn, HydroDyn), you would need to make changes there as well because these modules also assume small rotations”. Could you help confirm that whether I need to make further modifications or not?
The current simulation result seems to be exactly as expected, please see the following yaw motion histories for:
Fig 1. Case 1: noMooring+noTwrAeroLoads+WindOnly+YawDoFOnly (other DOFs fixed)
Fig 2. Case 2: SingleMoorLine+WithTwrAeroLoads+WindOnly+YawDoFOnly (other DOFs fixed)
The yaw motions finally go to 90 degs as expected.
I see that you’ve only changed the routines that define the rotational transformation (DCM) and to extract the angles from the DCM. Additional source code changed are required to compute large platform rotations accurately. For example, the rotational velocity of the platform in ElastoDyn is calculated in routine ElastoDyn.f90/CalculateAngularPosVelPAcc() and assumes that the three rotational DOFs are defined about the three orthogonal axes of the inertia frame. However, you’re rotational transformation assumes a given rotation sequence, only the first of which is a rotation about an axis of the inertia frame. (And there are many more examples.) As I said, implementing large platform rotations will likely require extensive changes to the FAST source code.
Apart from modifying the subroutine you mentioned of calculating the rotational velocity of the platform, do you think need I make the following large-angle rotational transformation matrix orthonormal, as you have done in Eq.(2-2) for the small-angle approximations?
If you have assembled your rotational transformation matrix properly e.g. through the use of an Euler angle sequence, the matrix should already be orthonormal.
Thank you for your quick response.
I would like to further confirm one point: because as you said, my rotational transformation assumes a given rotation sequence and only the first of which is rotating about an axis of the inertial frame, so in such case, is my rotational transformation still valid for large platform rotations? Should I further modify this rotational transformation matrix to make all the rotations be about the three axes of the inertial frame without any sequence? (Is it possible?)
Yes, your rotational transformation should be valid for large platform rotations. There are various choices for rotational parameters, but all Euler angle parameters assume a given sequence. The existing ElastoDyn module of FAST uses nonsequenced rotations about the inertia frame, but again, ElatsoDyn has invoked small angle assumptions to use this.
Yes, you are right, all Euler angle parameter assumes a rotation sequence. But I’m still confusing that should I use a nonsequenced rotation transformation in stead of Euler (or the like) for large platform rotations? Or in another word, does the existing ElastoDyn only accept the nonsequenced rotations?
Also, I do not quite understand the word “complications” you mentioned in your Thesis: “Consequently, I could avoid all the complications of using Euler angles(or the like), where the order of rotation is significant, when I derived and implemented the equations of motion in FAST”. Could you explain more details about the complications using Euler angles?
As I’ve explained, ElastoDyn was implemented assuming small angles and nonsequenced rotations. While there are several large-angle rotational parameters options (including Euler angles, Quaternions, Rodrigues parameters etc.), regardless of what you choose, you’ll have to update ElastoDyn and the rest of the source code consistently. But NREL does not have the resources to lay out the details for you. I would suggest reviewing literature on multi-body dynamics to understand the complications involved.
Dear Jason
I am encountering similar problem with simulation of IEC DLC1.6a of the OC3-Hywind. The wind speed 4m/s:2m/s:24m/s; Hs=13m, Tp=14s. Total simulation length is 3600s. Some realizations run without any errors, however a handful produce some errors as listed below:
Warning: SkewedWakeCorrection encountered a large value of chi (92.663 deg), so the yaw
correction will be limited. This warning will not be repeated though the condition may persist.
See the AD15 chi output channels, and consider turning off the Pitt/Peters skew model (set
SkewMod=1) if this condition persists.
FAST_Solution:FAST_AdvanceStates:ED_ABM4:ED_CalcContStateDeriv:SetCoordSy:Small angle assumption
violated in SUBROUTINE SmllRotTrans() due to a large platform displacement (ElastoDyn
SetCoordSy). The solution may be inaccurate. Simulation continuing, but future warnings from
SmllRotTrans() will be suppressed.
3)FAST_Solution:FAST_AdvanceStates:AD_UpdateStates:BEMT_UpdateStates(node 5, blade
1):BEMT_UnCoupledSolve:There is no valid value of phi for these operating conditions: Vx =
15.412, Vy = -155.28, rlocal = 11.747, theta = 0.23231, geometric phi = 3.0427. This warning will
not be repeated though the condition may persist. (See GeomPhi output channel.)
4)FAST_Solution:CalcOutputs_And_SolveForInputs:SolveOption1:ED_HD_InputOutputSolve:HydroDyn_CalcOutp
ut: Angles in GetSmllRotAngs() are larger than 0.4 radians.
ED_HD_InputOutputSolve:HydroDyn_CalcOutput: Angles in GetSmllRotAngs() are larger than 0.4
radians.
FAST_Solution:FAST_AdvanceStates:AD_UpdateStates:BEMT_UpdateStates(node 5, blade
3):BEMT_UnCoupledSolve:There is no valid value of phi for these operating conditions: Vx =
736.52, Vy = -3868.8, rlocal = 12.301, theta = 0.24172, geometric phi = 2.9535. This warning will
not be repeated though the condition may persist. (See GeomPhi output channel.)
FAST_Solution:CalcOutputs_And_SolveForInputs:SolveOption2:InflowWind_CalcOutput:CalcOutput:IfW_TSF
FWind_CalcOutput [position=(-726.12, 1629.9, 21.338) in wind-file coordinates]: FF wind array
boundaries violated: Grid too small in Y direction. Y=1629.9; Y boundaries = [-72.5, 72.5]
CalcOutputs_And_SolveForInputs:SolveOption1:ED_HD_InputOutputSolve:HydroDyn_CalcOutput: Angles in
GetSmllRotAngs() are larger than 0.4 radians.
ED_HD_InputOutputSolve:HydroDyn_CalcOutput: Angles in GetSmllRotAngs() are larger than 0.4
radians.
When I set CompAero=0, the simulation runs smoothly or if platform pitch DOF is disabled.
I have also tried smaller time steps (0.00125, 0.0001). These are the solutions I found from other posts.
I look forward to your invaluable advice.
Regards
Salem
Each of these errors have been discussed several times on this forum. Please search the keywords for each error to understand why these errors can be triggered and the solutions to resolving them.
Dear Jason
I have looked at several post and tried the suggestions given. I have reduced the time step to 0.00125 and 0.0001 yet the instability still occurs. I have set new ICs as well still no difference. However, I have found that when I disable platform pitch DOF all the simulations run smoothly. Please any pointers to how I can fix this issue would be greatly appreciated.
Regards
Salem
You are going to have to supply more information for me to answer your question:
Are you using the NREL-supplied FAST / OpenFAST model of the NREL-5MW turbine atop the OC3-Hywind spar or did you modify this model in some way? If you have not changed the geometry, mass, or stiffness, I would not expect that you’d have to modify the time step.
When you refer to an instability, what do you mean? Instability to me implies negative damping and an exponentially increasing response. What does the time series of turbine response look like (blade pitch, rotor speed, blade deflection, tower deflection, platform displacements)?
Time: 150 of 3660 seconds. Estimated final completion at 12:36:29.
Time: 151 of 3660 seconds. Estimated final completion at 12:35:57.
FAST_Solution:FAST_AdvanceStates:ED_ABM4:ED_CalcContStateDeriv:SetCoordSy:Small angle assumption
violated in SUBROUTINE SmllRotTrans() due to a large platform displacement (ElastoDyn
SetCoordSy). The solution may be inaccurate. Simulation continuing, but future warnings from
SmllRotTrans() will be suppressed.
Additional debugging message from SUBROUTINE SmllRotTrans(): 151.29 s
FAST_Solution:FAST_AdvanceStates:AD_UpdateStates:BEMT_UpdateStates(node 5, blade
1):BEMT_UnCoupledSolve:There is no valid value of phi for these operating conditions: Vx =
-9.289, Vy = -190.59, rlocal = 11.741, theta = 0.3637, geometric phi = -3.0929. This warning will
not be repeated though the condition may persist. (See GeomPhi output channel.)
FAST_Solution:CalcOutputs_And_SolveForInputs:SolveOption1:ED_HD_InputOutputSolve:HydroDyn_CalcOutp
ut: Angles in GetSmllRotAngs() are larger than 0.4 radians.
ED_HD_InputOutputSolve:HydroDyn_CalcOutput: Angles in GetSmllRotAngs() are larger than 0.4
radians.
FAST_Solution:CalcOutputs_And_SolveForInputs:SolveOption2:InflowWind_CalcOutput:CalcOutput:IfW_TSF
FWind_CalcOutput [position=(-1.40915E+05, 4895.1, 11719) in wind-file coordinates]: FF wind array
boundaries violated. Grid too small in Z direction (Z=11719 m is above the grid).
CalcOutputs_And_SolveForInputs:SolveOption1:ED_HD_InputOutputSolve:HydroDyn_CalcOutput: Angles in
GetSmllRotAngs() are larger than 0.4 radians.
ED_HD_InputOutputSolve:HydroDyn_CalcOutput: Angles in GetSmllRotAngs() are larger than 0.4
radians.
FAST encountered an error at simulation time 151.31 of 3660 seconds.
Simulation error level: FATAL ERROR
Aborting OpenFAST.
Yes I am using the NREL-supplied OpenFAST model of the NREL-5MW turbine atop the OC3-Hywind spar. I have not changed the FAST files, just the sea state and wind conditions for IEC DLC1.6a. I have also used BModes for getting modes shapes used in deriving polynomial coefficient used in FAST. these produce similar deflection as the coefficients supplied with OpenFAST (I ran simulations with these and the tower responses are alike).
