Acceleration Behavior at Blade Tip – IEA 15 MW + BeamDyn (No Aero/Inflow)

[Alessandro5I]

Hi everyone,

I'm currently running simulations using the IEA 15 MW reference turbine with BeamDyn, without aerodynamic effects or inflow. I've noticed some strange behavior in the acceleration output from the blade tip sensor.

Specifically, when comparing sensor #8 (located at 85% of the blade radius) with sensor #9 (at 100%, i.e., the blade tip), there are very large variations in the acceleration values for the tip sensor. You can clearly see this in the attached plot.

What may be the cause?

Thanks in advance,
Alessandro

[jjonkman]

Dear @Alessandro5I,

Maybe I don't fully understand what concerns you have with the results, which seem reasonable to me. Note that you are plotting these absolute translational accelerations in a local reference frame that orients with the blade as it deflects.

Best regards,

[jjonkman]

Dear @Alessandro5I,

Can you clarify which version of OpenFAST you are using? There have certainly been improvements and bug fixes made to BeamDyn over the years.

Best regards,

[Alessandro5I]

Dear @jjonkman,

I am using OpenFAST v4.0.1

Best regards,
Alessandro

[jjonkman]

Dear @Alessandro5I,

Thanks for clarifying. There were issues in BeamDyn in older versions of OpenFAST, but BeamDyn within OpenFAST v4.0.1 should function correctly.

BeamDyn has an internal quasi-static solve that "stretches" the blade at model initialization based on centrifugal forcing that should minimize what would other "kick" the system from a nonzero initial rotor speed. (ElastoDyn does not have this because blades in ElastoDyn cannot be stretched.) That said, gravity is not accounted for in this quasi-static solve, so, gravity can still "kick" the system, both in BeamDyn and ElastoDyn. I'm not sure why the "kick" is stronger in BeamDyn than ElastoDyn, but I suppose that could be the result of high-order dynamics accounted for in BeamDyn than are not in ElastoDyn.

Best regards,

[Alessandro5I]

Dear @jjonkman,

What concerns me is the discontinuity (a noticeable jump) in the behavior of the sensors at 85% compared to those at 95% or 100% radius.
In any case, I probably have no other option than to use the sensors located closer to the hub (< 90%) for my analysis, as everything seems to work properly that way.

Best regards,
Alessandro

[jjonkman]

Dear @Alessandro5I,

After further internal deliberation, I learned that gravity is included within BeamDyn's internal quasi-static solve that happens at model initialization. I was not previously aware of this. The "kick" in your case results from the impact of gravity loads on the hub, nacelle, and support structure as modeled in ElastoDyn.

Best regards,