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
Rotor speed
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
Rotor speed
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
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,
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.
My question is more related to the issues in coupling using FAST 3.5.3 Aerodyn interfaces than with running FAST itself.
Hi @Jason.Jonkman ,
Let me know if I can provide any additional details about my issue.
Thanks,
Ashok
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
Hi @Daniel.Zalkind,
Thanks for your input.
Setting WE_Mode = 0 worked.
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
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.
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