-
Notifications
You must be signed in to change notification settings - Fork 452
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
Bug in ServoDyn When Controlling Yaw from DLL #25
Comments
I created a workaround/solution for this problem. Replace the CalculateStandardYaw subroutine in the .\Source\dependencies\ServoDyn\ ServoDyn.f90-file, and recompile FAST. SUBROUTINE CalculateStandardYaw(t, u, p, m, YawPosCom, YawRateCom, ErrStat, ErrMsg) REAL(DbKi), INTENT(IN ) :: t !< Current simulation time in seconds REAL(4), SAVE :: YawPosComInt !< Internal variable that integrates the commanded yaw rate and passes it to YawPosCom ErrStat = ErrID_None !................................................................... IF ( t >= p%TYCOn .AND. p%YCMode /= ControlMode_NONE ) THEN ! Time now to enable active yaw control.
ELSE ! Do not control yaw, maintain initial (neutral) yaw angles
ENDIF END SUBROUTINE CalculateStandardYaw Regards, |
Dear Sabastiaan, Thanks for updated code. However, I see three problems that will need to be fixed for the general solution:
I hope that helps. Best regards, |
Dear Jason, Thank you very much for your suggestions. I will implement these changes later, and create a pull request accordingly. Best regards, |
@sebastiaanmuld, Thank you for your efforts in isolating and finding a solution for the ServoDyn bug. A couple of weeks ago we launched a new workflow for OpenFAST contribution which aims to support a larger magnitude of community driven development than we have in the past. To that end, we have established a basic regression test and unit test system to maintain confidence and stability in OpenFAST. Being the first to propose a bug fix since our latest release, you are in a lucky position to try it all out! The procedure for bug fixes is as follows:
For reference, the test specific documentation is at http://openfast.readthedocs.io/en/latest/source/testing/index.html, and the git usage is described at I understand that this is a heavy lift for a simple bug fix, especially since some of the infrastructure for unit testing does not yet exist for ServoDyn. I am happy to support by working with you to establish the ServoDyn testing infrastructure which you can then build on to implement the unit test and bug fix more easily. Please let me know if you'd like to talk about this in more detail or work together to develop a plan for implementing the bug fix. Thanks again for your contribution to OpenFAST. Rafael M Mudafort |
Dear Rafael, Thanks you very much for your e-mail! I would like to work with you on solving this bug. I think it is best for me to first get more familiar with the NWTC Programmer’s Handbook as Jason suggested. I will contact you in 1-2 weeks once I have done this, and then we can work out a plan for implementing the bugfix and setting up the ServoDyn testing infrastructure. Best regards, |
This fixes bug report OpenFAST#25
This fixes bug report OpenFAST#25
* SrvD: add variable for integrated yaw commands This fixes bug report #25 * SrvD: fix previous commit so correction steps work correctly
Closed with PR #456 |
Fixes for the multiturbine case
In routine CalculateStandardYaw of ServoDyn.f90, the yaw angle (position) command when the yaw rate is commanded from a Bladed-style DLL is calculated by adding an increment of YawRateCom*DT to the current yaw angle. However, the yaw angle command should be defined as the integral of the yaw rate command, regardless of the current yaw angle (i.e. the yaw angle command must become a state of ServoDyn). As it is currently implemented (incorrectly), when the yaw rate commanded from a Bladed-style DLL is zero, the yaw angle is commanded to be current yaw angle, effectively eliminating the yaw spring stiffness, yielding large yaw errors. I would not use yaw control from Bladed-style DLL controllers until this bug is fixed.
See the following forum topic for more information: https://wind.nrel.gov/forum/wind/viewtopic.php?f=30&t=1844&p=9256.
The text was updated successfully, but these errors were encountered: