-
Notifications
You must be signed in to change notification settings - Fork 472
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Trapezoidal Quadrature Bug in BeamDyn #13
Comments
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. |
- fixed initialization of PointLoad mesh (driver only) - added variables and reorganized loops for optimization - fixed internal-loads outputs (fixes OpenFAST#11) - Note that OpenFAST#13 has also been fixed (in a previous commit)
@jjonkman The equations in the initial post have an incorrect minus sign. The corrected equation should be: 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? |
@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. |
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:
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? |
This looks to have been fixed in OpenFAST v1.0.0, so I'm closing this issue. |
stall angle passed, bugs tno fixed, cleaner code
Merged NREL dev into the branch and addressed merge conflicts
This change makes it easier to scan and find information in each section of the API documentation by bringing any information that is outside of a table to the top of the section.
Combining Rod Damping and improving input file format
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.
The text was updated successfully, but these errors were encountered: