Trapezoidal Quadrature Bug in BeamDyn

[jjonkman]

In BeamDyn, the number of quadrature points when using trapezoidal quadrature should equal

( Station_Total - 1 )*Refine - 1

but in routine SetParameters() of BeamDyn.f90, the number of quadrature points when using trapezoidal quadrature is set incorrectly using the number of key points for the first member

( kp_total - 1 )*Refine - 1

I guess this wasn't found before because in the NREL 5-MW example, kp_total = Station_Total.

Thanks go to Bonnie Jonkman of Envision Energy USA for reporting this bug.

[bjonkman]

The locations of the trapezoidal quadrature points are also based on the z-component of the key points, which is probably why the number of trap points is computed using the number of key points instead of the station_total (the underlying assumption seems to be that the stations are defined at the key points). I would expect the locations of these quadrature points to be based on the eta specified in the BeamDyn blade input file, but they are not.

[rafmudaf]

@jjonkman The equations in the initial post have an incorrect minus sign. The corrected equation should be:
number_quadrature_points = ( Station_Total - 1 )*Refine + 1
and the buggy equation implemented in code is:
number_quadrature_points = ( kp_total - 1 )*Refine + 1.

In any case, this is currently implement as stated above in the openfast/dev branch at BeamDyn.f90 line 664. In fact, this update was included as a fix between v0.1.0 and v1.0.0.

Is there a definitive test to verify this bug and fix?

[jjonkman]

@rafmudaf -- I agree that the "-1" should have been "+1"; sorry for the original typo.

You can test this by putting together a BeamDyn model where Station_Total /= kp_total. You could probably do this easily by eliminating some of the key points in the primary BeamDyn input file for the NREL 5-MW baseline blade i.e. the first 12 key points currently have the same twist, so, you could probably eliminate many of these from the file.

[rafmudaf]

I've modified the 5MW BeamDyn model to have more stations than key points as @jjonkman suggested. In OpenFAST v0.1.0, which contains this bug, the loads are erratic and the solution fails to converge with this error:

 FAST_Solution:FAST_AdvanceStates:BD_GA2:BD_DynamicSolutionGA2:Solution does not converge after
 the maximum number of iterations

However, the same case in OpenFAST v1.0.0 completes the simulation with expected loads.

With the code modified as described above and a stable and expected solution, this issue looks fixed to me. @michaelasprague do you agree?

[rafmudaf]

This looks to have been fixed in OpenFAST v1.0.0, so I'm closing this issue.