Change BD states to follow the blade root reference frame #1771
Conversation
The reference frame is now moving. All values from p%GlbRot, p%Glb_crv, and p%GlbPos are now stored as otherstates and get updated at the end of an updatestates routine. Additional logic and data handling was changed within BD: - UpdateStates starts with the initial root position at T, and `q` and `dqdt` are relative to this position/orientation. - once UpdateStates converges, the `q` and `dqdt` states are updated to the root position/orientat at T+dt - Output calculations (mesh and channel outputs) have been modified - Inputs are slightly modified as well During Init, the values in `q` and `dqdt` are updated twice. The first time is relative to the reference frame for the meshes, and the second time for the mesh reference frame + displacements.
may have positions in mesh partially correct. Rotations appear too far though, so something wrong with rotation handling
Still has a free energy problem.
Some minor cleanup to better match parent branch (deleted blank lines, etc)
andrew-platt
requested review from
michaelasprague,
deslaughter and
jjonkman
|
This pull request resolves an issue related to simulating a locked rotor with Blade-1 pointing down (180 Deg) in still air. The blades are have a pre-curve and off diagonal terms in the stiffness matrix. Due to the proprietary nature of the wind turbine model, no further details can be shared publicly. |
There was a problem hiding this comment.
I'm still not sure I fully understand why this change was needed (I'm not sure what was wrong with the prior approach where the reference frame for the states was not changed every time step), but I'm happy to hear that this change resolves cases where BeamDyn was previously failing to converge. And my understanding is this change also significantly reduces the frequency with which the Jacobian will need to be updated in tight coupling, which makes this change important regardless.
I do have a couple questions on specific details of the implementation. See below.
Moreover, I'm a bit concerned that this change will mess up the BeamDyn linearization capability, especially in regards to RotStates and RelStates (the latter of which is implemented in BeamDyn, but not selectable by the user). Was linearization tested?
| ! Root displacement is relative to the GlbPos at time T, which is simply the difference between | ||
| ! the previous root position (GlbPos) and the new extrapolated position (Pos+TransDisp) | ||
| dxdt%q(1:3,1) = m%u%RootMotion%TranslationDisp(:,1) + & | ||
| matmul(m%u%RootMotion%Position(:,1) - OtherState%GlbPos, OtherState%GlbRot) |
There was a problem hiding this comment.
I don't get why TranslationDisp is not within the MATMUL() as TranslationDisp, Position, and GlbPos are all in global coordinates. Likewise in other places. Is this because the input is changed from global to local coordinates in BD_InputGlobalLocal?
There was a problem hiding this comment.
Correct. The TranslationDisp was changed in the BD_InputGlobalLocal routine, but the reference Position was not changed.
Removing the BD_InputGlobalLocal routine would really help clean up this logic.
| @@ -5149,32 +5161,33 @@ END SUBROUTINE BD_CompTngtStiff | |||
| !! 4 Point forces/moments | |||
| !! 5 Distributed forces/moments | |||
| !! It also transforms the DCM to rotation tensor in the input data structure | |||
| SUBROUTINE BD_InputGlobalLocal(p, u) | |||
| SUBROUTINE BD_InputGlobalLocal(p, OtherState, u) | |||
There was a problem hiding this comment.
I was not previously aware of this routine, but it appears to be in violation of the framework because inputs are supposed to be INTENT(IN) and not changed. Can we rework BeamDyn so that the inputs are not changed? I'm concerned that inputs are generally assumed to be in global coordinates, but are no longer after this change, so, there is likely more potential for misunderstanding and errors.
There was a problem hiding this comment.
This routine has been in BeamDyn since ~2013. Now that the reference frame for the states follows the blade root motion, it really should be removed. It will take a little time to do, so perhaps we can do that during the 4.1 tight coupling we can simplify a few things in BD.
|
My suspicion is that there is something very slightly incorrect in the equations for tangent stiffness matrix that becomes an issue when we have large angular displacements. If this suspicion is correct, it would explain the observations @ashesh2512 made about the difference between the analytical and numerically calculated tangent stiffness matrices. By resetting the states to follow the root motion, we never have a situation with large angular displacements. I ran a few checks with the BeamDyn linearization regression tests. A few terms in the C and D matrices from the @mayankchetan also did some linearization testing with the IEA 15 MW turbine and saw no substantive change in results from v 3.5.0 (negative damping still occurs exactly as before). |
|
Comparison table from @mayankchetan: [table would not copy nicely from Teams, hence the picture instead] |
This PR is ready to merge
Feature or improvement description
BeamDyn states have been calculated in a stationary reference frame. This has led to slow convergence or non-convergence with some blades at large angular displacements. This PR changes the reference frame for the states to the blade root motion reference frame.
To accomplish this, the BeamDyn states are now calculated relative to the blade root motion mesh and must be updated to the new reference frame every timestep. The BeamDyn algorithm is now as follows:
GlbPos,GlbRot, andGlb_crvin OtherStates instead of parameters. These are used in calculations to set outputs, and move inputs into the correct frames.UpdateStatesroutine uses the reference frame at timeTand calculates the new states at timeT+dt. AfterUpdateStatescompletes, the reference frame valuesGlbPos,GlbRot, andGlb_crvare updated to the root motion for timeT+dt. The states atT+dtare then shifted to this new reference frame so that the states atT+dtare using the root motion frame atT+dt.CalcOutputroutine is essentially unchanged.The values for the reference frame (
GlbPos,GlbRot, andGlb_crv) are stored inOtherStatesinstead of parameters so they can be rolled back with the states when the predictor-corrector algorithm is used.A flag in the source code has also been added to allow reverting to the previous behavior if necessary (not user accessible).
Related issue, if one exists
When the rotor was locked with blades at 180 degrees azimuth (blade 1 pointing straight down), a time domain simulation would fail with non-convergence on blade 2:
After this update, this simulation now runs to completion (see comments below).
We expect this will help eliminate some non-convergence issues with curved blades during time-domain simulations (we have not fully tested this with all known problematic blades yet).
Impacted areas of the software
Additional supporting information
The BeamDyn formulation has been using a stationary reference frame for all states. This requires reparamerization of the WM parameters of the states at +/-Pi. This can lead to calculation non-convergence when the turbine is yawed or the blade is pitched away from power (non-convergence typically occurred on blades 2&3). During the initial development of a new tight coupling algorithm in the glue to simultaneously solve all BeamDyn instances along with ElastoDyn, @deslaughter found it difficult to get convergence beyond ~45 degrees of blade pitch, azimuth, or nacelle yaw. This led to questioning if it might be appropriate to change the calculation frame used in BD (requiring changing the states) to be relative to the blade root motion. Rather than try this on the tight coupling only, we added it to the main branch as well for testing.
Test results, if applicable
Test results are identical to before.