Pure Aerodynamic Force Discrepancies

Hi everybody,

I am facing some problems when comparing the thrust forces “RotThrust” and “RtAeroFxh” . My model is a simplification of the 5MW onshore reference wind turbine where no pre-cone neither tilt is applied (both set to zero). All my DOF of the turbine are FALSE except the generator DOF.
I run wind step simulation to obtain my thrust force and coefficient when the turbine is normally operating. Then I plot the steady value over wind speed.


I have read another post where the discussion of the “RotThrust” value was discussed ( AeroDyn Outputs ). However, I do not understand why in this case my values of “RotThrust” and “RtAeroFxh” are not identical if I have tilt and pre-cone angle set as zero.

Any hint on that?

I attach my Elastodyn file in case it helps.

Thank you in advance
Elastodyn_operational.txt (14.3 KB)

Dear Albert,

Indeed, the way you’ve set up the model should lead to equal values for output RotThrust from ElastoDyn and RtAeroFxh from AeroDyn.

Are you by chancing using FAST v8.12? In FAST v8.12, the aerodynamic load data at the root and tip could be lost in the connection between AeroDyn and ElastoDyn, which I would could imagine would produce the result you are seeing. To correct this, we changed the blade mesh in the ElastoDyn model in FAST v8.13 and newer to ensure that all of the aerodynamic load data from AeroDyn was being transferred to ElastoDyn consistently. Thus, I suggest you upgrade to the latest version of FAST (now FAST v8.16) to include this correction.

Best regards,

Dear Jason,

I have upgraded to the new FAST version and run the same case :

It seems correct to me now !

Thank you for your support.

Great!

Hi again Jason ,

I ran now a turbulent time series ( same conditions as before ) and compare the two parameters.

Is there any dynamics involved between the two FAST outputs?

I am a bit confused why they are not the same value considering there is not pre-cone neither tilt.

Any idea why they are not the same?

Thank you,

Dear Albert,

I would expect the results to match with your simulation setup even with turbulent wind.

From your plot, it looks like RotThrust and RtAeroFxh match up until 322 seconds–are the results consistent earlier in the simulation? If so, what happens at 322? Or do RotThrust and RtAeroFxh match better at some simulation times than others randomly throughout the simulation?

Best regards,

Dear Jason,

It randomly matches. I only post a part of the simulation.

I plot the complete time-series and the relative error now.

Thank you for your support.

Dear Albert,

I set-up a case similar to yours and obtained similar results, except that the error between RotThrust and RtAeroFxh that I calculate is usually less than 0.5% rather than the 10% you calculate. (In my case, I simply took Test18, disabled gravity, disabled all DOFs except GenDOF, set the ShftTilt to 0, and added RotThurst and RtAeroFxh as outputs.) Any ideas why your error is much larger than mine?

Regardless, I now understand what is happening. The difference between RotThrust and RtAeroFxh is related to how the coupling between the ElastoDyn and AeroDyn modules happens in the FAST glue code. After the ElastoDyn and AeroDyn states are updated when advancing time from step n to n+1, the input-output solve at step n+1 in the FAST glue code first uses extrapolated inputs (aerodynamic loads from AeroDyn) to calculate ElastoDyn outputs, then the outputs of ElastoDyn (rotor motions) are transferred as input to AeroDyn for it to calculate its outputs (aerodynamic loads), then both the ElastoDyn and AeroDyn outputs (including RotThrust and RtAeroFxh) are written to a file. RotThrust and RtAeroFxh may differ because RotThrust is based on extrapolated inputs rather than the consistent outputs from AeroDyn. I also ran a case where I added one correction step (by setting NumCrctn=1 in the FAST primary input file), which reduces the error between RotThrust and RtAeroFxh by an order of magnitude. Reducing the time step or adding more corrections would further reduce the error. However, we’ve set-up Test18 already with what we believe are suitably converged values of the time step and number of corrections.

I hope that helps.

Best regards,

Dear Jason,

I reduced the time step to half of what I was having before ( I’m using now 0.005) and I get same magnitude of the error.
It seems I was using a big time step.

Thank you for your response and explanation.