BeamDyn bug fixes and updates #109
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 algorithm to better search for a workable series of load steps when the full user-specified load fails to converge. It is essential a bisection type approach.
…ture points in BeamDyn
Updated cross-sectional property interpolation info
|
Do the r-test case results (from this pull-request) which do not depend on BeamDyn match the baseline results? If not, have they been individually reviewed and accepted? |
|
Hey rafmudaf, |
|
Hi @IAbda, |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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_dynamicdoes 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_WTurbwith initial azimuth angle 0 and 120 from the OpenFASTdevbranch. 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.