Hi @Jason.Jonkman ,
We have coupled our structural solver with OpenFAST through Aerodyn_Driver_subs.f90 and Aerodyn_Driver_Types.f90. We use the Aerodyn, Inflowwind and Servodyn modules, and our inhouse code for hydrodynamics, elasto/blade-dynamics and mooring system. Previously we were coupling to FAST 3.0.0 without any issues. Now are coupling to FAST 3.5.3, but using the interfaces of Aerodyn_Driver_subs.f90 and Aerodyn_Driver_Types.f90 from FAST 3.0.0 (because the interface routines changed a lot from FAST 3.0.0 to FAST 3.5.3). For the NREL 5MW floating wind turbine we are getting heavy fluctuations in GenTq and GenPwr as we increase the wind speed in a stepped manner from 5-10-15-20 m/s. The fluctuations are most prevalent around 10 m/s wind speed shown below
All the other results match.
Any idea on why this would occur ? Do we need the new coupling routines to get accurate results ?
When coupled with FAST 2.6.0 it’s giving proper result as shown below
FAST results are shown below
Hi @Ashok.Jammi,
You have a really interesting use case! Without knowing the details of which routines you are calling, it is a little difficult to know where the issue is. In the three years between the 3.0.0 and 3.5.3 releases, we had two major restructurings of the AeroDyn driver, and over 40 separate pull requests modifying the AeroDyn code. Pinpointing exactly what changed will be somewhat difficult, but we may be able to isolate some likely areas to look.
Combining the AeroDyn_Driver_Subs.90 and associated _Types.f90 from 3.0.0 with the newer AeroDyn code from 3.5.3 is not a use case that we expected. My suspicion is that there may be some new or modified variable not getting set correctly during the AeroDyn initialization or time step calls by the old interface. For example, we added an AeroProj_Mod variable to AeroDyn for better modeling of VAWT turbines. While this particular variable should default correctly if not set, there may be other initialization variables that are not getting set right when the older AeroDyn_Driver_Subs.f90 is used with the newer AeroDyn.
If you want to continue using the older interface, I suggest trying the following:
- Check what new variables were added to the AeroDyn_Init (such as in the
AD_InitInputType data structure). Are there any new variables not getting set, or whose purpose was modified/expanded?
- Similarly, are there any variable changes in the
AD_InputType data structure?
Alternatively, upgrading to the later 3.5.3 AeroDyn_Driver_Subs.f90 may solve the issue. However, I can understand your hesitation in wanting to do that as there are a lot of changes introduced with multi-rotor capabilities.
Andy
Hi @Andy.Platt ,
Thank you so much for your insights.
In AD_InputType these are the 2 new fields that are added
But these aren’t relevant to the interface routines.
In AD_InitInputType we have :
The highlighted variables - are initialized in the new AeroDyn_Driver_Subs.f90
May be I should find out a get around to initialize them.
But finally as you say updating to 3.5.3 is the best solution - however since the data structure AeroDyn_Data - is removed in AeroDyn_Driver_Types.f90 - this is becoming a daunting task -as all our internal interface routines depend on that.
Thanks,
Ashok
