Tuning ROSCO controller with DISCON.IN

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].

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]

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]

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

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


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

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

Hi Salem,

Our paper about robust tuning is still under review. Here 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 in the ROSCO_Toolbox, self.vs_minspd is the rotor speed. When the DISCON is written, it is converted to the generator speed here.

I hope this helps.

Best, Dan

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

Hi @Daniel.Zalkind,
Thank you for your responses. I ran example_12 successfully. However, does it not create a new DISCON.IN file with the results?
BR
Salem

Hi Salem,

It looks like that example stops short of writing the DISCON. Here is an example of how to write a DISCON with a controller object.

Best, Dan

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

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

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

Best, Dan

Hi Dan,
Many thanks for your help.
BR
Salem

Dear @Daniel.Zalkind
I compared DNV Bladed linearized model to those used in example12.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

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,

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

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

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

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

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,

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