Influence of BlCrvAC and BlSwpAC on AeroDyn outputs -- comparison standalone and OpenFAST

[ldouteau]

Hi,

While validating a coupling of AeroDyn, I came through a comparison between OpenFAST and AeroDyn standalone (OpenFAST master branch v2.3.0). The OpenFAST test cases were as simple as possible to compare with AeroDyn (Elastodyn with motion DOFs unactivated, InflowWind with constant uniform wind, AeroDyn). In other words, it defines a rigid onshore wind turbine with prescribed rotation of the rotor and no control. I expected the results output by AeroDyn/standalone to be similar to those from AeroDyn/OpenFAST. Am I wrong ?

In fact, I observed two different behaviors, linked to the parameters BlCrvAC and BlSwpAC in AeroDyn's blade file:

• When BlCrvAC=BlSwpAC=0m for each aerodynamic node, both simulations provide the exact same results.
• Otherwise, differences show up from the very beginning of the simulation. As soon as BlCrvAC and BlSwpAC are non-zero on a given aerodynamic node, the evaluation of the local aerodynamic outputs at this node differ.

To illustrate the issue, I ran a test case using the NREL 5MW turbine, for which BlCrvAC and BlSwpAC are non-zero. The following figure presents the local AoA at a given node for 4 different configurations:

• Blue : OpenFAST with regular 5MW blade
• Orange : AeroDyn standalone with regular 5MW blade
• Green : OpenFAST with modified 5MW blade (BlCrvAC=BlSwpAC=0m). Curve superposed with red one
• Red : AeroDyn with modified 5MW blade (BlCrvAC=BlSwpAC=0m). Curve superposed with green one Interestingly, at t=0s, the offset between Blue and Red/Green is twice the one between Orange and Red/Green. This is true for several local parameters, and this is independent from the values of BlCrvAC and BlSwpAC.

I investigated a bit, and I feel like the translation velocity evaluated at blade nodes AD%u%BladeMotion(k)%TranslationVel may generate this difference. For a simulation with the 5MW blade, I compared at t=0s the position of blade aerodynamic nodes u%BladeMotion(1)%position and the translation velocity AD%u%BladeMotion(1)%TranslationVel in AD_CalcOutput, for a simulation with AeroDyn/standalone and another with OpenFAST. While minor differences exist for the position, the translation velocity varies a lot. The differences in position and translation velocity can be found in the file attached (in meters). AD_vs_OF_Blade1_position_translationvel.txt

I'm a bit confused by the computation of this translation velocity in those 2 test cases.

• AeroDyn's driver computes it from a prescribed rotation of the rotor and the position of aerodynamic nodes. This directly takes into account the bending parameters BlCrvAC and BlSwpAC.
• From what I understand, during an OpenFAST simulation, the rotation is performed within Elastodyn's routines. ElastoDyn's blade mesh is used to compute the translation velocity, which is then interpolated back onto the aerodynamic nodes. I don't get how the correct velocity fields can be obtained, as ElastoDyn has no idea of what BlCrvAC or BlSwpAC may be.

Sorry for the looong question, I tried to keep it precise and to expose clearly what I went through. I joined a test case to reproduce the problem, see below.

Have a nice day,

Louis Douteau

To Reproduce All the results presented here have been obtained from the test case attached. 5MW_Land_DLL_WTurb_compAD.zip

Steps to reproduce the behavior: 1- update in the Makefile OF_FOLDER_PATH = path to OpenFAST repo 2- choose the AeroDyn blade file (NRELOffshrBsline5MW_AeroDyn_blade.dat or NRELOffshrBsline5MW_AeroDyn_blade.dat.noCrvSwp) 3- "make run" to run both OpenFAST and AeroDyn 4- "make plot" to compare outputs (comparative plots written to comp*.png)

[jjonkman]

Hi @ldouteau,

Thank you for your thorough description of the problem.

My theory is that the difference in velocity at the aerodynamic analysis nodes that you are seeing is related to interpolation in the Line2-to-Line2 mesh-to-mesh mapping in the coupled ElastoDyn-AeroDyn solution of OpenFAST versus the analytically exact calculation used in the AeroDyn driver. If my theory is correct, then I would expect to see the effect of interpolation go to zero as the number of structural analysis nodes in ElastoDyn (BldNodes) increases, bringing the coupled ElastoDyn-AeroDyn solution of OpenFAST closer (and eventually match) the solution from the AeroDyn driver. Can you run this test and report the results?

If increasing BldNodes in ElastoDyn does not improve the results, I would guess that there is a bug somewhere in the kinematics math--either in the AeroDyn driver or the Line2-to-Line2 mesh-to-mesh mapping, but this would surprise me as this math has been checked many times before.

Best regards,

[ldouteau]

Hi @jjonkman ,

Thank you for your reactivity !

I went through your suggestions, first trying to increase the number of nodes in ElastoDyn, but the results remained unchanged. See the upcoming plots ran on the same test case as yesterday:

• Blue and Orange respectively OpenFAST and AeroDyn with 18 ED nodes
• Green and Red respectively OpenFAST and AeroDyn with 118 ED nodes. Green and Blue (resp. Red and Orange) data sets superpose perfectly.

I agree to your point that the interpolation is probably the cause of the differences observed. I agree too that either the Line2-to-Line2 function or the AeroDyn implementation are probably not bugged, I guess this issue would have came out earlier then. My interpretation would be that, as soon as prebending parameters are non-zero, the aerodynamic nodes are displaced, moved away from the structural nodes. The interpolation would then loose precision.

To clarify this I attached two files to illustrate this point, which compare the positions of aerodynamic and structural nodes (evaluated at the Line2_to_Line2 call) :

• for the modified 5MW blade, with BlCrvAC=BlSwpAC=0m at each aerodynamic node. ElastoDyn and AeroDyn nodes almost coincide, the interpolation is straightforward, and ultimately AeroDyn/standalone and OpenFAST compare well. ED_AD_interpolation_5MW_noCrvSwp.txt
• for the actual 5MW blade, withBlCrvAC and BlSwpAC non-zero. An important deflection is observed along the y-axis between both samplings, which I assumed from the previous situation to use the same coordinate system. The interpolation realized would be less relevant, and may thus explain the differences with AeroDyn/standalone where the motion is computed at the exact position of aerodynamic nodes. ED_AD_interpolation_5MW.txt

I also tried to compare the evolution of the offset with BlCrvAC alone on a single node. I just went with BlSwpAC=0m on a given aerodynamic node, varied BlCrvAC and examined the evolution of the relative velocity (could have been another local parameter). The upcoming plot exposes Vrel(BlCrvAC,t=0s)-Vrel(BlCrvAC=0m,t=0s) for both AeroDyn/standalone (AD) and OpenFAST (OF). The datasets are perfectly linearly fitted (R²=1), with the 0.01 offset due to the format of outputs. The evolution of Vrel with BlCrvAC is twice faster when simulating with OpenFAST, I don't know if it can help finding the source of the error.

What is your opinion about these observations ? Let me know if you need me to perform other checks.

Have a nice day,

Louis

[jjonkman]

Hi @ldouteau,

OK, I tracked down the bug, which was in the rotational velocity field of the ElastoDyn blade output mesh, where the rotational speed was accidentally doubled. This bug would effect any coupled AeroDyn-ElastoDyn solution with curvature or sweep offsets set in AeroDyn. The bug should be fixed in PR #453.

Best regards,

[ldouteau]

Hi @jjonkman, Your correction solved the problem. Thank you for the efficient follow-up ! Best regards, Louis