Fix aeroelastic stability analysis with BeamDyn #1050
Conversation
|
Natural frequencies and damping ratios for the IEA 15MW RWT, release v1.1 https://github.com/IEAWindTask37/IEA-15-240-RWT/releases/tag/v1.1 without aerodynamic effects
|
There was a problem hiding this comment.
@ebranlard are the changes in 68bb5a1 line endings or file permissions? Most of these changes are the entire file.
The logarithmic mapping was used for orientations for the root orientation perturbation in ED. This was causing the entry for DOF_DrTr coupling to X_Orientation_Root# (where # was the blade pointing down) to incorrectly change signs in the dYdx matrix from ElastoDyn ( C^{ED} matrix).
Additional ED rotation/orientation parameters were using logarithmic mapping that should not have been, including
- BladeLn2Mesh
- HubPtMotion
- NacelleMotion
- BladeRootMotion -- this one was causing the DrTr feedback issue
The `PackMotionMesh_dY` routine was modified to accept a `UseLogMaps` optional flag similar to the `PackMotionMesh` routine in ModMesh.
Further review showed that SubDyn was not always using the logarithmic mapping. This was partially corrected.
Yet further investigation shows that the `PerturbOrientationMatrix` routine from NWTC_Num.f90 uses the logarithmic mapping. This will be modified to also accept the `UseLogMaps` flag as it is called by some places where log mapping is acceptable, and other places where it is not.
# Conflicts:
# modules/subdyn/src/SubDyn.f90
# modules/subdyn/src/SubDyn_Output.f90
Revert BeamDyn to use the PerturbOrientationMatrix routine again, but without the optional logmap. Set HD and SD to use the log map option in PerturbOrientationMatrix. # Conflicts: # modules/nwtc-library/src/NWTC_Num.f90
…zation perturbations of orientations Change flag `UseLogMaps` to `UseSmlAngles` and change following routines to use a small angle perturbation instead of `DCM_logmap`: - PackMotionMesh - PackMotionMesh_dY - PerturbOrientationMatrix
# Conflicts: # modules/aerodyn/src/AeroDyn.f90 # modules/aerodyn/src/AeroDyn_IO.f90 # modules/aerodyn/src/AeroDyn_Registry.txt # modules/aerodyn/src/AeroDyn_Types.f90
I've cleaned this up as well as the commit history here: https://github.com/rafmudaf/openfast/tree/stability_cleanup. If @ebranlard or @ptrbortolotti like it, I can force-push to the stability branch. Otherwise, @ebranlard you could change the line endings in your last commit so that the highlighted differences are the real lines of code that you changes. |
|
Hey, It seems it was a line-ending error again. It's fine by me if we use your cleaned up version and force-push it to this branch. |
|
ok @ebranlard I've done it. I also have the old branch locally just in case anything is incorrect here, but I double checked that there were no unexpected differences. Could you or @ptrbortolotti get some eyes on the changes one more time? |
|
thanks a lot for doing that! The changes looks good to me |
| @@ -6398,7 +6417,7 @@ SUBROUTINE FAST_DiffInterpOutputs( psi_target, p_FAST, y_FAST, m_FAST, ED, BD, S | |||
| CALL SetErrStat(ErrStat2,ErrMsg2,ErrStat,ErrMsg,RoutineName ) | |||
|
|
|||
| call BD_GetOP( t_global, BD%Input(1,k), BD%p(k), BD%x(k,STATE_CURR), BD%xd(k,STATE_CURR), BD%z(k,STATE_CURR), BD%OtherSt(k,STATE_CURR), & | |||
| BD%y_interp(k), BD%m(k), ErrStat2, ErrMsg2, y_op=y_FAST%Lin%Modules(Module_BD)%Instance(k)%op_y, NeedLogMap=.true.) | |||
| BD%y_interp(k), BD%m(k), ErrStat2, ErrMsg2, y_op=y_FAST%Lin%Modules(Module_BD)%Instance(k)%op_y, NeedLogMap=.false.) | |||
There was a problem hiding this comment.
The way this FAST_DiffInterpOutputs routine works, we really can't be mixing the value of NeedLogMap between the modules (see calls to SD_GetOP, BD_GetOP, ED_GetOp). When we pack the y operating points in pack_in_array(), it assumes the orientations are represented as 3 numbers, but if NeedLogMap is false, the 9 values of the orientation matrix are returned. So, (1) we are going to be trying to make all components of BD orientation matrices identical and (2) we are going to be skipping a bunch of blade node elements towards the tip when we check that the trim solution has converged.
It looks like PackMotionMesh doesn't use log maps anymore, so I would expect that we could use NeedLogMap=.true. here. Maybe? Otherwise we will need to update how pack_in_array() works (and make sure the other models that have orientations as output work the same way).
@andrew-platt, @jjonkman, @ebranlard : Any preferences on how to fix this?
There was a problem hiding this comment.
good question. @jjonkman, did I miss something in changing this over?
As an aside note, I have not addressed the NeedLogMap=.true. change into the StC linearization. I'll make a separate PR for that and include what we think this should be for BD.
This PR is ready to merge once PR #962 is merged.
Many thanks to @michaelasprague, @ebranlard, @jjonkman, and @rafmudaf for their contributions in isolating the issue. The majority of the testing was performed by @ebranlard and @ptrbortolotti.
Description
This PR fixes two issues with BeamDyn.
revises the method used for small angles in the linearization process. Previously, a logarithmic mapping had been applied for small angle changes. This resulted in discontinuities in linearization involving BeamDyn, which caused large negative damping for any blade close to a +/-180 degree azimuth (178 to 182 degree window) - see Linearization with BeamDyn #823.
To fix this issue, the logarithmic mapping call has been removed from the
PackMotionMeshroutine in the ModMesh module, and replaced with a small angle mapping for small angles, and DCM differencing method for large angles.A limit is placed on the
QFitparameter within BeamDyn. This now limits the maximum order of the spline fit to the keypoints to 7 instead oforder_elem. Without this limit, the solver within BeamDyn would go unstable in some configurations or loadings resulting in incorrect solutions for the geometry, particularly in twist. When BeamDyn would stay stable, this could appear as differences between blade tip motions for a simplified rotor (see Bug report #816 and Choice of axis in BeamDyn #818).Impacted areas of code
BeamDyn primarily
A few other modules were also modified for consistency with the documentation: some modules should use small angle difference and others a large angle DCM difference.
Small angle:
Large angle DCM:
Test Results
No existing test cases should be affected.
Items to complete
Related issues
closes #816 #818 #823
This may partially improve issue #366