Azimuth Angle of Blades

Hello all,

I have a question about Azimuth angle input in FAST primary file. is Azimuth angle just used for calculation of wind field on the exact position of blades or it has also some effects on structural properties?

Many Thanks

Dear Gholamreza,

FAST certainly uses the azimuth angle to determine the position of the blades within the wind field. However, the azimuth angle is also used by the structural model e.g. to calculate the gravity load on the blades.

Best regards,

Dear Dr. Jonkman

Thanks for your respond. Does Azimuth angle also affect mode shapes and natural frequencies of blades according to blade position?
according to my understandings, Bmodes does not take blade azimuth angle in to the account for calculation of mode shapes.

Dear Gholamreza,

The blade mode shapes are input to FAST, not dependent on azimuth. Indeed, BModes does not consider azimuth dependence either. The full-system mode shapes and frequencies calculated by FAST through a linearization and subsequent eigenanalysis may have a small azimuth-dependence, but usually the state-matrix is azimuth-averaged (after applying the multi-blade-coordinate (MBC) transformation) before eigenanalysis.

Best regards,

Dear .Dr. Jonkman

Thank you again for your answer.

Dr. Jonkman

As another question; I am curious about aerodynamic modeling of blades in Parked situation. how can I implement quasi-steady and unsteady formulation to address motion dependent forces (Buffeting and self-excited forces)?
where can I change the parameters dealing with aerodynamic admittance function and/or aerodynamic flutter derivatives?
from the forum posts like:
(Extreme events)
and
(Extreme events - #15 by Jason.Jonkman)

I comprehended that in parked situation only quasi-steady is taken into the account.
I would be appreciated if you help me in my two stated questions?

Many Thanks

Dear Gholamreza,

Correct. The unsteady airfoil aerodynamics calculations in AeroDyn are only valid in operational conditions, not at very high angles of attack that would be experienced in parked/idling conditions. For these cases, we typically assume quasi-steady aerodynamics. Modeling buffeting etc. in parked/idling conditions would require the addition of new physics models in FAST.

You may also find the following forum topic of interest: Designing for yaw errors using FAST.

Best regards,

Dear Dr. Jonkman

I really appreciate your helpful answer.

Dear Mr. Jonkman,

I have a question regarding motion-dependent forces, which have been mentioned above in this post.
I am trying to study the impact of considering the tower aerodynamic damping for the fatigue proofs of the tower. To do so, I use the formulation of Steckley ([url]https://ir.lib.uwo.ca/digitizedtheses/1853/[/url]), in which the aerodynamic damping forces are applied as a motion-dependent force at the top of the structure. Therefore I am trying to apply a force at the tower top, which is dependent on the tower top velocity, i.e: F=c*dx/dt, with x=tower top displacement (TTDspFA).

I am considering a couple of approaches, but wanted to ask you for your advice:

  1. Introducing the force as a tuned mass damper: the TMD equations should be used in a way, that the damper inertial forces match the magnitude of the aerodynamic damping forces, and the Damper should oscillate with the same amplitude as the tower top, but the motion velocity should be opposed to that of the tower.
  2. I have read about the new structure control module StC. Using this submodule I could run a simulation of the case study, read the displacements at the tower top, and generate a time series for the aerodynamic forces at the tower top. This time series could then be applied using StC_DOF_MODE=4 (Prescribed time series). This seems a relatively simple option, but the feedback effects get lost (i.e. aerodynamic damping reduces oscillation amplitude, which also reduces aerodynamic damping, etc.), and it would probably require some iterations.

Do you have any ideas or recommendations for this?

Thanks a lot for your attention and kind regards,

Robert Fontecha

Dear Robert,

I think it would be difficult to adopt approach 1 because the damping in the tower-based TMD applies to the relative motion between TMD and toewr, rather than to the nacelle velocity directly.

Approach 2 also has a pitfall, because as you said, the motion will change once the force is added, so, you cannot guarantee that the applied force will actually generate damping (and I’m not convinced an iterative approach would converge).

An alternative approach could be to modify the structural control (StC) source code to calculate the force dependent on tower velocity. For a tower-based StC, the reference motion of the tower node (position, velocity, etc.) is passed from OpenFAST to the StC module, which is used by the StC equations of motion and output calculation. You could modify the source code such that a force is calculated that is directly proportional (via damping constant c) to this tower-node velocity. Of course, this would require a recompile of OpenFAST.

Of course, the aerodynamic loads from AeroDyn intrinsically include damping from tower motion, and while this aero-elastic coupling is not intrinically linear in nature, the linearization functionality of OpenFAST could be used to quantify the equivalent tower-dependent linear damping (c).

Best regards,

Dear Mr. Jonkman,

thanks for your answer. Before I jump into modifying the StC code, I wanted to try if approach 2 could converge, as until now I have only worked with the binaries.

I have now downloaded the binaries for Openfast v.2.6.0, but when I run OpenFast I get the error ending with “invalid logical input for the file “(…)\Serovdyn.dat” occurred while trying to read CompNTMD” (see attached files). I also attach the used primary input, ServoDyn and STC templates.

It seems that Servodyn looks for an old Input “comNTMD”. Could it be that the new module StC is not included in the v.2.6.0 binaries? Or am I doing something wrong?

Thanks for your time,

Robert Fontecha
OpenFAST_error.zip (48.9 KB)

Dear Robert,

You are correct. The new StC functionality is not included in OpenFAST v2.6. Instead, the new StC functionality has been merged into the dev branch of OpenFAST, which is slated to be released in OpenFAST v3.0. See the StC pull request for details: github.com/OpenFAST/openfast/pull/607.

Best regards,