FAST and GH-bladed differ in RootMzc1

[HYFOAM]

@jjonkman

  Hi jjonkman, I recently found that for the leaf-root load, the difference between RootFxc1, RootFyc1, RootMxc1, and RootMyc1 is very small when I simulated NREL 5mw wind machine with OpenFAST and GH-Bladed respectively. However, for RootFzc1 and RootMzc1, the differences are large and the trends are different. This is shown in the figure below.
 As far as I know OpenFAST does not have DOF in the bladed z-direction, so I guess this may be the main reason for the difference in calculation.
 If my guess is correct, then how to ensure the reliability of the calculation results when making the pitch motor selection.

[jjonkman]

Dear @HYFOAM,

While OpenFAST does not currently have a blade-pitch DOF, it can still calculate the pitching moment. The pitching moment is calculated as the integral along the blade of the applied aerodynamic moments and inertial moments and applied forces, weights, and inertial forces crossed with the moment arms, which involve the blade deflections and the offsets of the mass and aerodynamic centers with respect to the pitch axis.

You haven't shown the RootFzc1 (axial force) comparison, but differences would likely be the result of differing blade mass or differing projection of the aerodynamic forces.

Best regards,

[HYFOAM]

Dear @jjonkman Thank you for your reply, I will go ahead and compare the factors you mentioned.

I have another question to ask you.

I see in the Elastodyn.dat file of the '5MW_OC4Semi_WSt_WavesWN' calculation example. The platform mass as well as the inertia are very different compared to the OC4 description file as shown below. I have a feeling that this may be a difference due to ballast water.

I would like to know which platform mass and inertia I need to use when I perform the free decay oscillation verification for the '5MW_OC4Semi_WSt_WavesWN' example? And can you provide experimental or accurate verification data about the free decay oscillation of the 5MW_OC4Semi wind turbine?

openfast ’Elastodyn.dat‘ 3.85218E+06 PtfmMass - Platform mass (kg) 2.56193E+09 PtfmRIner - Platform inertia for roll tilt rotation about the platform CM (kg m^2) 2.56193E+09 PtfmPIner - Platform inertia for pitch tilt rotation about the platform CM (kg m^2) 4.24265E+09 PtfmYIner - Platform inertia for yaw rotation about the platform CM (kg m^2) ‘Definition of the Semisubmersible Floating System for Phase II of OC4’ Documentation

[jjonkman]

Dear @HYFOAM,

The OpenFAST model of the OC4-DeepCwind semi as provided in the r-test is fully consistent with the OC4-DeepCwind specifications report. The total mass of 1.3473E7 kg includes the mass of the water ballast. However, in this OpenFAST model, only the steel mass is considered in ElastoDyn; the water ballast is included in the strip-theory solution of HydroDyn.

The results from the Phase II (DeepCwind semi) benchmark of the IEA Wind Task 30 OC4 project are publicly available in the following Google Drive: https://drive.google.com/drive/folders/0B0KGNSHvXXgCVTZpU2thUDQtNnM?resourcekey=0-p6CkChh-R5Bwd-rSYU1ycg&usp=share_link.

Best regards,

[HYFOAM]

Dear @jjonkman, Thank you for your answer to my last question.

Regarding my first question, I compared the results of leaf root load calculations for GH-Bladed, Simpack-AeroDyn and FAST, as shown below. We can see that there are obvious differences between the forces, especially the FAST forces show more drastic fluctuations and a large difference in Mz. What is the main reason for such?

In addition, which quantities should I focus on when setting up the calculation example to ensure the accuracy?

Best regards,

[jjonkman]

Dear @HYFOAM,

I would suggest simplifying the models to debug what is different in the model set ups or software implementations. Can you make the blades rigid in all three software? Can you disable aerodynamics in all three software? I would start there...

Best regards,

[HYFOAM]

Dear @jjonkman Thanks for your reply, how can I make the blades rigid in FAST? What files do I need to change?

[jjonkman]

Dear @jjonkman,

To model rigid blades in OpenFAST, set CompElast = 1 in your OpenFAST primary .fst input file and set FlapDOF1 = FlapDOF2 = EdgeDOF = False in your ElastoDyn input file.

Best regards,

[HYFOAM]

Dear @jjonkman

Thank you for your reply, I will try what you said and compare.

Best regards,

[AsIlll223]

Dear @jjonkman

I compare the difference of DTU10MW Blade RootMzc1 between OpenFAST and Bladed , it seems like the difference is large and the trends are different. This is shown in the figure below.

I'm not sure what caused this difference ，but I think maybe OpenFAST and Bladed RootMz contains different moment components. This could be OpenFAST cauculate the pitching moment as RootMzc, which is calculated as the integral along the blade of the applied aerodynamic moments and inertial moments and applied forces, weights, and inertial forces crossed with the moment arms, but the Bladed only calculate the applied aerodynamic moments as RootMzc. Could you give me some advice about the difference ?

Best regards,

[jjonkman]

Dear @AsIlll223,

I agree with your description about how OpenFAST computes RootMzc, but I can't comment on how this is done in Bladed. How do the results between OpenFAST and Bladed compare when the blade is made rigid?

Best regards,

[AsIlll223]

Dear @jjonkman

Thank you for your quickly reply. I made the blade in OpenFAST be rigid and compared the results. This is shown in the figure below.

Can I assume that when considering the blades to be rigid, the blade RootMz only cocntains the applied aerodynamic moments ? It seems that when we consider the blades to be rigid, the RootMzc of the two show the same trend, but the torque directions of the two are opposite, and the absolute values are not much different. What does this mean and the results confuse me a lot.

Best regards,

[AsIlll223]

Dear @jjonkman

I compare the difference of DTU10MW Blade Root Mz between OpenFAST ElatoDyn RootMzc and BeamDyn RootMzr , it seems the two have the almost consistently trend but their mean value difference is large. Is this result reasonable? This is shown in the figure below.

After that, I refer to https://forums.nrel.gov/t/the-function-for-aerodynamic-force-input-positions-in-elastodyn/4990 ， https://forums.nrel.gov/t/elastodyn-local-spanwise-blade-deflection-transformation/2299 and https://forums.nrel.gov/t/aerodynamic-center-offset-effects-on-blade-torsion/4841.

As you discussed in the above three topics，I learned how the aerodynamic moment calculated by AeroDyn be transfered to ElastoDyn and BeamDyn , and I found that The difference between the two transfer processes is mainly that BeamDyn uses _Subroutine Transfer_Loads_Point_toLine2, while ElastoDyn uses _Subroutine Transfer_Loads_Point_toPoint. Since BeamDyn considers the three-dimensional coordinates of the interpolation point, while ElastoDyn only considers its coordinate along the blade Root-to-Tip direction, this may be the reason for the difference. Do you think this is a reasonable explanation? If I want both to calculate the same RootMz, how do you think I should modify the ElastoDyn program?

Best regards,

[jjonkman]

Dear @AsIlll223,

Just a few comments:

• For your rigid comparison between Bladed and OpenFAST with ElastoDyn, I would question whether the aerodynamic pitching moments or offsets between the pitch axis and aerodynamic center are set consistently between the two models.
• I don't agree with your statement below. The coupling between ElastoDyn and AeroDyn and between BeamDyn and AeroDyn both involve the total three-dimensional offset between the aerodynamic and structural meshes in their spatial mesh-to-mesh mapping. See our papers involving spatial mesh mapping for more information: https://www.nrel.gov/docs/fy14osti/60742.pdf and https://dx.doi.org/10.2514/6.2015-1461.

  Since BeamDyn considers the three-dimensional coordinates of the interpolation point, while ElastoDyn only considers its coordinate along the blade Root-to-Tip direction, this may be the reason for the difference.

• Regarding the comparison between BeamDyn and ElastoDyn, I would guess sectional offsets between the pitch axis and center of mass--which are available in BeamDyn, but not in ElastoDyn--play a role. You could always eliminate any sectional offsets from the BeamDyn model (bringing it closer to the ElastoDyn model) to study that effect.

Best regards,

[AsIlll223]

Dear @jjonkman

Thank you for your quickly reply. I think your suggestion has a greater possibility as the reason. I ignored the pre-bending of the blade, and set x_r and y_r in the BeamDyn model to 0. Under this setting, Can it now be considered that the calculation nodes of BeamDyn are all at the Pitchaxis ? But I don’t know whether the Pitchaxis of BeamDyn is located at the 0.25c of the blade airfoil as default or at the other position of the blade airfoil, because I do not find Pitchaxis location input in BeamDyn but ElastyoDyn .

Best regards,

[xiong6688]

Dear @HYFOAM

Hello, I have been working on migrating the NREL 5MW OpenFAST example to GH-Bladed recently, but there are always problems with the calculation results. I have seen that you have done this work before. May I ask if you could share your NERL 5MW GHBladed example with me for learning?

Best regards,

[jjonkman]

Dear @AsIlll223,

In BeamDyn, the key points of the blade (kp_xr, kp_yr, etc.) are specified relative to the pitch axis, so, kp_xr = kp_yr = 0 corresponds to key points that lie on the pitch axis. The pitch axis is not defined as a fraction of chord, because the location of the leading and trailing edge is not needed in the calculations.

That said, the blade sectional properties are defined as 6x6 mass and stiffness matrices relative to the reference axis (which is the locii of key points). These matrices can include terms that are offset from the diagonal; some of these terms represent mass offsets, and, so, just setting the reference axis to be coincident with the pitch axis doesn't mean that the mass is aligned with the pitch axis.

Best regards,

[AsIlll223]

Dear @jjonkman

Thank you very much for your quickly reply. I agree with your point of view, it really helps a lot. In addition, I am confused that BeamDyn uses line elements to describe motion and force, while ElastoDyn uses point elements to describe motion and force. Could you tell me the reason ?

Best regards,

[jjonkman]

Dear @AsIlll223,

This is just a matter of convention. ElastoDyn currently expects blade aerodynamic loads to be input as lumped at points (in N for force and N m for moment) rather than as distributed loads per unit length (in N/m for force and Nm/m for moment), so, a point mesh is used. I'm sure ElastoDyn could be changed so that the blade aerodynamic loads are input as a line mesh using distributed loads per unit length.

Best regards,

[AsIlll223]

Dear @jjonkman

Thank you for your reply. It really helps a lot for me.

Best regards,