search

OpenFAST / openfast

Main repository for the NREL-supported OpenFAST whole-turbine and FAST.Farm wind farm simulation codes.
http://openfast.readthedocs.io
Apache License 2.0
648 stars 447 forks source link

Disagreement between BeamDyn and ElastoDyn when dynamic BEM model is used (WakeMod=2) #983

Open jiayaomeng opened 2 years ago

jiayaomeng commented 2 years ago

Bug description The BeamDyn results disagree with ElastoDyn when using the dynamic BEM model in AreoDyn. Both models are under the steady uniform wind (6 m/s) thus similar steady responses and operation conditions are expected. However, it seems the BeamDyn model bifurcates at the first several seconds and gives inaccurate results. They do agree when the classical BEM model is used (WakeMod=1).

To Reproduce All settings are consistent with the example files provided in "https://github.com/OpenFAST/r-test/tree/78d763effae41fb41ecff5143f0b486a6ac0593c/glue-codes/openfast/5MW_Land_BD_DLL_WTurb" except that I switched "WakeMod" in AeroDyn from "1 (BEM)" to "2 (DBEM)."

Expected behavior They should agree, though some little discrepancies can exist due to the different blade models they are using.

Screenshots, if applicable pitchAndRotor Torque twrMotion bldMotion

OpenFAST Version

OpenFAST Copyright (C) 2021 National Renewable Energy Laboratory Copyright (C) 2021 Envision Energy USA LTD This program is licensed under Apache License Version 2.0 and comes with ABSOLUTELY NO WARRANTY. See the "LICENSE" file distributed with this software for details.

OpenFAST-v3.0.0 Compile Info:

System Information (please complete the following information):

Additional context I noticed this issue reported by @ptrbortolotti and it seems like a bifurcation as well. I tried to compile with that new branch but the large difference between ElastoDyn and BeaDyn still exists.

jjonkman commented 2 years ago

Dear @jiayaomeng,

A couple things to try to better isolate the problem:

Best regards,

jiayaomeng commented 2 years ago

Dear @jjonkman,

Many thanks for your reply!

It turns out to be the convergence issue. The big difference still exists with the modification of GenDOF = False and AFAeroMod = 1, but after I reduced DTfrom 0.0015s to 0.0005s and NumCrctn=1, BeamDyn and ElastoDyn finally match. bldMotion

I will close this issue, thank you again!

Best wishes, Jiayao

jjonkman commented 2 years ago

Thanks, @jiayaomeng.

It sounds like you changed both DT and NumCrctn at the same time. Have you tried each of these changes independently? I'm curious which one is more effective at solving the problem. Considering the time steps you are using are already quite small, there may be an issue with the coupling between BeamDyn and AeroDyn that we need to address.

Thanks,

jiayaomeng commented 2 years ago

Dear @jjonkman,

I tried the two changes independently and found that only reducing dt to 0.0005s still doesn't work, whereas the change ofNumCrctn=1 is effective even with dt=0.0015s. That's interesting. Does that mean we are advised to add the correction step first before considering using a smaller time step when coming across the numerical instability issue?

Best wishes, Jiayao

jjonkman commented 2 years ago

Dear @jiayaomeng,

Typically adding one correction step and dropping the time step in halve have similar effect, but sometimes adding one correction step is necessary for solution accuracy. This typically indicates a reordering of the OpenFAST glue code input-output coupling algorithm is in order. I'm going to reopen this issue for now to remind us to review the BeamDyn-AeroDyn coupling. Until this issue is resolved, I recommend running with NumCrctn = 1 when using BeamDyn with DBEMT enabled in AeroDyn.

Best regards,

jjonkman commented 2 years ago

@andrew-platt -- Any ideas on this one?

andrew-platt commented 2 years ago

I'm a bit surprised that we need a correction step. It might be that there is enough high frequency motion of the blade due to the drivetrain coupling that it induces some unwanted effects in the DBEMT. This is sort of hinted at with the warning about tau:

FAST_Solution:FAST_AdvanceStates:AD_UpdateStates:BEMT_UpdateStates(node 1, blade 1):ComputeTau:Rotor-averaged axial induction factor is greater than 0.5; limiting time-varying tau1.

I'm not entirely sure how we would fix this issue as I'm not sure if it is an issue in BeamDyn, in AeroDyn 15, or in the coupling code. I suppose it could be in part related to the qfit parameter in BeamDyn and #818, but it may also be an interaction of AD15 DBEMT with the large initial transients we've seen due to the BeamDyn to ElastoDyn coupling at the hub (the drivetrain DOF tends to make those worse).

ebranlard commented 1 year ago

We have seen similar issues. Using DBEMT_Mod=3 instead of DBEMT_Mod=1 should help, but we still don't know why the discrete formulation (DBEMT_Mod=1) is sensitive to number of corrections and time step when beamdyn is used.

jiayaomeng commented 6 months ago

Dear @jjonkman,

I just wanted to follow up on the possible BeamDyn-AeroDyn coupling issue that we discussed earlier. I came across the large discrepancy between ElastoDyn and BeamDyn again, even with NumCrctn = 1 and DBEMT_Mod=3 (as @ebranlard suggested). Please take a look at the following simulation results of the 5MW ITI-Barge floating wind turbine example. The two models match very well when the wind speed is under the rated speed (8 m/s), but disagree when above (14m/s).

Here are my Aerodyn settings: 2 WakeMod - Type of wake/induction model {0=none, 1=BEMT, 2=DBEMT, 3=OLAF} 2 AFAeroMod - Type of blade airfoil aerodynamics model {1=steady model, 2=BL unsteady model} 3 DBEMT_Mod - Type of dynamic BEMT (DBEMT) model {1=constant tau1, 2=time-dependent tau1, 3=constant tau1 with continuous formulation} 6 UAMod - Unsteady Aero Model Switch {2=B-L Gonzalez, 3=B-L Minnema/Pierce, 4=B-L HGM 4-states, 5=B-L 5 states, 6=Oye, 7=Boeing-Vertol} Simulation control setting in the .fst file 0.00125 DT - Recommended module time step (s) 2 InterpOrder - Interpolation order for input/output time history (-) {1=linear, 2=quadratic} 1 NumCrctn - Number of correction iterations (-) {0=explicit calculation, i.e., no corrections} I used the ROSCO controller with the floating feedback being enabled only for the 14m/s case. Settings in the DISCON.IN file 2 ! Fl_Mode - Floating specific feedback mode {0: no nacelle velocity feedback, 1: feed back translational velocity, 2: feed back rotational veloicty} -20.000 ! Fl_Kp - Nacelle velocity proportional feedback gain [s] and I am using the latest OpenFAST v3.5.1.

I had expected that BeamDyn results should not be very different from ElastoDyn for this 5MW turbine, since the platform pitch and blade flapwise velocities under 14 m/s are not insanely larger than those under 8 m/s. I was wondering if the discrepancy is induced by the BeamDyn-AeroDyn coupling when, for example, the blade pitch controller comes into play. Any suggestions would be very much appreciated!

compareEDBD_wind8

compareEDBD_wind14

jjonkman commented 6 months ago

Dear @jiayaomeng,

Are you using the OpenFAST model of the NREL 5-MW baseline wind turbine atop the ITI Energy barge provided by NREL, with the modifications to the AeroDyn inputs and the change to the ROSCO controller that you mention? Did you make any other changes to the model?

Regardless, perhaps the results are not too surprising because blade deflection is largest around rated and your simulation has a mean wind speed just above rated. I would guess that the BeamDyn model is showing sizeable blade twist, which is somewhat compensated in ElastoDyn by the use of larger blade-pitch angles.

You sound concerned with the DBEMT_Mod = 3 and UAMod = 6 results; is that because the comparison between the solutions with ElastoDyn and BeamDyn are more similar with simpler aerodynamic settings such as WakeMod = AFAeroMod = 1?

Best regards,

jiayaomeng commented 6 months ago

Dear @jjonkman,

Many thanks for your reply! The only change I made is to use a 6*6 linear stiffness matrix in HydroDyn to represent the moorings' elasticity. I tinkered with different combinations of WakeMod and AFAeroMod, and compared the results calculated from ElastoDyn and BeamDyn. It seems the issue comes from the unsteady aerodynamics. The two models disagree once AFAeroMod is set to 2. Could you further advise on this, please? Thank you!

compareEDBD_wind14_debugGitHub

compareEDBD_wind14_debugGitHub2

compareEDBD_wind14_debugGitHub3

Best wishes, Jiayao

jjonkman commented 6 months ago

Dear @jiayaomeng,

Thanks for narrowing this down. Can I ask for one more check? How do the models compare if keep AFAeroMod = 2, but switch UAMod from 6 to something else like 3 or 4?

Best regards,

jiayaomeng commented 6 months ago

Dear @jjonkman,

The two models match very well after switching UAMod to 4. Does this indicate some bug in the 1-state stall model? Many Thanks, Jiayao

compareEDBD_wind14_debugGitHub4

jjonkman commented 6 months ago

@jiayaomeng -- I've not used UAMod = 6 myself before, but it sounds like there is an issue. I would suggest using UAMod = 4 for now.

@ebranlard -- Do you know what the issue with UAMod = 6 could be?

ptrbortolotti commented 6 months ago

we've had problems with UAMod6 when polars are very nonlinear. the internal logic of openfast to identify the linear regime might fail and the outputs become unreliable. this points to a weakness of the theory more than a weakness of openfast. airfoil polars, especially toward the root, are commonly very nonlinear

jiayaomeng commented 6 months ago

Thanks for the information,@ptrbortolotti! However, it still puzzles me why UAMod=6 appears to work fine with BeamDyn for the 8m/s case.