FSAero marix and coordinate systems


for the coupling of FAST with another program I need the aerodynamic forces on every blade element in the global (inertial frame) coordinate system.
I have been digging through the source code but I am still not sure on how to interpret the things I have found.

In the “AD_CalculateLoads” function (AeroDyn.f90) the forces calculated in the “ELEMFRC” function are written into the blade load structure:

... ADCurrentLoads%Blade(IElement,IBlade)%Force(1) = ... ...

Then the forces are multiplied by the local axes of the trailing edge coordinate system (FAST.f90):

[code] …
! Call AeroDyn through AeroCalc() and fill FSAero() and MMAero() with
! the resulting forces (AeroForces(:)):
! NOTE: AeroForces(1) = element normal force per unit span in the m1 direction (N/m).
! AeroForces(2) = element tangential force per unit span in the -m2 direction (N/m).
! AeroForces(3) = element pitching moment per unit span in about the m3-axis (N-m/m).

FSAero(K,J,:slight_smile: = ADAeroLoads%Blade(J, K)%Force(1) * te1(K,J,:slight_smile: + ADAeroLoads%Blade(J, K)%Force(2) * te2(K,J,:slight_smile:

But in the comments it says that the AeroForces are given in the m-coordinate system (see above).
All the coordinate systems axes seem to be defined with respect to the inertial frame.
Therefore I think the forces in the FSAero matrix are the forces in the intertial frame and therefore the ones I need.
But then still the comment about the m-coordinate system confuses me.
Are my assumptions correct or am I totally off track?

Best regards


Dear Marc,

In AeroDyn v13, the blade aerodynamic loads are returned to FAST in a coordinate system that originates at the aerodynamic analysis node and is oriented such that x-axis points to the nominal suction side of the airfoil, the y-axis is aligned with the local chord and points toward the trailing edge, the z-axis is directed along the blade toward the tip. Inside FAST, this is known as the trailing-edge (te) coordinate system, so, the calculation you showed from SUBROUTINE FAST.f90/RtHS() is correct.

In AeroDyn v12.58, however, the blade aerodynamic loads were returned to FAST in what FAST calls the “m” coordinate system – a coordinate system rotated from the te coordinate system via the angle blade pitch + aerodynamic twist (this is a coordinate system that is aligned with the rotor plane when there is no blade deflection). It appears the comment you showed just before FSAero is calculated in SUBROUTINE FAST.f90/RtHS() was not corrected with the release of AeroDyn v13. Sorry for the confusion. We’ll be sure to change this comment in the next release of FAST.

For more information on the changes to FAST with the release of AeroDyn v13, please see the “Addendum to the AeroDyn User’s Guide”: wind.nrel.gov/designcodes/simula … erface.pdf.

Best regards,

Thank you Jason for your fast reply!

Best regards


I am again stuck at the FAST coordinate system transformation. The results I get are not as expected.

The blade aerodynamic loads are returned to FAST in the trailing edge (te) coordinate system.
But I need the aerodynamic loads in the inertial frame coordinate system for passing them to another program.
My idea was to invert the te-Matrix for every blade element and multiply the corresponding forces (in the te coordinate system) with this inverted matrix as the te-Matrix is determined from the intertial frame coordinate system by a series of rotations.
At the moment I am not really happy with the results but can someone confirm that in theory this should work?
If it doesnt what approach would you recommend?

Best regards

Dear Marc,

Your approach sounds correct to me.

Perhaps your problem is that the inertial frame coordinate system internal within FAST v7 (about which te is determined) does not follow IEC convention? That is, z1 in FAST = xi from the IEC coordinate system, z2 in FAST = zi from the IEC coordinate system, and z3 in FAST = -yi from the IEC coordinate system (the y and z axes are swapped between the IEC convention and the internal FAST v7 coordinate system).

Best regards,

Hallo Jason,

what consuses me is the following:

AeroDyn: “Addendum to the User’s Guides for FAST, A2AD, and AeroDyn Released March 2010 - February 2013”

… the X axis pointing in the (nominally) downwind (zero degree wind) direction, the Y axis pointing to the left
looking along the positive X axis, and the Z axis pointing vertically upward … (page 12)

There is also a picture on page 14.

FAST: “FAST User’s Guide” - August 2005 (FAST Version 6)

Inertial Frame Coordinate System
xi axis Pointing in the nominal (0°) downwind direction.
yi axis Pointing to the left when looking in the nominal downwind direction.
zi axis Pointing vertically upward opposite to gravity.

x - downwind
y - left (looking from upwind)
z - up

It reads like all initial coordinate systems are the same. Did the FAST System change in Version 7 or where is my mistake?
Because in the FAST.f90 there is following transformation:

      ADAeroMarkers%Blade(J,K)%Orientation(1,1) =     te1(K,J,1)
      ADAeroMarkers%Blade(J,K)%Orientation(2,1) =     te2(K,J,1)
      ADAeroMarkers%Blade(J,K)%Orientation(3,1) =     te3(K,J,1)
      ADAeroMarkers%Blade(J,K)%Orientation(1,2) = -1.*te1(K,J,3)
      ADAeroMarkers%Blade(J,K)%Orientation(2,2) = -1.*te2(K,J,3)
      ADAeroMarkers%Blade(J,K)%Orientation(3,2) = -1.*te3(K,J,3)
      ADAeroMarkers%Blade(J,K)%Orientation(1,3) =     te1(K,J,2)
      ADAeroMarkers%Blade(J,K)%Orientation(2,3) =     te2(K,J,2)
      ADAeroMarkers%Blade(J,K)%Orientation(3,3) =     te3(K,J,2)

This looks like the coordinate systems in FAST and AeroDyn are not based on the same initial coordinate system.

Best regards

Dear Marc,

Your understanding of the coordinate systems from the AeroDyn and FAST User’s Guides is correct. However, since its inception, the coordinate systems used internally by FAST’s equations of motion have used a different inertial frame coordinate system, as I spelled out in my prior post (the z1/z2/z3 system, where the y and z axes are swapped relative to the IEC coordinate system). It would be very difficult to change the internal FAST coordinate systems, so, we’ve been forced to implement transformations in parts of the FAST source code pertaining to the inputs, outputs, and communication with other modules.

Best regards,