Issues while modeling flexible blade rotor using FAST 3.5.3 interfaces

Wind & Water Computer-Aided Engineering Software Tools
1

Dear NREL,
I am currently interfacing OpenFAST with our in house structural solver. At the moment, I am upgrading the coupling from OpenFAST v3.0.0 to OpenFAST v3.5.3.

I made the changes in datatypes as needed by v3.5.3. As for conforming to the interface subroutines - I tried to conform to FAST 3.0.0 logic. What this specifically means is that I don’t have a FED datatype. Also I don’t use Aerodyn-Inflowind coupling. I call InflowWind routines and Aerodyn routines directly.

With this setup - I am able to get correct results with a rigid blade model. Time histories of aerodynamic outputs agree between my solver and OpenFAST run on its own.
My test case is the IEA 15MW wind turbine, with 12 m/s wind, ramp loading from 0m/s to 12m/s until 25 seconds, and then steady wind of 12m/s for the rest of the time.
But with flexible blades my results are as follows:

Blade pitch

image
image1000×543 77.1 KB

Rotor speed

image
image1000×480 64.9 KB

The ramp is up to t = 25 sec. It looks like the controller is is struggling to get to steady state, but once this is attained the steady state values are correct. Until t = 40 sec the values match between rigid and flexible blade models. After this point, the controller seems to behave oddly with the new v3.5.3 interfaces.

I also tried to interface with FAST v3.5.3 using the old v3.0.0 interfaces. That means the data types were not updated to FAST 3.5.3 and Aerodyn_Driver_Subs and AeroDyn_Driver_Types of FAST 3.0.0 are used - I just changed the driver writing subroutine to conform to FAST 3.5.3. This approach yielded better results. The output parameters reach steady-state quite quickly.
Flexible blade model:
Blade pitch

image
image1000×538 66.5 KB

Rotor speed

image
image1000×480 62.2 KB

Could you offer any insights on what might be the issue with my implementation?
Since it worked with FAST 3.0.0 interfaces I expect it to work with FAST 3.5.3 interfaces (after updating the datatypes)

Thanks,
Ashok

2

Dear @Ashok.Jammi,

I’m not sure I know how to answer your question, but can you clarify a couple things first:

  • Your time-series plots refer to OpenFAST, but are these actually results from your own structural coupled to the AeroDyn, InflowWind, and ServoDyn modules of OpenFAST, without using the rest of OpenFAST?
  • If the answer to the first question is “yes”, what happens if you run the same exact case using OpenFAST; do you also see issues with the response?

Thanks,

3

Hi @Jason.Jonkman,
Yes, these plots are from my own structural solver coupled with Aerodyn, InflowWind and ServoDyn modules of OpenFAST without the rest.

When I run this case with OpenFAST - I don’t see any issues. The response looks similar to the second set of plots above.

5_BldPitch1
5_BldPitch1640×480 13.7 KB

9_RotSpeed
9_RotSpeed640×480 14.5 KB

My question is more related to the issues in coupling using FAST 3.5.3 Aerodyn interfaces than with running FAST itself.

4

Hi @Jason.Jonkman ,
Let me know if I can provide any additional details about my issue.

Thanks,
Ashok

5

Hi Ashok,

The main issue seems to be that the rotor speed does not increase as quickly with the new coupling. Have you compared the aerodynamic forces (and moments/torque) on the blades and the whole rotor from AeroDyn yet? I think that would be a helpful debugging step.

To simplify your ROSCO controller, you can disable the wind speed estimate, which is using the blade pitch, rotor speed, and generator torque as inputs. The wind speed estimate is determining the blade pitch at low wind speeds, which is probably responsible for the odd pitch behavior before the rotor speeds up. WE_Mode = 0 in the ROSCO DISCON.IN will simply use a filtered wind speed measurement at the hub height.

I hope this helps.

Best, Dan

6

Hi @Daniel.Zalkind,
Thanks for your input.
Setting WE_Mode = 0 worked.

image
image1350×740 35.9 KB

That means wind speed estimation is wrong - leading to odd pitch behavior.
So can we conclude that - the rotor speed input to servodyn is getting corrupted somewhere along … ?
Why would this happen only to flexible blade turbines ?

Regards,
Ashok

7

The wind speed estimator is just using the information provided to it.

You still have odd transients between 40 and 80 seconds. I suggest you evaluate the aerodynamic loading and blade displacements to understand why those are occurring.

8

Thanks for your support @Daniel.Zalkind .
The issue is resolved. The controller was getting Rotor speed input in RPM - so it was responding accordingly.

Regards,
Ashok