BeamDyn structural modes of IEA-15 blade

Wind & Water Structural Analysis
1

Dear OpenFAST users,

I am currently trying to compute the vibration modes of the IEA-15-RWT blade using BeamDyn.

Specifically, I use the linearization feature of OpenFAST (v3.0.0) interfaced with BeamDyn. In order to compute in-vacuo blade modes, all degrees of freedom other than those associated with the blades have been disabled, gravity is set to zero, as well as initial conditions. The rotor is not rotating. The fully populated stiffness matrices given in the GitHub repo are used, material damping is set to zero. A time-marching simulation is run for 5 seconds (dt=0.002) and rhoinf=0 or 1, then linearization is performed. Eventually, eigenvalues are computed.

The BeamDyn solver parameters are the following:
True Echo
False QuasiStaticInit
[0.0 or 1.0] rhoinf
2 quadrature
“DEFAULT” refine
“DEFAULT” n_fact
“DEFAULT” DTBeam
“DEFAULT” load_retries
30 NRMax
“DEFAULT” stop_tol
False tngt_stf_fd
False tngt_stf_comp
“DEFAULT” tngt_stf_pert
“DEFAULT” tngt_stf_difftol
True RotStates
1 member_total
31 kp_total
[variing] order_elem

I have observed several behaviours that I find difficult to interpret:

  1. It seems that the natural frequencies do not seem to converge when the order_elem parameter is increased (see the graphs below for parameters rhoinf=0 and rhoinf=1, where dashed lines report the frequencies found by Rinker et al. TORQUE 2020).
    convergence_beamdyn_rhoinf1.pngconvergence_beamdyn_rhoinf0.png
    It is also not very clear to me how order_elem should be set with respect to member_total (kept fixed to 1 in my investigations).

  2. Even if the blades have no material damping, the damping of the modes is not very small (except when order_elem=1) as visible above. Interestingly, when the geometry of the blade is set as being straight (by setting kp_xr to zero), then damping returns to small values (on the order of 1e-12).

  3. When non-zero material damping is considered, sometimes the time-marching solution crashes (error message: FAST_Solution:FAST_AdvanceStates:B2:BD_GA2:BD_DynamicSolutionGA2:Solution does not converge after the maximum number of iterations)

As there have been some bug reports recently regarding BeamDyn (e.g. github.com/OpenFAST/openfast/issues/823), I’m not sure what could be the trace of a bug and what could be on my side a misunderstanding of the recommended settings for using BeamDyn.

Thank you in advance for any clarification!

Cheers,
Jean-Lou

2

Hello Jean Lou,
it looks like you have been replicating most of the problems that I’ve observed in the past months. We are actively working to solve them, and although we have some temporary fixes, we have not closed the issues yet.

This said, I can give you some tips. Most importantly, please try switching to my fork of OpenFAST, branch beamdyn_io: github.com/ptrbortolotti/openfa … beamdyn_io

This fork/branch fixes two problems:

  • OpenFAST 3.0 includes an assumption of small rotations that is not valid for BeamDyn
  • It limits the order of the spectral elements in BeamDyn to 7, improving convergence of BeamDyn when the reference beam axis is curved/swept

About some of the other issues that you mention:

  • Set the order_elem to 10. I actually believe that 14 could be an even safer choice right now, see github.com/OpenFAST/openfast/issues/816
  • BeamDyn within the glue code of OpenFAST currently requires very tiny time steps to solve all structural frequencies and pass them to ElastoDyn. Whenever you don’t get convergence, try reducing DT in the main .fst file. I’m used to 0.4/0.2/0.1 ms. We are aware of the excessive computational costs of these simulations and we’ll be working to change the coupling scheme between BeamDyn and ElastoDyn
  • I’ve never tried running simulations without aerodynamics and 0 structural damping. I usually set the latter to a small but realistic value.
  • Make sure to use the openfast_dev branch of github.com/IEAWindTask37/IEA-15 … enfast_dev, it will become master in the next days
  • We are planning a TORQUE2022 publication describing our efforts in this area

I hope this helps.
Best regards,
Pietro Bortolotti

3

Dear Pietro,

thank you for your detailed answer, this is helpful. I’ll see if these first corrections improve things.

Cheers,
Jean-Lou

4

Dear Pietro,

I hope this message finds you well. I stumbled upon this topic and was wondering whether there had been any progress lately with the requirements from BeamDyn to have small timesteps (e.g. dt around 0.0005s)?
Thanks in advance,
Bruno

5

Dear @Bruno.Nguyen,

At NREL, we are currently working on plans to introduce a tight-coupling scheme between the structural modules of OpenFAST, which should support larger time steps for models with BeamDyn and/or SubDyn enabled. But there is no implementation yet.

Best regards,

1 Like