Hi,
I am using FAST_v8.15.00a-bjj with Test26 from the CertTest directory as my baseline setup. My goal is to extract translation and rotation parameters of the blade at different radial positions in order to animate and render my wind turbine in 3ds max. Therefore, I need to convert the rotation parameters from BeamDyn in Wiener-Milenkovic form to rotation matrices or rotation angles about each axis.
Right now I am using equation 5.17 from section 5.4 of the BeamDyn manual to convert to rotation matrices. However, my results do not appear plausible. The resulting matrices apply scaling and their determinant is not 1. The BeamDyn manual mentions something about a rescaling operation in order to remove singularities. Can this be the root of my problem?
Can anyone help me convert from Wiener-Milenkovic rotations parameters (for example outputs N1RDxr, N1RDyr and N1RDzr from FAST/BeamDyn) to rotation matrices or rotation angles about each of the axis?
Thank you for your help
Jan
Hi Jan,
I am doing the similar task right now. So, I am studying about the Wiener-Milenkovic parameters…
Just wondering have you solve your problem yet?
Thanks
We’re aware of this problem at NREL, as we’ve seen similar problems ourselves. We suspect that there is a bug in BeamDyn in the section of code that converts the rotations from the internal coordinate system to the coordinate system used for output. Even though Qi Wang–the lead developer of BeamDyn–has departed NREL, he is still looking into it and we hope to release a correction soon.
Best regards,
Hi Jason,
Just want to follow up on this topic.
Since there are errors in converting rotational/angular deflections in BeamDyn, does it mean that the angle of attack (AoA) from AeroDyn has errors as well?
BeamDyn and AeroDyn are coupled via FAST, so if the angular deformations from BeamDyn are wrong, AeroDyn may computes wrong AoAs based on the wrong info. from BeamDyn.
Are these errors only limited to computing angular deformations for BeamDyn outputs? May I assume that AoAs from AeroDyn are correct with these BeamDyn errors?
Thank you.
Dear Daniel,
The rotations sent from BeamDyn to AeroDyn, and the associated angle of attack, are correct. The rotations computed within the BeamDyn equations of motion are also correct. The error is in the section of code related to how the internal rotations are converted before being written to the output file.
Best regards,
Hi everyone,
We are currently trying to use BeamDyn, and we do not well understand the relation between the rotation tensor expressed in terms of Wiener-Milenkovic parameters, and the Direction Cosine Matrix (DCM) written in the BeamDyn manual (5.18) at the page 23.
Indeed, in the manual, the DCM is equal to the transpose rotation tensor.
If we are looking to the book Flexible Multibody Dynamics, SOLID MECHANICS AND ITS APPLICATIONS Volume 176 by O.A.Bauchau, we can observe at page 114 that the DCM is just equal to the rotation tensor (eq 4.18).
With simple modifications to the code, we have been able to get and analyse the orientation of the beam. This orientation was coherent with the output DCM of BeamDyn.
Thus, can someone explain where this difference comes from between these two sources and why a transpose is needed ?
Because if the Wiener-Milenkovic parameters output from BeamDyn define the actual orientation of each cross section relative to the undeflected orientation (as it is stated in the topic “Extract blade tip torsional deformation from the Wiener-Milenković parameters in BeamDyn”), we do not understand why a transpose is required.
Thanks for your help.
Best regards,
Alban
Dear Alban,
I don’t have Bauchau’s book at home with me to double check (I’m currently working at home due to the pandemic), but my understanding is that the rotation matrix (R) stated in the BeamDyn documentation is defined is such that premultiplication of a vector in local coordinates (v) by R gives the vector in global coordinates (V). And the the Direction Cosine Matrix (DCM) used in the FAST / OpenFAST modularization framework is the opposite–premultiplication of V by DCM gives v:
V = R*v
v = DCM*V
Thus, because the inverse of a rotation matrix or DCM is its transpose, then
R = DCM^-1 = DCM^T
Best regards,
Dear Jason,
Thank a lot for your answer.
However, we are still a bit confused with all the sources relative to rotation matrix, DCM and Wiener-Milenkovic parameters.
We have made test imposing forces and moment at the tip of the beam (the other tip being fixed), and by printing the DCM resulting of the computation, we have concluded that DCM transforms the undeformed vector of the beam (U) to the deformed one (d), all expressed in the reference blade coordinate system : d = DCM. U .
In your answer, you state the rotation matrix (R) in the BeamDyn documentation is defined is such that premultiplication of a vector in local coordinates (v) by R gives the vector in global coordinates (V) : V= R*v
If Global frame = frame fixed to the bottom of the tower (or frame related to the undeformed beam is no rigid motion), and Local frame = frame fixed to the deformed beam, then the transposition between R and DCM looks meaningful.
But, you also state that “The Wiener-Milenkovic parameters output from BeamDyn define the actual orientation of each cross section relative to the undeflected orientation.” in the post 4828. This is also stated in the BeamDyn documentation “Sectional angular/rotational deflection Wiener-Milenković
parameter (relative to the undeflected orientation) at Nβ expressed in r” page 56.
But since the relation (5.17) between the Wiener-Milenkovic and the rotation matrix expressed in section 5.4. page 23 of the BeamDyn documentation is similar to the one given in Wang et al “Geometric Nonlinear Analysis of Composite Beams using Wiener-Milenković Parameters” with C^T=R, we think all the elements are not consistent. May be there is something wrong in the paper of Wang ?
Thanks for your help,
Best regards,
Alban Leroyer
Dear @Jason.Jonkman,
I am studying the “FAST CoordinateSystems” file in the ElastoDyn Users Guide and Theory Manual for OpenFAST (4.2.7. ElastoDyn Users Guide and Theory Manual — OpenFAST v3.5.3 documentation). During my study, I derived the first equation on the first page of that file, as shown in the red box in the figure below. However, my derived equation differs from the equation in the file in terms of the signs of the three rotation angles.
Could you provide me with materials regarding the detailed derivation of the theoretical equation in the file? If there are any books on the topic, it would be even better. Thank you!
Best regards,
.
Dear @Yangyang.Li,
If you take only one of the rotations, e.g., rotation theta_3 about X_3, the transformation is:
[ 1 theta_3 0;
-theta_3 1 0;
0 0 1 ]
This makes sense because x_1 will rotate about X_3 a small amount from X_1, pointing slightly toward X_2, so, the sign on theta_3 in the first row should be positive. Likewise, x_2 will rotate a small amount from X_2, pointing slightly away from X_1, so, the sign on theta_3 in the second row should be negative.
Best regards,
Dear @Jason.Jonkman ,
Thank you for your prompt responses. However, I still have two questions regarding the coordinate systems and the orientation of the angles in the file:
- In the figure below, the red text represents the coordinate system of the tower, with the X_2 axis pointing along the tower’s central axis toward the top, while the blue text represents the coordinate system of the blade, with the X_3 axis pointing along the blade’s pitch axis toward the tip. Is this correct?
- Under your guidance, I believe that the three rotation angles θ1 to θ3 are considered positive in the clockwise direction. Therefore, I have illustrated the displacements in the X direction resulting from rotations about the X_2 and X_3 axes, as shown in the figure below. The coordinate system of the tower is defined in the same way as the coordinate systems above.Is this correct?
Best regards,
Dear @Yangyang.Li,
Regarding (1), I agree that the red and blue coordinate systems are consistent with how the internal coordinate systems are defined within ElastoDyn. That said, for the tower, the red coordinate system is not consistent with the tower coordinate system ElastoDyn uses for output, in which case X_1 is correct, but X_2 should be X_3 and X_3 should be -X_2.
Regarding (2), I don’t agree. The rotations (theta) should be positive about their respective axis. Both theta_3 and theta_2 are shown negatively. Your equation is correct and matches the originally documented solution.
Best regards,
Dear @Jason.Jonkman ,
Thank you for your prompt responses. However, I still have a question regarding the orientation of the angles in question 2:
With your guidance, I changed the orientation of my rotation, so now the rotation θ3 about X_3 is considered positive. However, I noticed that in the upper half of the cross-section where X_2 is positive, the rotated displacement in the X_1 direction becomes negative, which is inconsistent with the signs of the transformation matrix, as illustrated in the figure below. Is this incorrect?
Additionally, could you provide me with a transformation matrix for a three-blade system using pitch control, which is for the transformation from the di (1-3) axes to the rf (1-3) axes? It seems that the “Rotor-Furl Coordinate System” is designed for a two-blade system with rotor-furl control.
Best regards,
Dear @Yangyang.Li,
Regarding theta_3, the arrow you are pointing to is for x_2, not x_1. For x_1, the theta_3 term is positive along X_2. For x_2, the theta_3 term is negative along X_1.
The rotor-furl (rf) coordinate system relative to the nacelle-yaw (d) coordinate system is the same for 2- and 3-bladed rotors.
Best regards,
