Unexpected Yaw Rate Transients in 14_open_loop_control

[abelvanweert]

Desired use case

At the moment i'm using the 14_open_loop_controller to generate any kind of yaw maneuver such that me and my team can study the effects of dynamic yawing on blade root and tower bending moments. However we encountered a weird bug, when using the olc.interp_series to apply any kind of yaw angle.

Description

When using the olc.interp_series for any kind of yaw angle maneuver, high yaw rates and accelerations are generated in the beginning of our simulations. This highly effects our computation time, because we need to wait a long time before the transients in the tower bending moment are gone, due to the bad damping of the tower.

My question for you guys is the following: Is there a way to prevent these high oscillations at the start of the simulation (thus prevent these high yaw rates and accelerations)?

Current behavior

Even though the yaw angle follows the given input nicely, the yaw rate (which communicates with OpenFAST) and yaw acceleration are not as expected and highly influence the applied loads and computation time.

Graphs of current behavior

Expected behavior

We would like to know where these high yaw rates and accelerations come from and how to mitigate this such that less big transients are generated and thus the computation time can be lowered.

The used code (edited 14_open_loop_control case)

Until now only static yaw angles are tested, this was done by slowly maneuvering to the desired yaw angle in the first seconds, staying in idle in the following seconds (to let transients die out) and then the real maneuver is applied.

`
Load a turbine, tune a controller with open loop control commands
In this example:

• Load a turbine from OpenFAST
• Tune a controller
• Write open loop inputs
• Run simple simulation with open loop control

Parameters
dt = 0.01
t_ramp = 200.0
t_wait = 500.0
t_maneuver = 600.0
begin_maneuver = t_ramp + t_wait
Windspeed = 10
Simulation_time = t_ramp + t_wait + t_maneuver
final_yaw_angle_degree = 20

Python Modules
import os
import matplotlib.pyplot as plt
import numpy as np
from openfast_toolbox.io import FASTOutputFile
from openfast_toolbox.postpro import equivalent_load
import pandas as pd

ROSCO toolbox modules
from rosco import discon_lib_path
from rosco.toolbox import controller as ROSCO_controller
from rosco.toolbox import turbine as ROSCO_turbine
from rosco.toolbox import utilities as ROSCO_utilities
from rosco.toolbox.ofTools.fast_io import output_processing
from rosco.toolbox.inputs.validation import load_rosco_yaml
from rosco.toolbox.ofTools.case_gen.CaseLibrary import set_channels
from rosco.toolbox.ofTools.case_gen.runFAST_pywrapper import runFAST_pywrapper, runFAST_pywrapper_batch
from rosco.toolbox.ofTools.case_gen.CaseGen_General import CaseGen_General

def main():
this_dir = os.path.dirname(os.path.abspath(file))
tune_dir = '/data/leuven/366/vsc36692/miniconda3/envs/science/ROSCO/Examples/Test_Cases/IEA-15-240-RWT/IEA-15-240-RWT-Monopile'

rosco_dir         = os.path.dirname(this_dir)
example_out_dir   = os.path.join(this_dir,'examples_out')
example_out_dir = os.path.join(this_dir,'examples_out')
if not os.path.isdir(example_out_dir):
    os.makedirs(example_out_dir)

 Load yaml file (Open Loop Case)


parameter_filename = os.path.join(tune_dir, 'IEA-15-240-RWT-Monopile_ROSCO.yaml')





inps = load_rosco_yaml(parameter_filename)
path_params         = inps['path_params']
turbine_params      = inps['turbine_params']
controller_params   = inps['controller_params']

 Set up open loop input
olc = ROSCO_controller.OpenLoopControl(t_max=Simulation_time)





 === YAW SIGNALS: ramp (0–200s) → wait (200–700s) → arbitrary maneuver (700–1300s) ===


----- Define PHASE 3 desired yaw signal (edit this for other maneuvers) -----

 Example 1: static yaw at 'final_yaw_angle_degree'

maneuver_angle_rad = np.deg2rad(final_yaw_angle_degree)

def yaw_maneuver_func(t_rel):
    # t_rel in [0, t_maneuver]
    return maneuver_angle_rad

# If later want something else --> replace yaw_maneuver_func

# Initial yaw to reach at end of ramp is the first value of phase-3 signal
yaw_target_init = yaw_maneuver_func(0.0)

# ----- Phase 1: triangular angle ramp (0–200s) to yaw_target_init -----

t1_up  = np.linspace(0, t_ramp/2, int(t_ramp/(2*dt)), endpoint=False)
t1_dn  = np.linspace(t_ramp/2, t_ramp, int(t_ramp/(2*dt)))

# quadratic-in/quadratic-out angle profile (integral of triangular velocity)

yaw_up = (yaw_target_init/2) * (t1_up/(t_ramp/2))**2
yaw_dn = yaw_target_init * (1 - 0.5*((t_ramp - t1_dn)/(t_ramp/2))**2)
time_phase1 = np.concatenate([t1_up, t1_dn])
yaw_phase1  = np.concatenate([yaw_up, yaw_dn])

# ----- Phase 2: wait (200–700s) -----

time_phase2 = np.linspace(time_phase1[-1] + dt,
                          time_phase1[-1] + t_wait,
                          int(t_wait/dt))
yaw_phase2  = np.full_like(time_phase2, yaw_target_init)

# ----- Phase 3: arbitrary maneuver (700–1300s) -----

time_phase3 = np.linspace(time_phase2[-1] + dt,
                          time_phase2[-1] + t_maneuver,
                          int(t_maneuver/dt))
yaw_phase3  = np.array([yaw_maneuver_func(t_rel) for t_rel in (time_phase3 - time_phase3[0])])

# ----- Combine & apply -----

yaw_times  = np.concatenate([time_phase1, time_phase2, time_phase3])
yaw_values = np.concatenate([yaw_phase1, yaw_phase2, yaw_phase3])

olc.interp_timeseries('nacelle_yaw', yaw_times, yaw_values, 'sigma')


  




# Plot open loop timeseries
fig,ax = olc.plot_timeseries()
if False:
    plt.show()
else:
    fig.savefig(os.path.join(example_out_dir,f'14_OL_Sim/Plots/14_OL_Inputs.png'))

# Write open loop input, get OL indices
ol_filename = os.path.join(example_out_dir,'14_OL_Input.dat')
ol_dict = olc.write_input(ol_filename)
controller_params['open_loop'] = ol_dict


# Instantiate turbine, controller, and file processing classes
turbine         = ROSCO_turbine.Turbine(turbine_params)
controller      = ROSCO_controller.Controller(controller_params)

# Load turbine data from OpenFAST and rotor performance text file
turbine.load_from_fast(path_params['FAST_InputFile'], \
os.path.join(tune_dir,path_params['FAST_directory']), \
    rot_source='txt',\
    txt_filename=os.path.join(tune_dir,path_params['rotor_performance_filename']))

# Tune controller 
controller.tune_controller(turbine)

# Write parameter input file
param_file = os.path.join(this_dir,'DISCON.IN')   # This must be named DISCON.IN to be seen by the compiled controller binary. 
ROSCO_utilities.write_DISCON(turbine,controller,param_file=param_file, txt_filename=path_params['rotor_performance_filename'])

### Run OpenFAST using aeroelasticse tools
case_inputs = {}
case_inputs[('ServoDyn','DLL_FileName')] = {'vals': [discon_lib_path], 'group': 0}
case_inputs[('ServoDyn','Ptch_Cntrl')] = {'vals': [1], 'group': 0}
case_inputs[('ServoDyn','YCMode')] = {'vals': [5], 'group': 0}
case_inputs[('ServoDyn','TYCOn')] = {'vals': [0], 'group': 0}
case_inputs[('ElastoDyn','YawDOF')] = {'vals': ['True'], 'group': 0}


# Apply all discon variables as case inputs
discon_vt = ROSCO_utilities.DISCON_dict(
turbine, 
controller, 
txt_filename=os.path.join(tune_dir,path_params['FAST_directory'],path_params['rotor_performance_filename'])
)
for discon_input in discon_vt:
    case_inputs[('DISCON_in',discon_input)] = {'vals': [discon_vt[discon_input]], 'group': 0}

case_inputs[('Fst','TMax')] = {'vals': [Simulation_time], 'group': 0}
case_inputs[('InflowWind','HWindSpeed')] = {'vals': [Windspeed], 'group': 0}
case_inputs[('DISCON_in','LoggingLevel')] = {'vals': [3], 'group': 0}

# Generate cases
run_dir = os.path.join(example_out_dir,'14_OL_Sim')
if not os.path.exists(run_dir):
    os.makedirs(run_dir)

case_list, case_name_list = CaseGen_General(case_inputs, dir_matrix=run_dir, namebase='OL_Example')
channels = set_channels()

# Run FAST cases
fastBatch                   = runFAST_pywrapper_batch()

fastBatch.FAST_directory    = os.path.realpath(os.path.join(tune_dir,path_params['FAST_directory']))
fastBatch.FAST_InputFile    = path_params['FAST_InputFile']        
fastBatch.channels          = channels
fastBatch.FAST_runDirectory = run_dir
fastBatch.case_list         = case_list
fastBatch.case_name_list    = case_name_list
fastBatch.debug_level       = 2
fastBatch.FAST_exe          = 'openfast'

fastBatch.run_serial()

......
`

[dzalkind]

It looks like you're starting the turbine at a non-zero yaw position and it is returning to 0. Note that YawNeut in ServoDyn needs to be set to the same value as NacYaw in ElastoDyn for non-zero initial yaw positions.

I would also not start the maneuver at 0 seconds. There will be transients no matter what, but they appear to dissipate in a reasonable amount of time (~30 sec.)

[abelvanweert]

Dear dzalkind,

The first plot shows the yaw position as you can see i start from a yaw angle of 0 degree and move to a yaw angle of 20 degree. The second plot show the yaw acceleration and the third plot is the yaw rate. These big yaw accelerations at the beginning highly affect the tower bending moments, which take way longer to settle down.

Or do you think something else causes these big transients?
It's just a pity of the loss of computation time. 1/2 of my simulation time is used to wait for transients to die out, the other half is for DEL calculation.

[dzalkind]

It's hard to tell what loads are due to transients and what is due to the maneuver that also starts at 0 degrees.

It also appears that you're using the monopile version of the IEA-15MW. The substructure dynamics in SubDyn could also be the cause of the transients. I would ensure there is a non-zero value for the yaw inertia here.

You might want to simplify your set up so there are no yaw maneuvers and pose the question in the OpenFAST or IEA forums.

[abelvanweert]

Dear Dzalkind,

For my case i want to test the 15MW in an onshore scenario, so things like SubDyn, Platform movement, ... are turned off.

[abelvanweert]

Is there a way to let my windturbine follow exactly my yaw profile, because if I zoom in on the yaw profile in the first seconds I notice these big oscillations? Is this maybe due to a sampling mismatch?

[abelvanweert]

Or would it be a better idea to just derive the position function to get the yaw rate function directly such that it can be given like this:

olc.interp_timeseries('yaw_rate', yaw_times, yaw_rate, 'sigma')

Or does the openloopcontroller function olc not accept yaw rate?

[abelvanweert]

@dzalkind ,

I’ve been running open-loop yaw simulations using the IEA-15-240-RWT turbine with the ROSCO controller.
Recently, I modified my setup so that:

There’s no pitching action (pitch controller disabled).
I run yaw angles from −20° to 20° in steps of 5°.
I run 30 cases in parallel.
Each simulation waits 1000 seconds before applying the yaw signal.

However, my tower-bottom side-to-side bending moment DELs (TwrBsMxt) still look strange and have the same non-ideal shape as before. As you can see it is highly unsymmetrical and you can see that the tower-bottom side-to-side bending moment for windspeed of 7 m/s is higher then for 11 m/s, which is strange.

Here’s what I currently see :

I’m trying to understand where this behavior could be coming from.
My main hypothesis is that it might be caused by the open-loop controller not handling the olc.interp_timeseries function correctly, which could be introducing small oscillations or ripples in the yaw signal.

To investigate, I compared wind speed = 11 m/s, yaw = 20° with wind speed = 7 m/s, yaw = 20°.
When zooming in on the yaw profiles:

In the following figures the 11 m/s case will always be on the left and the 7 m/s case will always be on the right

you can see these oscillations, which i don't think should be there.

The yaw rate fluctuations also show a noticeably larger amplitude at 11 m/s.

The yaw velocity that you see should just be a triangular profile, now it looks like a lot of noise is added.

But when looking at the tower-bottom bending moments, the profiles are very different. The 7 m/s case shows much larger oscillation amplitudes and also a different, some kind of modulated signal.

I’m wondering whether these oscillations are caused by my signal generation (interp_timeseries) or whether they’re a result of wind–structure interaction within OpenFAST itself or something else.

I’ve been stuck on this part for a few months now, so I’d really appreciate any insights or advice.
If anyone would like to look at more plots or parts of my Python code, I’d be happy to share them.

Thanks in advance for any help!
Best,
Abel Van Weert

[dzalkind]

Hi Abel,

The extra dynamics are due to stiffness and damping in the yaw degree of freedom in OpenFAST. I don't think it has to do with the open loop inputs.

An asymmetrical pattern in loading for yawed turbines is typical, due to the rotation and wind shear. You can find this in previous reports and articles.

I hope this helps.

Best, Dan

[abelvanweert]

Dear Dan @dzalkind ,

Thanks for the fast reply.
One final question, don't you think it's abnormal that a higher damage equivalent load for the tower bottom side to side bending moment is generated at lower windspeed then at the rated windspeed?

With kind regards,
Abel Van Weert

[dzalkind]

No, I don't think it's abnormal, but it would be good for your study to explore why this occurs. Generator torque variations can excite side-to-side motion. This is also where the rotor speed and tower mode can overlap and increase loading, so the controller will impact the loads in this region.

[abelvanweert]

@dzalkind I first thought this was indeed the case, that the blade passing frequency aligned with the towers natural frequency. But in this input file a minimal rotation speed was given such that this couldn't be the case.

I saw that it's also possible to just apply a speed exclusion zone, you think this might solve it?
Or should a notch filter be applied?
Or do you rather think it's something else that's causing this problem?

With kind regards,
Abel Van Weert

[dzalkind]

Hi Abel,

If the high side-to-side moments are occurring at specific rotor speeds, then an exclusion zone could be helpful.

If the frequency of the side-to-side moments are creating generator speed and torque variations at that frequency, a notch filter could be helpful.

I'm not sure what the cause of the loads that concern you are, so it's difficult for me to comment further.

Best, Dan

[abelvanweert]

Dear @dzalkind,

I recently tested a 5MW case as well to see how that different wind speeds and yaw misalignments influence the tower and blade bending moments. Here i forgot to put a minimal rpm and got great peaks at 6 & 7 m/s with yaw misalignment of -20 and 20 degrees. I thus noticed that this was caused by the blade passing frequency aligning with the towers natural frequency.

So now to prevent this from happening i applied a cut-in rpm of 6.9.
But never the less i still notice that the critical point remains at 6 & 7 m/s with yaw misalignment of -20 and 20. Of course only now the peaks are lower. Is this normal behavior or am i missing something.

I will give you as reference the TwrBsMxt before applying a cut-in rpm:

And after applying a cut-in rpm:

This looks to me like the same problem that the 15 MW case had. And I am eager to know why exactly this is the case (why are lower windspeeds of 6-7 m/s generating higher loads then higher windspeeds (11 m/s).

With kind regards,
Abel Van Weert

[dzalkind]

Side-to-side loads is most closely linked to generator torque, so I might investigated those variations.

[abelvanweert]

@dzalkind

I looked further into this and mostly put my attention on the case with windspeed of 6 & 7 m/s and yaw angle 30 degree. To see if the Side-to-side loads could be linked to generator torque variations i plotted the fourier transform of the GenTq, TwrbsMxt and RotSpeed. This gave me the following:

As you can see there is indeed a visible peak at the towers side-to-side natural frequency that could explain the side to side bending moment. To see if this also is the case for the 6 m/s case i also did the same for this case (As you can see in my previous plot that i send you 6 m/s also generates high bending moments). Plotting this spectrum gave me the following:

As you can see there is not really a big visible peak at the natural frequency (for GenTq). I'm thus still wondering to this moment what is causing these high side-to-side and fore-aft bending moments for the 7 & 6 m/s at yaw = 30 cases.

With kind regards,
Abel Van Weert

[dzalkind]

I don't think this is an issue with the ROSCO control software, so I'm going to convert this to a discussion post. Please feel free to continue the discussion there. I'm happy to answer questions you have about the controller and associated loads.