# Tuning ROSCO controller with DISCON.IN

**URL:** <https://forums.nlr.gov/t/tuning-rosco-controller-with-discon-in/2458>\
**Category:** Controls\
**Created:** [April 30, 2021, 3:37pm UTC](https://forums.nlr.gov/t/tuning-rosco-controller-with-discon-in/2458 "2021-04-30T15:37:14Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Peter.Veldman](https://avatars.discourse-cdn.com/v4/letter/p/cdc98d/32.png) [@Peter.Veldman](https://forums.nlr.gov/u/Peter.Veldman)\
**Post date:** [April 30, 2021, 3:37pm UTC](https://forums.nlr.gov/t/tuning-rosco-controller-with-discon-in/2458/1 "2021-04-30T15:37:14Z")

</div>

Dear NREL team,

I am running aero-hydro-servo-elastic simulations of the 15MW NREL offshore reference wind turbine, using specific aero-elastic and hydrodynamic software. The aero-elastic software I use supports the bladed-style communication interface. Therefore I am using the ROSCO controller version 2.1.1 obtained from [url][https://github.com/NREL/ROSCO/tags[/url]](https://github.com/NREL/ROSCO/tags%5B/url%5D).

From the simulations it becomes clear (as expected) that there is a lot of blade-pitch action going on around the natural floater pitch frequency. If I understand correctly, the ROSCO controller allows for a “parallel compensation” which is an additional feedback term on the blade pitch control signal. The tower-top accelerations signal is filtered, integrated and multiplied times a proportional gain, which is added to the standard blade pitch control signal. This floating controller module, inside DISCON.IN, is the one I should change when a floater with different motion characteristics is used.

The floater which I am investigating has a natural pitch period of around 0.15 rad/s (changes along with floater offset due to the mooring stiffness). Therefore I want to attenuate the blade pitch control in the region of around 0.15 - 0.18 rad/s.

Now, my question is: what parameters in the DISCON.IN file should I change in order to reach the intended result (attenuating the aerodynamic thrust)?

Changing the F\_FlCornerFreq (Natural frequency and damping in the second order low pass filter of the tower-top fore-aft motion for floating feedback control) does not give the desired result. I also looked into the sensitivity of the Fl\_Kp (Nacelle velocity proportional feedback gain) by just dividing and multiplying the original gain by 2. While this has a big effect, I am not sure if this is the correct approach and how to converge to a correct gain.

Thanks in advance.

Kind regards,

Peter Veldman

DISCON.IN:

[code]! Controller parameter input file for the IEA-15-240-RWT\_semi wind turbine  
! - File written using ROSCO Controller tuning logic on 04/21/20

!------- DEBUG ------------------------------------------------------------  
1 ! LoggingLevel - {0: write no debug files, 1: write standard output .dbg-file, 2: write standard output .dbg-file and complete avrSWAP-array .dbg2-file}

!------- CONTROLLER FLAGS -------------------------------------------------  
2 ! F\_LPFType - {1: first-order low-pass filter, 2: second-order low-pass filter}, [rad/s] (currently filters generator speed and pitch control signals  
2 ! F\_NotchType - Notch on the measured generator speed and/or tower fore-aft motion (for floating) {0: disable, 1: generator speed, 2: tower-top fore-aft motion, 3: generator speed and tower-top fore-aft motion}  
0 ! IPC\_ControlMode - Turn Individual Pitch Control (IPC) for fatigue load reductions (pitch contribution) {0: off, 1: 1P reductions, 2: 1P+2P reductions}  
2 ! VS\_ControlMode - Generator torque control mode in above rated conditions {0: constant torque, 1: constant power, 2: TSR tracking PI control}  
1 ! PC\_ControlMode - Blade pitch control mode {0: No pitch, fix to fine pitch, 1: active PI blade pitch control}  
0 ! Y\_ControlMode - Yaw control mode {0: no yaw control, 1: yaw rate control, 2: yaw-by-IPC}  
1 ! SS\_Mode - Setpoint Smoother mode {0: no setpoint smoothing, 1: introduce setpoint smoothing}  
2 ! WE\_Mode - Wind speed estimator mode {0: One-second low pass filtered hub height wind speed, 1: Immersion and Invariance Estimator, 2: Extended Kalman Filter}  
1 ! PS\_Mode - Pitch saturation mode {0: no pitch saturation, 1: implement pitch saturation}  
0 ! SD\_Mode - Shutdown mode {0: no shutdown procedure, 1: pitch to max pitch at shutdown}  
1 ! Fl\_Mode - Floating specific feedback mode {0: no nacelle velocity feedback, 1: nacelle velocity feedback}  
0 ! Flp\_Mode - Flap control mode {0: no flap control, 1: steady state flap angle, 2: Proportional flap control}

!------- FILTERS ----------------------------------------------------------  
1.00810 ! F\_LPFCornerFreq - Corner frequency (-3dB point) in the low-pass filters, [rad/s]  
0.70000 ! F\_LPFDamping - Damping coefficient [used only when F\_FilterType = 2]  
3.12 ! F\_NotchCornerFreq - Natural frequency of the notch filter, [rad/s]  
0.00000 0.25000 ! F\_NotchBetaNumDen - Two notch damping values (numerator and denominator, resp) - determines the width and depth of the notch, [-]  
0.628320000000 ! F\_SSCornerFreq - Corner frequency (-3dB point) in the first order low pass filter for the setpoint smoother, [rad/s].  
0.15 1.00000 ! F\_FlCornerFreq - Natural frequency and damping in the second order low pass filter of the tower-top fore-aft motion for floating feedback control [rad/s, -].  
1.16240 1.00000 ! F\_FlpCornerFreq - Corner frequency and damping in the second order low pass filter of the blade root bending moment for flap control [rad/s, -].

!------- BLADE PITCH CONTROL ----------------------------------------------  
28 ! PC\_GS\_n - Amount of gain-scheduling table entries  
0.064065 0.091441 0.113134 0.131901 0.148787 0.164298 0.178797 0.192476 0.205467 0.217906 0.229898 0.241557 0.252756 0.263645 0.274434 0.284672 0.294952 0.304789 0.314694 0.324122 0.333781 0.342816 0.352034 0.361052 0.369784 0.378753 0.387278 0.395688 ! PC\_GS\_angles - Gain-schedule table: pitch angles  
-1.273191 -1.100149 -0.958278 -0.839852 -0.739503 -0.653385 -0.578671 -0.513238 -0.455456 -0.404058 -0.358041 -0.316603 -0.279092 -0.244975 -0.213811 -0.185234 -0.158933 -0.134648 -0.112155 -0.091262 -0.071805 -0.053641 -0.036645 -0.020708 -0.005734 0.008362 0.021655 0.034212 ! PC\_GS\_KP - Gain-schedule table: pitch controller kp gains  
-0.132832 -0.119684 -0.108904 -0.099906 -0.092281 -0.085737 -0.080060 -0.075088 -0.070698 -0.066792 -0.063296 -0.060147 -0.057297 -0.054705 -0.052337 -0.050165 -0.048167 -0.046322 -0.044612 -0.043025 -0.041547 -0.040166 -0.038875 -0.037664 -0.036526 -0.035455 -0.034445 -0.033491 ! PC\_GS\_KI - Gain-schedule table: pitch controller ki gains  
0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 ! PC\_GS\_KD - Gain-schedule table: pitch controller kd gains  
0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 ! PC\_GS\_TF - Gain-schedule table: pitch controller tf gains (derivative filter)  
1.570800000000 ! PC\_MaxPit - Maximum physical pitch limit, [rad].  
0.000000000000 ! PC\_MinPit - Minimum physical pitch limit, [rad].  
0.034900000000 ! PC\_MaxRat - Maximum pitch rate (in absolute value) in pitch controller, [rad/s].  
-0.03490000000 ! PC\_MinRat - Minimum pitch rate (in absolute value) in pitch controller, [rad/s].  
0.791680000000 ! PC\_RefSpd - Desired (reference) HSS speed for pitch controller, [rad/s].  
0.000000000000 ! PC\_FinePit - Record 5: Below-rated pitch angle set-point, [rad]  
0.017450000000 ! PC\_Switch - Angle above lowest minimum pitch angle for switch, [rad]

!------- INDIVIDUAL PITCH CONTROL -----------------------------------------  
0.0 ! IPC\_IntSat - Integrator saturation (maximum signal amplitude contribution to pitch from IPC), [rad]  
0.0 0.0 ! IPC\_KI - Integral gain for the individual pitch controller: first parameter for 1P reductions, second for 2P reductions, [-]  
0.0 0.0 ! IPC\_aziOffset - Phase offset added to the azimuth angle for the individual pitch controller, [rad].  
0.0 ! IPC\_CornerFreqAct - Corner frequency of the first-order actuators model, to induce a phase lag in the IPC signal {0: Disable}, [rad/s]

!------- VS TORQUE CONTROL ------------------------------------------------  
96.55000000000 ! VS\_GenEff - Generator efficiency mechanical power → electrical power, [should match the efficiency defined in the generator properties!], [%]  
19624046.66639 ! VS\_ArSatTq - Above rated generator torque PI control saturation, [Nm]  
4500000.000000 ! VS\_MaxRat - Maximum torque rate (in absolute value) in torque controller, [Nm/s].  
21586451.33303 ! VS\_MaxTq - Maximum generator torque in Region 3 (HSS side), [Nm].  
0.000000000000 ! VS\_MinTq - Minimum generator (HSS side), [Nm].  
0.523600000000 ! VS\_MinOMSpd - Optimal mode minimum speed, cut-in speed towards optimal mode gain path, [rad/s]  
33732396.86935 ! VS\_Rgn2K - Generator torque constant in Region 2 (HSS side), [N-m/(rad/s)^2]  
15000000.00000 ! VS\_RtPwr - Wind turbine rated power [W]  
19624046.66639 ! VS\_RtTq - Rated torque, [Nm].  
0.791680000000 ! VS\_RefSpd - Rated generator speed [rad/s]  
1 ! VS\_n - Number of generator PI torque controller gains  
-38609162.66552 ! VS\_KP - Proportional gain for generator PI torque controller [1/(rad/s) Nm]. (Only used in the transitional 2.5 region if VS\_ControlMode =/ 2)  
-4588245.18720 ! VS\_KI - Integral gain for generator PI torque controller [1/rad Nm]. (Only used in the transitional 2.5 region if VS\_ControlMode =/ 2)  
9.00 ! VS\_TSRopt - Power-maximizing region 2 tip-speed-ratio [rad].

!------- SETPOINT SMOOTHER ---------------------------------------------  
1.00000 ! SS\_VSGain - Variable speed torque controller setpoint smoother gain, [-].  
0.00100 ! SS\_PCGain - Collective pitch controller setpoint smoother gain, [-].

!------- WIND SPEED ESTIMATOR ---------------------------------------------  
120.000 ! WE\_BladeRadius - Blade length (distance from hub center to blade tip), [m]  
1 ! WE\_CP\_n - Amount of parameters in the Cp array  
0.0 0.0 0.0 0.0 ! WE\_CP - Parameters that define the parameterized CP(lambda) function  
0.0 ! WE\_Gamma - Adaption gain of the wind speed estimator algorithm [m/rad]  
1.0 ! WE\_GearboxRatio - Gearbox ratio [\>=1], [-]  
318628138.00000 ! WE\_Jtot - Total drivetrain inertia, including blades, hub and casted generator inertia to LSS, [kg m^2]  
1.225 ! WE\_RhoAir - Air density, [kg m^-3]  
“Cp\_Ct\_Cq.IEA15MW.txt” ! PerfFileName - File containing rotor performance tables (Cp,Ct,Cq)  
104 72 ! PerfTableSize - Size of rotor performance tables, first number refers to number of blade pitch angles, second number referse to number of tip-speed ratios  
44 ! WE\_FOPoles\_N - Number of first-order system poles used in EKF  
3.00 3.50 4.00 4.50 5.00 5.50 6.00 6.50 7.00 7.50 8.00 8.50 9.00 9.50 10.00 10.50 11.09 11.59 12.09 12.59 13.09 13.59 14.09 14.59 15.09 15.59 16.09 16.59 17.09 17.59 18.09 18.59 19.09 19.59 20.09 20.59 21.09 21.59 22.09 22.59 23.09 23.59 24.09 24.59 ! WE\_FOPoles\_v - Wind speeds corresponding to first-order system poles [m/s]  
-0.02366483 -0.02760896 -0.03155310 -0.03549724 -0.03944138 -0.04338551 -0.04732965 -0.05127379 -0.05521793 -0.05916206 -0.06310620 -0.06705034 -0.07099448 -0.07493861 -0.07888275 -0.08282689 -0.05297576 -0.05605471 -0.06299641 -0.07197232 -0.08228907 -0.09357435 -0.10567394 -0.11844707 -0.13176547 -0.14562128 -0.16003276 -0.17507351 -0.19032493 -0.20602365 -0.22255106 -0.23876816 -0.25602518 -0.27307271 -0.29115170 -0.30880313 -0.32785309 -0.34593703 -0.36525166 -0.38468218 -0.40394579 -0.42458588 -0.44445660 -0.46456892 ! WE\_FOPoles - First order system poles

!------- YAW CONTROL ------------------------------------------------------  
0.0 ! Y\_ErrThresh - Yaw error threshold. Turbine begins to yaw when it passes this. [rad^2 s]  
0.0 ! Y\_IPC\_IntSat - Integrator saturation (maximum signal amplitude contribution to pitch from yaw-by-IPC), [rad]  
1 ! Y\_IPC\_n - Number of controller gains (yaw-by-IPC)  
0.0 ! Y\_IPC\_KP - Yaw-by-IPC proportional controller gain Kp  
0.0 ! Y\_IPC\_KI - Yaw-by-IPC integral controller gain Ki  
0.0 ! Y\_IPC\_omegaLP - Low-pass filter corner frequency for the Yaw-by-IPC controller to filtering the yaw alignment error, [rad/s].  
0.0 ! Y\_IPC\_zetaLP - Low-pass filter damping factor for the Yaw-by-IPC controller to filtering the yaw alignment error, [-].  
0.0 ! Y\_MErrSet - Yaw alignment error, set point [rad]  
0.0 ! Y\_omegaLPFast - Corner frequency fast low pass filter, 1.0 [Hz]  
0.0 ! Y\_omegaLPSlow - Corner frequency slow low pass filter, 1/60 [Hz]  
0.0 ! Y\_Rate - Yaw rate [rad/s]

!------- TOWER FORE-AFT DAMPING -------------------------------------------  
-1 ! FA\_KI - Integral gain for the fore-aft tower damper controller, -1 = off / \>0 = on [rad s/m] - !NJA - Make this a flag  
0.0 ! FA\_HPF\_CornerFreq - Corner frequency (-3dB point) in the high-pass filter on the fore-aft acceleration signal [rad/s]  
0.0 ! FA\_IntSat - Integrator saturation (maximum signal amplitude contribution to pitch from FA damper), [rad]

!------- MINIMUM PITCH SATURATION -------------------------------------------  
44 ! PS\_BldPitchMin\_N - Number of values in minimum blade pitch lookup table (should equal number of values in PS\_WindSpeeds and PS\_BldPitchMin)  
3.00 3.50 4.00 4.50 5.00 5.50 6.00 6.50 7.00 7.50 8.00 8.50 9.00 9.50 10.00 10.50 11.09 11.59 12.09 12.59 13.09 13.59 14.09 14.59 15.09 15.59 16.09 16.59 17.09 17.59 18.09 18.59 19.09 19.59 20.09 20.59 21.09 21.59 22.09 22.59 23.09 23.59 24.09 24.59 ! PS\_WindSpeeds - Wind speeds corresponding to minimum blade pitch angles [m/s]  
0.06981317 0.06981317 0.06544985 0.05672320 0.04799655 0.03490659 0.02617994 0.00872665 -0.01745329 -0.01745329 -0.01745329 -0.01745329 -0.01096058 0.02043054 0.04426907 0.06340170 0.07720696 0.08784519 0.09811110 0.10810992 0.11787911 0.12742889 0.13680695 0.14602761 0.15508707 0.16402141 0.17286494 0.18166247 0.19028138 0.19882038 0.20741910 0.21571175 0.22414599 0.23233213 0.24065712 0.24869393 0.25697817 0.26483569 0.27290279 0.28085978 0.28864680 0.29667058 0.30437206 0.31202925 ! PS\_BldPitchMin - Minimum blade pitch angles [rad]

!------- SHUTDOWN -----------------------------------------------------------  
0.395690000000 ! SD\_MaxPit - Maximum blade pitch angle to initiate shutdown, [rad]  
0.418880000000 ! SD\_CornerFreq - Cutoff Frequency for first order low-pass filter for blade pitch angle, [rad/s]

!------- Floating -----------------------------------------------------------  
-9.36350000000 ! Fl\_Kp - Nacelle velocity proportional feedback gain [s]

!------- FLAP ACTUATION -----------------------------------------------------  
0.000000000000 ! Flp\_Angle - Initial or steady state flap angle [rad]  
0.00000000e+00 ! Flp\_Kp - Blade root bending moment proportional gain for flap control [s]  
0.00000000e+00 ! Flp\_Ki - Flap displacement integral gain for flap control [s]  
0.000000000000 ! Flp\_MaxPit - Maximum (and minimum) flap pitch angle [rad][/code]

 ![PSD_bladepitch_thrust.png](https://europe1.discourse-cdn.com/nrel/original/2X/8/8304188ebefa9007aa9b57ae787be16be5580e98.png)

---

<div class="post-metadata">

**Author:** ![Nikhar.Abbas](https://avatars.discourse-cdn.com/v4/letter/n/3da27b/32.png) [@Nikhar.Abbas](https://forums.nlr.gov/u/Nikhar.Abbas)\
**Post date:** [April 30, 2021, 5:24pm UTC](https://forums.nlr.gov/t/tuning-rosco-controller-with-discon-in/2458/2 "2021-04-30T17:24:20Z")

</div>

Hi Peter,  
It sounds like you are on the right track with all of this and you certainly seem to understand the general workflow of how the parallel compensation term is included.

As long as the floating feedback filter’s parameters (F\_FlConerFreq) do not exclude the platform’s natural frequency, I wouldn’t expect much to change in this region as you modify them. As you have found, tuning of Fl\_Kp is where you will likely see the greatest affect on the platform’s pitching.

Some details of this are discussed in the WES pre-print about ROSCO: [url][https://wes.copernicus.org/preprints/wes-2021-19/wes-2021-19.pdf[/url]](https://wes.copernicus.org/preprints/wes-2021-19/wes-2021-19.pdf%5B/url%5D)

Notably, the automated tuning of the floating feedback gain in the current implementation of the ROSCO toolbox is entirely rooted in the rotor’s dynamics. This is certainly a bit of a “first-pass” at this sort of automated tuning and there is definitely room for improvement. I think it makes sense that a different floater might warrant different gains for this term, so modifying Fl\_Kp should help.

So, again, I think you’re on the right track - I would continue to modify the Fl\_Kp term to improve the performance as you see fit. Some modifications of the filter parameters might help in certain cases as well, but not as much as the Fl\_Kp term will.

Cheers,  
Nikhar

---

<div class="post-metadata">

**Author:** ![Peter.Veldman](https://avatars.discourse-cdn.com/v4/letter/p/cdc98d/32.png) [@Peter.Veldman](https://forums.nlr.gov/u/Peter.Veldman)\
**Post date:** [May 5, 2021, 6:51pm UTC](https://forums.nlr.gov/t/tuning-rosco-controller-with-discon-in/2458/3 "2021-05-05T18:51:14Z")

</div>

Dear Nikhar,

Thanks a lot for your reply.

Like you recommended I continued to modify the floating feedback gain (Fl\_Kp term). To investigate the ROSCO controller behavior on the floating system for different floating feedback gains, I performed platform pitch decay tests in constant wind and calm water (i.e. no waves/current).

From the analyses it became very clear that when the floating feedback loop in the controller is excluded, the platform pitch motion in the above-rated condition is not stable. Additionally, if the feedback loop is included, the “original” Fl\_Kp of -9.36 [s] does not seem to have sufficient damping. By increasing the absolute value of the feedback gain by more than a factor 10, the platform pitch behaves like intended (positively damped). Moreover, this feedback gain of -100 seems to have a positive effect on tower base loads as well. Do you think this very large gain used in the DISCON.IN file is a reasonable/realistic value?

Kind regards,

Peter Veldman

 ![decay_underrated_ROSCO_controllers.png](https://europe1.discourse-cdn.com/nrel/original/2X/c/cb662e5a57381ee487af7648df3b7de11a307c87.png)  
 ![decay_aboverated_ROSCO_controllers.png](https://europe1.discourse-cdn.com/nrel/original/2X/4/498b76bf53e6755a71ec4f5fcf79a236523ff956.png)

---

<div class="post-metadata">

**Author:** ![Nikhar.Abbas](https://avatars.discourse-cdn.com/v4/letter/n/3da27b/32.png) [@Nikhar.Abbas](https://forums.nlr.gov/u/Nikhar.Abbas)\
**Post date:** [May 13, 2021, 4:01pm UTC](https://forums.nlr.gov/t/tuning-rosco-controller-with-discon-in/2458/4 "2021-05-13T16:01:12Z")

</div>

Hi Peter,  
Sorry about the delay on this response!

In short, it could be reasonable to have a gain this high, though it is certainly higher than I would expect.

The improved damping of the system in your plots does suggest that a gain this high might be useful. That said, I would be cautious to specifically tune this damping value for near-rated operation with no waves. This does tend to be the “worst-case” scenario in our simulations, but will likely result in overly aggressive gains in nearly every other case. In my experience tuning this controller, a gain that successfully stabilizes the worst-case scenario adequately (but not aggressively) can result in better global performance. It might be good to test this gain value in some turbulent scenarios to see if floating platform damping that is this aggressive is, indeed, what you want to have. If that is the case, I see no problems with increasing it by a factor of 10, as you have suggested.

As I mentioned in my previous response, we do not expect the floating feedback gain coming from the the current tuning process to be a perfect gain. As you have shown, it produces a stabilizing controller, but can certainly be improved upon. Another thing to note: an improved controller structure might have a pitch or wind speed dependent floating feedback gain schedule such that it can be more aggressive in these unstable near-rated scenarios and less aggressive in higher wind speeds where the negative damping problem is less of a concern. We are working on implementing capabilities for this in the coming months, so if you are interested in something like this, keep an eye on the ROSCO toolbox!

Cheers,  
Nikhar

---

<div class="post-metadata">

**Author:** ![Salem.Okpokparoro](https://avatars.discourse-cdn.com/v4/letter/s/848f3c/32.png) [@Salem.Okpokparoro](https://forums.nlr.gov/u/Salem.Okpokparoro)\
**Post date:** [November 4, 2022, 12:19pm UTC](https://forums.nlr.gov/t/tuning-rosco-controller-with-discon-in/2458/5 "2022-11-04T12:19:19Z")

</div>

Hi @Nikhar.Abbas,  
For robust tuning with ROSCO using linearized model of the FWT, I take it the tuning is done in class LinearControlModel(object)? My FWT model is linearized with DNV Bladed hence the format of the linearization files is different from those of OpenFAST. No details of such robust tuning was contained in the ROSCO publication. Would appreciate any paper from which the tuning was formulated or any advice on what I need to feed into LinearControlMode to run the tuning.

Additionally, for the setting of VS\_MinOMSpd (if this is HSS speed rather than rotor speed, hence vs\_minspd in the input yaml maybe is generator speed rather than rotor speed?). If so, when gear ratio (Ng) \> 1, perhaps multiplying by Ng as below is in order? This was how I was able to get appropriate rotor speed constraint for my simulations:

if self.vs\_minspd:  
self.vs\_minspd = np.maximum(self.vs\_minspd, (turbine.TSR\_operational \* turbine.v\_min /  
turbine.rotor\_radius) \* Ng)  
else:  
self.vs\_minspd = (turbine.TSR\_operational \* turbine.v\_min / turbine.rotor\_radius) \* Ng  
self.pc\_minspd = self.vs\_minspd

Regards  
Salem

---

<div class="post-metadata">

**Author:** ![Daniel.Zalkind](https://avatars.discourse-cdn.com/v4/letter/d/5daacb/32.png) [@Daniel.Zalkind](https://forums.nlr.gov/u/Daniel.Zalkind)\
**Post date:** [November 4, 2022, 3:56pm UTC](https://forums.nlr.gov/t/tuning-rosco-controller-with-discon-in/2458/6 "2022-11-04T15:56:53Z")

</div>

Hi Salem,

Our paper about robust tuning is still under review. [Here](https://github.com/NREL/ROSCO/blob/main/Examples/example_12.py) is a link to an example in our repository. You could compare this method and the linear models used in it with what you have.

At [this point](https://github.com/NREL/ROSCO/blob/51629665d22f92770f861daeebcebd47ab32abb1/ROSCO_toolbox/controller.py#L319) in the ROSCO\_Toolbox, `self.vs_minspd` is the rotor speed. When the DISCON is written, it is converted to the generator speed [here](https://github.com/NREL/ROSCO/blob/51629665d22f92770f861daeebcebd47ab32abb1/ROSCO_toolbox/utilities.py#L445).

I hope this helps.

Best, Dan

---

<div class="post-metadata">

**Author:** ![Salem.Okpokparoro](https://avatars.discourse-cdn.com/v4/letter/s/848f3c/32.png) [@Salem.Okpokparoro](https://forums.nlr.gov/u/Salem.Okpokparoro)\
**Post date:** [November 6, 2022, 9:37pm UTC](https://forums.nlr.gov/t/tuning-rosco-controller-with-discon-in/2458/7 "2022-11-06T21:37:30Z")

</div>

Hi @Nikhar.Abbas,  
Many thanks for your feedback. I have been working with ROSCO version 2.3.0 in which VS\_MinOMSpdwas written with:  
file.write(‘{:\<014.5f} ! VS\_MinOMSpd - Optimal mode minimum speed, cut-in speed towards optimal mode gain path, [rad/s]\n’.format(controller.vs\_minspd))  
I will fetch the latest version and transfer my 3-dimensional (pitch angle, tsr and wind speed dimensions) performance table interpolation unto it.  
Regards,  
Salem

---

<div class="post-metadata">

**Author:** ![Salem.Okpokparoro](https://avatars.discourse-cdn.com/v4/letter/s/848f3c/32.png) [@Salem.Okpokparoro](https://forums.nlr.gov/u/Salem.Okpokparoro)\
**Post date:** [November 7, 2022, 1:20pm UTC](https://forums.nlr.gov/t/tuning-rosco-controller-with-discon-in/2458/8 "2022-11-07T13:20:08Z")

</div>

Hi @Daniel.Zalkind,  
Thank you for your responses. I ran [example\_12](https://github.com/NREL/ROSCO/blob/main/Examples/example_12.py) successfully. However, does it not create a new DISCON.IN file with the results?  
BR  
Salem

---

<div class="post-metadata">

**Author:** ![Daniel.Zalkind](https://avatars.discourse-cdn.com/v4/letter/d/5daacb/32.png) [@Daniel.Zalkind](https://forums.nlr.gov/u/Daniel.Zalkind)\
**Post date:** [November 7, 2022, 3:59pm UTC](https://forums.nlr.gov/t/tuning-rosco-controller-with-discon-in/2458/9 "2022-11-07T15:59:17Z")

</div>

Hi Salem,

It looks like that example stops short of writing the DISCON. [Here](https://github.com/NREL/ROSCO/blob/51629665d22f92770f861daeebcebd47ab32abb1/Examples/example_06.py#L56) is an example of how to write a DISCON with a `controller` object.

Best, Dan

---

<div class="post-metadata">

**Author:** ![Salem.Okpokparoro](https://avatars.discourse-cdn.com/v4/letter/s/848f3c/32.png) [@Salem.Okpokparoro](https://forums.nlr.gov/u/Salem.Okpokparoro)\
**Post date:** [November 7, 2022, 9:39pm UTC](https://forums.nlr.gov/t/tuning-rosco-controller-with-discon-in/2458/10 "2022-11-07T21:39:12Z")

</div>

Hi @Daniel.Zalkind,  
Many thanks, I’ll add as appropriate. Please finally, what is the benefit of the robust tuning as implemented in ROSCO for FWTs–when compared to tuning without the linearized FWT model?  
Regards  
Salem

---

<div class="post-metadata">

**Author:** ![Daniel.Zalkind](https://avatars.discourse-cdn.com/v4/letter/d/5daacb/32.png) [@Daniel.Zalkind](https://forums.nlr.gov/u/Daniel.Zalkind)\
**Post date:** [November 7, 2022, 10:42pm UTC](https://forums.nlr.gov/t/tuning-rosco-controller-with-discon-in/2458/11 "2022-11-07T22:42:40Z")

</div>

Hi Salem,

The idea behind the robust tuning is that it provides some theoretical margin on the stability of the controller. More information can be found here: [https://onlinelibrary.wiley.com/doi/epdf/10.1002/we.2408](https://onlinelibrary.wiley.com/doi/epdf/10.1002/we.2408)

Personally, I mostly use the standard ROSCO tuning, which doesn’t require linearized models and is simpler to set up.

Best, Dan

---

<div class="post-metadata">

**Author:** ![Salem.Okpokparoro](https://avatars.discourse-cdn.com/v4/letter/s/848f3c/32.png) [@Salem.Okpokparoro](https://forums.nlr.gov/u/Salem.Okpokparoro)\
**Post date:** [November 8, 2022, 3:28am UTC](https://forums.nlr.gov/t/tuning-rosco-controller-with-discon-in/2458/12 "2022-11-08T03:28:33Z")

</div>

Hi Dan,  
Many thanks for your help.  
BR  
Salem

---

<div class="post-metadata">

**Author:** ![Salem.Okpokparoro](https://avatars.discourse-cdn.com/v4/letter/s/848f3c/32.png) [@Salem.Okpokparoro](https://forums.nlr.gov/u/Salem.Okpokparoro)\
**Post date:** [November 10, 2022, 10:40am UTC](https://forums.nlr.gov/t/tuning-rosco-controller-with-discon-in/2458/13 "2022-11-10T10:40:34Z")

</div>

Dear @Daniel.Zalkind  
I compared DNV Bladed linearized model to those used in [example12.py](https://github.com/NREL/ROSCO/blob/main/Examples/example_12.py). I have a question about the following continuous states used for the tuning:  
ED Platform horizontal surge translation DOF (internal DOF index = DOF\_Sg), m  
ED Platform vertical heave translation DOF (internal DOF index = DOF\_Hv), m  
ED Platform pitch tilt rotation DOF (internal DOF index = DOF\_P), rad  
ED 1st tower fore-aft bending mode DOF (internal DOF index = DOF\_TFA1), m  
ED First time derivative of Platform horizontal surge translation DOF (internal DOF index = DOF\_Sg), m/s  
ED First time derivative of Platform vertical heave translation DOF (internal DOF index = DOF\_Hv), m/s  
ED First time derivative of Platform pitch tilt rotation DOF (internal DOF index = DOF\_P), rad/s  
ED First time derivative of 1st tower fore-aft bending mode DOF (internal DOF index = DOF\_TFA1), m/s  
ED First time derivative of Variable speed generator DOF (internal DOF index = DOF\_GeAz), rad/s

I currently have the first 8 states above in my Bladed model and I think I know what they are. However the 9th state: ED First time derivative of Variable speed generator DOF (internal DOF index = DOF\_GeAz), rad/s, I do not know what this represents. Removing it from the linearization gave different gains, so must be important or how important is it? Any help on this would be greatly appreciated.  
Regards  
Salem

---

<div class="post-metadata">

**Author:** ![Jason.Jonkman](https://dub1.discourse-cdn.com/nrel/user_avatar/forums.nlr.gov/jason.jonkman/32/3086_2.png) [@Jason.Jonkman](https://forums.nlr.gov/u/Jason.Jonkman)\
**Post date:** [November 10, 2022, 1:43pm UTC](https://forums.nlr.gov/t/tuning-rosco-controller-with-discon-in/2458/14 "2022-11-10T13:43:08Z")

</div>

Dear @Salem.Okpokparoro,

> ED First time derivative of Variable speed generator DOF (internal DOF index = DOF\_GeAz), rad/s

is the generator speed state in rad/s, expressed relative to the low-speed shaft.

Best regards,

---

<div class="post-metadata">

**Author:** ![Salem.Okpokparoro](https://avatars.discourse-cdn.com/v4/letter/s/848f3c/32.png) [@Salem.Okpokparoro](https://forums.nlr.gov/u/Salem.Okpokparoro)\
**Post date:** [November 10, 2022, 1:59pm UTC](https://forums.nlr.gov/t/tuning-rosco-controller-with-discon-in/2458/15 "2022-11-10T13:59:15Z")

</div>

> [@Jason.Jonkman](#):
>
> generator speed state in rad/s, expressed relative to the low-speed shaft

Dear @Jason.Jonkman  
Thank you. Please how crucial is this state in the robust tuning for FWT PI controller? This is because I am currently unable to include this state in my linearization output. Is there a way I can derive it from the rotor speed and gear box ratio?  
Regards  
Salem

---

<div class="post-metadata">

**Author:** ![Daniel.Zalkind](https://avatars.discourse-cdn.com/v4/letter/d/5daacb/32.png) [@Daniel.Zalkind](https://forums.nlr.gov/u/Daniel.Zalkind)\
**Post date:** [November 10, 2022, 3:51pm UTC](https://forums.nlr.gov/t/tuning-rosco-controller-with-discon-in/2458/16 "2022-11-10T15:51:52Z")

</div>

Hi Salem,

I don’t have a lot of experience with the robust tuning and sensitivities to different states and their errors. Since the PI controller is used to regulate the generator speed, I would guess it’s pretty important.

Best, Dan

---

<div class="post-metadata">

**Author:** ![Salem.Okpokparoro](https://avatars.discourse-cdn.com/v4/letter/s/848f3c/32.png) [@Salem.Okpokparoro](https://forums.nlr.gov/u/Salem.Okpokparoro)\
**Post date:** [November 10, 2022, 3:59pm UTC](https://forums.nlr.gov/t/tuning-rosco-controller-with-discon-in/2458/17 "2022-11-10T15:59:49Z")

</div>

Hi Dan,  
Thank you so much for taking out time to respond, much appreciated.  
BR  
Salem

---

<div class="post-metadata">

**Author:** ![Salem.Okpokparoro](https://avatars.discourse-cdn.com/v4/letter/s/848f3c/32.png) [@Salem.Okpokparoro](https://forums.nlr.gov/u/Salem.Okpokparoro)\
**Post date:** [November 10, 2022, 4:03pm UTC](https://forums.nlr.gov/t/tuning-rosco-controller-with-discon-in/2458/18 "2022-11-10T16:03:30Z")

</div>

Hi @Jason.Jonkman,  
Perhaps I didn’t understand clearly, would ED First time derivative of Variable speed generator DOF be the same as the state; ‘Low-speed Shaft: Velocity’? I can obtain relevant matrices for this state.  
Regards  
Salem

---

<div class="post-metadata">

**Author:** ![Jason.Jonkman](https://dub1.discourse-cdn.com/nrel/user_avatar/forums.nlr.gov/jason.jonkman/32/3086_2.png) [@Jason.Jonkman](https://forums.nlr.gov/u/Jason.Jonkman)\
**Post date:** [November 10, 2022, 6:50pm UTC](https://forums.nlr.gov/t/tuning-rosco-controller-with-discon-in/2458/19 "2022-11-10T18:50:16Z")

</div>

Dear @Salem.Okpokparoro,

Because you don’t have any drivetrain torsion DOF enabled, the generator side and rotor side of the low-speed shaft have the same speed/state, so, I agree that generator speed state is equivalent to the low-speed shaft (or rotor) speed in your case.

Best regards,

---

<div class="post-metadata">

**Author:** ![Salem.Okpokparoro](https://avatars.discourse-cdn.com/v4/letter/s/848f3c/32.png) [@Salem.Okpokparoro](https://forums.nlr.gov/u/Salem.Okpokparoro)\
**Post date:** [November 10, 2022, 7:39pm UTC](https://forums.nlr.gov/t/tuning-rosco-controller-with-discon-in/2458/20 "2022-11-10T19:39:32Z")

</div>

Dear @Jason.Jonkman,  
Many thanks for your time and help.  
Regards  
Salem

[Next page](https://forums.nlr.gov/t/tuning-rosco-controller-with-discon-in/2458.md?page=2)
