-
Notifications
You must be signed in to change notification settings - Fork 457
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
BeamDyn bug fixes and updates #114
Conversation
Moved some of the calculations that don't change at each node outside the node loop.
… the loop. Also apparently added some write statements for figuring out what is going on wit p%uu0 versus p%QuadPt
A few COS and SIN functions were done in single precision, and they ended up causing spikes in BD simulations. Test26 now works in single precision like the double-precision version does!
- fixes for running FAST with BD and BD driver in single precision (should increase speed) - fix for sectional and root load outputs in static case - input distributed mesh is along the spline instead of the key-point line - more code cleanup - updated crvCompose to use vector math for readability - updated BD driver for compilation in single precision
- roational velocity vector is now double precision; - the BD input file specified in the driver was defined relative to the working directory instead of the directory where the driver input file is located.
4 sets of equations should give same results, assuming the "pivot" is not zero. New implementation picks set of equations with largest pivot value, not just one that is slightly larger than 0. (The values are all bounded by 0 and 4 [or less].)
The initial translation velocity calculation didn't remove the location of the root node when taking the cross product with the rotational velocity. This fixes OpenFAST#26
- 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)
- removed unused variables, including subroutine arguments - removed duplicated code - moved some computations into parameters for computational efficiency
a variable was implicitly defined (though it was defined correctly)
I took all of OpenFAST changes, and will modifiy a few issues I noticed when resolving differences later.
call generic LAPACK_gesvd instead of specific one
I got tired of reading all the compiler warnings about these variables not being used in the Registry and about redefining NDEBUG in MAP++
Setting types with allocatable arrays inside them using the equals sign can cause severe problems on some compilers.
The curve-compose operation was implemented backwards, resulting in incorrect values if the initial rotation was not identity (steady-state simulations gave different mean values for the three blades)
Some instances of the static solve may have incorrectly reported an error.
This changes som comments in the code and some text printed to the summary file
Changed the algorithm to use a bisect approach instead of a predefined, linear load step when the full user-specified load fails to converge
@ghaymanNREL in response to your question in an earlier pull request (#109) regarding the openfast-related regression tests, here are the results from peregrine. As expected, the only failing case is the BeamDyn associated case.
|
This updates the baseline solutions for all three supported platforms. The BeamDyn-specific regression test solutions have been corrected and updated. The OpenFAST regression test solutions have simply been updated. Please see the associated OpenFAST pull request for more information: OpenFAST/openfast#114
Gets the updated baseline solutions for BeamDyn related cases from the r-test submodule. Please see the corresponding pull request for more information: OpenFAST#114
The regression test baseline solutions have been updated for all supported platform/compiler combinations. After review, this pull request can be merged. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. Thanks.
This pull request will merge significant updates to BeamDyn developed at Envision Energy. These updates have been tested and validated as shown below.
The following updates are included:
Issue 11
Sectional load calculations are fixed in commit 0829f84 at line 1569.
This issue is exposed by evaluating the results of the BeamDyn regression test case
5MW_Land_BD_DLL_WTurb
. In the OpenFAST dev branch, the first node is at the root but the sectional loads do not match the root loads. Furthermore, the BeamDyn sectional loads do not match the ElastoDyn sectional loads. In this case, the blade root has 13.3 degrees of structural twist so the difference in loads between section 1 and root is related to the offset coordinate systems between blade local and blade reference.The charts below compare the solutions of the NREL 5MW turbine regression test cases with ElastoDyn and BeamDyn. The left and right columns (ElastoDyn and BeamDyn solutions, respectively) are expected to match. The charts in the upper and lower rows (root and first section, respectively) are expected to differ in magnitude. However, a difference in the ElastoDyn and BeamDyn solution is clearly shown.
Note the difference in units: N vs kN.
The updated BeamDyn solutions demonstrate agreement between the sectional and root loads and are validated by ElastoDyn.
The OpenFAST regression test case using BeamDyn,
5MW_Land_BD_DLL_WTurb
, does not currently output the sectional loads, so this bug was not exposed there and it does not require an updated baseline solution. However, the BeamDyn specific regression testbd_5MW_dynamic
does require an update to the baselines as the sectional loads have been updated. The root and node 1 forces and moments are shown side by side with the corrected BeamDyn solutions below.Issue 26
Initial translational velocity calculation is fixed at commit 97d1c2a.
The problems is exposed by running
5MW_Land_BD_DLL_WTurb
with initial azimuth angle 0 and 120 from the OpenFASTdev
branch. With an initial azimuth of 120 degrees, it is expected that the root moments would simply shift blade numbers in this pattern:The solution from openfast/dev is shown in the charts below where the root moments do not shift as expected and a frequency variation is introduced in the rotor torque.
The following charts show that this pull request fixes the root moment blade shift and calculates a consistent rotor torque.