ServoDyn blade pitch seems to always start from zero degrees

Dear NLR,

We’ve coupled AeroDyn and ServoDyn to our own structural solver, effectively taking the place of ElastoDyn/BeamDyn in terms of the overall solution. It’s working fine for the most part, but there are some minor issues which ideally we like to get working better. One of these is supplying initial conditions to ServoDyn.

For example, I have a simple test case…

  • IEA 15MW RWT
  • Wind speed = 20 m/s steady/constant
  • Based on turbine characteristics, this is safely into the rated range, where rotor speed is 7.55 rpm
  • Running the turbine from a standing start (zero initial rotor speed), indeed produces a rotor speed of 7.55 rpm, and a blade pitch angle is 17.55 deg. But it takes a while to reach steady-state naturally.
  • Now if I want to run the turbine starting from a realistic rotor speed, to fast-track away the initial transience, I supply initial conditions via the AeroDyn driver file, and the structural code also passes some initial conditions to ServoDyn.
  • The initial rotor speed from AeroDyn looks good at 7.55rpm. But then it changes, most likely due to changes in pitch angle, see next point
  • The initial blade pitch angle returned from ServoDyn looks good, momentarily, at the very first solution step, then seems to reset to zero degrees, before slowly recovering to the correct angle as the controller gets to grips with the applied loads and turbine response.
  • Probably goes without saying, but we are supplying AeroDyn with instantaneous blade positions etc. as discussed in… How to import hub motions to AeroDyn?
  • See plots below for illustration.

In the structural code, we are initialising blade pitch and rotor speed.

  • InitInData_SrvD%BlPitchInit
  • InitInData_SrvD%RotSpeedRef

In the OpenFAST code (SUBROUTINE SrvD_Init), I noticed that ServoDyn is accepting our suggested pitch angle during initialisation. But I also noticed that it is setting an initial rotor speed of zero.

SUBROUTINE SrvD_Init

p%BlPitchInit = InitInp%BlPitchInit

u%BlPitch = p%BlPitchInit(1:p%NumBl)

u%RotSpeed = 0.0

I am just wondering if the structural solver could/should be setting more information for ServoDyn’s initial conditions, in addition to InitInp%BlPitchInit and InitInp%RotSpeedRef?

Hope the above makes sense.

Kind regards,

Aengus.

Driver File

----- Combined-Case Analysis [used only when AnalysisType=3, numTurbines=1 -------------

      1    NumCases        - Number of cases to run

WndSpeed ShearExp RotSpd Pitch Yaw dT Tmax DOF Amplitude Frequency

(m/s) (-) (rpm) (deg) (deg) (s) (s) (-) (-) (Hz)

0.2000000E+02 0.0000000E+00 0.7550000E+01 0.1755000E+02 0.0000000E+00 0.5000000E-01 0.2000000E+03 0 0 0

Blade Pitch

Rotor Speed

Dear @Aengus.Connolly,

Just a few comments/questions:

  • I’m not sure I understand your point about you “supply[ing] initial conditions via the AeroDyn driver file”. Can you clarify? In OpenFAST, the AeroDyn driver is only used for standalone AeroDyn simulations, uncoupled from the other OpenFAST modules.
  • ServoDyn initialization input data, InitInData_SrvD%RotSpeedRef is the reference rotor speed for OpenFAST’s steady-state trim solution (before linearization); it is not needed for typical time-domain simulations.
  • ServoDyn does not need to know the rotor speed at model initialization because that data is not used at initialization.
  • At time zero, ServoDyn receives the inputs such as the rotor speed directly from the structural solver (in OpenFAST, the structural solver is called/updated before ServoDyn).

Best regards,

Dear @Jason.Jonkman

Apologies for the slow reply, I’ve got totally sidetracked and not had a chance to revisit this issue since.

  • Regarding the driver file, we sometimes use this to access initialisation parameters if relevant to the structural solver, so yes a little different to OpenFAST architecture.
  • Regarding RotSpeedRef, thanks for the clarification.
  • Understood
  • Understood

I will investigate in more detail whenever I get time.

Thank you,

Aengus.