All of the NREL 5-MW Baseline wind turbine FAST models (http://wind.nrel.gov/public/jjonkman/NRELOffshrBsline5MW) have their controller implemented as a Dynamic Link Library (DLL) in the style of the GH Bladed code. These controller DLLs include logic for variable-speed generator torque and collective blade pitch-to-feather control. The standard version of the FAST.exe that comes with the archive of FAST v6.01 does not have a direct interface to GH Bladed-style DLL controllers. However, the FAST v6.01 archive contains a source file, BladedDLLInterface.f90, which when compiled in FAST, can be used to link GH Bladed-style DLL controllers to FAST models. See the FAST User's Guide for information on how to perform this recompile. Alternatively, you can find a version of the FAST.exe already compliled with the BladedDLLInterface.f90 source file here: http://wind.nrel.gov/public/jjonkman/FAST/FAST_v6.02c-jmj_AeroDyn_v12.58_BladedDLLInterface.exe.

In FAST model, if I want to use a DLL controller , which was used in GH Bladed, to control Pitch angle and generator torque, I need to compile FAST including source file BladedDLLInterface.f90. Should I change anything in the routine of BladedDLLInterface.f90 ?

For 5MW_Onshore example, I compiled FAST without changing anything in source file BladedDLLInterface.f90, to get the FAST.exe.
Then Aero, Blade, Tower, Wind, Linear, Adams_specific input files and DISCON.dll controller are copied into the FAST.exe directory. I ran the simulation and compared the results with the simulation of version FAST_v6.02c-jmj_AeroDyn_v12.58_BladedDLLInterface.exe downloaded from http://wind.nrel.gov/public/jjonkman/FA ... erface.exe. The output results are the same. Does that mean we do not need to change the routine BladedDLLInterface.f90 if for a FAST model we want to use DLL controller which is suitable for GH Bladed.

Is the controller DISCON.dll for different NREL 5-MW Baseline wind turbine FAST models the same controlller? I tried each controller for 5MW_Onshore example and got the same output results.

You only need to change the BladedDLLInterface.f90 source file in the case where you need to specify one or more of the paremeters in MODULE BladedDLLParameters(). This MODULE stores model-specific inputs that are available in the Bladed code, but which are not available inputs in FAST. These parameters are passed to the controller DLL, so, if you DLL uses one or more of the parameters, you will need to define them properly.

The DLL controllers supplied with the NREL 5-MW models do not use any of the parameters from MODULE BladedDLLParameters(). So, you don't need to change anything in the BladedDLLInterface.f90 source file to use the NREL 5-MW DLL controllers.

There are five models of the NREL 5-MW wind turbine available from: http://wind.nrel.gov/public/jjonkman/NR ... rBsline5MW. These models include: the (1) onshore version of the 5-MW turbine, (2) the 5-MW turbine installed on a fixed-bottom monopile with rigid foundation in 20m of water, (3) the 5-MW turbine installed on the floating ITI Energy barge, (4) the 5-MW turbine installed on a floating Tension Leg Platform, and (5) the 5-MW turbine installed on a floating spar-buoy (based on the IEA Annex XXIII OC3 project's modifications to the Hywind concept). Models (1) (2), and (4) use the same DLL controller. The pitch control gains in model (3) are reduced according to the controller modifications documented in Chapter 7 of my PhD thesis-turned NREL report: http://www.nrel.gov/docs/fy08osti/41958.pdf. The pitch control gains and the torque controller in model (5) have been modified according to the changes documented in the OC3-Hywind report supplied with model (5).

I changed the parameters in MODULE BLadedDLLParameters() as specified in the Wind Turbine model, although I do not know anything inside the DLL controller. How could I open a DLL controller to see the logic and the parameters used inside? Using the suitable Compiler? How to know which programming language is used to create this controller?

Then I compiled the FAST.exe successfully. The DLL controller's name is like this "disconAB.dll". I also changed the DLL_FileName= 'disconAB.dll' and DLL_ProcName='disconAB' before compiling FAST. I ran the simulation and had a error message after AeroDyn was loaded.
"Aerodynamics loads calculated using AeroDyn(12.58, 28-Jun-2005)The DLL disconAB could not be loaded.Aborting FAST."Should I also change some other lines in BLadedDLLInterface.f90.

I tried also in another way. I renamed the DLL controller as DISCON.dll.
DLL_FileName='DISCON.dll' and DLL_ProcName='DISCON' were not changed. Compiling was successful. When I ran the simulation, I got another kind of error.
Aerodynamics loads calculated using AeroDyn(12.58, 28-Jun-2005)forrt1: severe (157): Program Exception - access violationImage PC Routine Line SourceDISCON.dll 10003CC0 Unknown Unknown Unknown

Stack trace terminated abnormally.

The DLL controller could be used in FAST, no matter which programming language is used to create this DLL controller. Is this right? I read the Bladed Manual Appendix B, the example DLL controllers could be created by using codes of C or Fortran computer language. Are the variables in the DLL controllers of GH-Bladed style always using the same variable names like avrSWAP, aviFAIL, accINFILE, avcOUTNAME, avcMSG? If so, a DLL controller used by GH-Bladed could be used in FAST directly without changing the variable names in BladedDLLInterface.f90 routine. Do I understand correctly? I do not know if some DLL controllers of GH-BLaded style use variable names other than avrSWAP, aviFAIL, accINFILE, avcOUTNAME, avcMSG?

You cannot reverse engineer the DLL controller to get the source code. Who did you get your DLL controller from? You will have to ask the developer of the DLL if you can have the source code. For the NREL 5-MW models, the source code for the DLL controller is provided (in Fortran) with each model.

DLL_FileName must be set to the file name of the DLL. This is typically 'DISON.dll'. DLL_ProcName must be set to the name of the procedure in the DLL that is being called. This is typically 'DISCON'.

I'm not sure what is producing the errors you've reported. Sorry.

The DLL can be written in a language other than Fortran (e.g., C). The Bladed manual describes the arguments to the DLL. The names of the arguments are not important. But the order of the arguments and their content is.

The DLL controller was given by the company and was written for GH-Bladed. It is not possible to have the source code. The controller was compiled in C programming language. Have you ever used the controller written for GH-Bladed into Fast successfully, like in my case? If my model was not correctly created,or has some mistakes that I do not know, could this cause the unsuccessful controller deployment? Or maybe the incompatibility of C compiled controller with FAST.

I tried to use the 5MW onshore controller with some parameter changes into my model. I got some warning and error like this:

Waring:Small angle assumption violated in SUBROUTINE SmllRotTrans() due to a large blade deflection. The solution may be inaccurate. Future warings suppressed. Simulation continuing...

With regards to the small angle assumption warning, FAST uses a linear modal summation to determine the tower and blade deflections. Consequently, there is a small angle approximation in the blade and tower deflection formulations. The accuracy of the deflections and loads will be diminished at the time the warning was generated and possibly thereafter if the problem persists. This warning is generally triggered by one of two problems:

1) Improper choice in time step. If the time step is chosen too large for a given system, the numerical solution may become unstable and the response may "blow up." This warning message generally, then, precedes a simulation crash. This problem can be eliminated by reducing the time step.

2) Very flexible blades. In this case, the numerical solution remains stable and the large deflections are "real" and are caused by high loading or a physical instability. FAST, however, cannot model very flexible systems accurately so you must question the validity of the results.

What I typically suggest is that if (2) is the problem, that you examine the time history of the blade tip deflection and check the magnitude of the deflection at the time the warning was generated. Whenever the deflection exceeds this value in the remainder of the simulation, you must be cautious in how you interpret the results. If the deflection persistently exceeds this value, you should probably not be using the FAST code; a general-purpose multibody code would be a better choice. It is also possible that the small angle approximation is only violated during the start-up transient (I've seen this when modeling the NREL 5-MW turbine, for example). This happens because the blades are suddenly loaded by the wind at time zero. In this case the warning should not be of concern because the start-up transient output should not be used in the post-processing of a loads analysis. This problem can also be eliminated by choosing initial blade displacements that are representative of your given wind speed (i.e., initialize the blade displacements to the values of the steady-state displacements for a given wind speed).

In your case the simulation crashes soon after the warning is generated. So, (1) may be the problem.

The error regarding FF_Interp is telling you that the blade element has passed outside of the turbulence grid in the Y (transverse) direction. This error is typically caused by the use of a grid that is too small for the given rotor or by excessive turbine deflections. What is the width of the grid compared to the rotor diameter? (It is not the number of grid points, but the height/width of the grid that are important to this error.) Perhaps the excessive turbine deflections identified by the small angle assumption warning are triggering the error?

I changed the time step and my model works with 5MW DLL controller and another GH-Bladed style controller of a smaller wind turbine. The error FFinterp was triggered by the small angle assumption, beause I also tested different height and width.

If the warning of small angle assumption comes out after 20 seconds simulation time, is small angle approximation violated only during the 20 seconds or it means small angle approximation is violated from 20 seconds till the simulation end. This case happens when the inproper time step is chosen.

I obtained the new copy of GH-Bladed style DLL controller( the same controller) of my wind turbine model.( The last copy does not work at all.) When I run the simulation, the executable encouters a message box like:

FAST.exe has encountered a problem and needs close. We are sorry for the inconvenience.

If you were in the middle of something, the information you were working on might be lost.

Please tell Microsoft about this problem.We have created an error report that you can send to us. We will treat this report as confidential and anonymous.

I searched in google for this information and it seems to be a message but not an error. Should I download these dll packages from the Microsoft and install them? Or maybe the controller itself causes this message report.

The small angle assumption violation does not trigger the FF_Interp error, but it often preceeds it when (1) is the problem. And since reducing the time step resolved one of your problems, it sounds like (1) was a problem.

The small angle assumption violation warning is only written to the screen by FAST once. So if you see the warning at 20 seconds, then the violation may or may not persist. What I suggest in this case is that you examine the time history of the blade tip deflection and check the magnitude of the deflection at 20 secnods. Whenever the deflection exceeds this value in the remainder of the simulation, you must be cautious in how you interpret the results. If the deflection persistently exceeds this value, you should probably not be using the FAST code; a general-purpose multibody code--which does not make use of small angle assumptions--would be a better choice. However, I've only known a few turbines that have had blades so flexible that the FAST small angle assumption is persistently violated.

I have never seen a message box pop up while running a FAST simulation. If you only get that when running with your new DLL, than I suspect it is the DLL.

I have run the NREL 5MW turbine with monopile rigid foundation model with a fixed pitch angle 50 deg. There was a small deflection violated warning but the results seem like reasonable. Then I have run a 13.2 MW offshore wind turbine model with a 50 deg pitch angle. There was also a small deflection violated warning but the results don't look good such that the in plane deflection of the blade is keeping at a large number (35 meters) up and down. I have tried used the suggestions you posted before such as reduce the time step (DT) in FAST, but the results still don't make sense until I try to increase the induction factor tolerance to 0.2 in AeroDyn (the results start to converge (6m also deflection) but still have a trend to diverge after 600 second simulation). So regarding my use of induction factor tolerance (AToler = 0.2), do you think what I was doing would generate a reliable result? In the case I set AToler = 0.2, I still use a DT = 0.0125 since I would expect a lower 1st natural frequency of the 13.2 MW turbine than the 5 MW.

The second question is regarding the solution of GDW and BEM. Would the parameter AToler = 0.2 only introduce some influence to the results of BEM but not to GDW?

I wouldn't recommend increasing AToler much above 0.005. AToler is the maximum difference allowed between two successive calculations for the axial induction factor (a). A large value of AToler will result in a large loss of solution accuracy.

AToler is only used by the iterative solution of the EQUILibrium wake (BEM) option of AeroDyn. The DYNIN (GDW) wake option is not iterative, and so, is not effected by the setting of AToler, except at initialization where GDW uses BEM to initialize the solution over the first few time steps.

I'm not sure where this FAST model of a 13.2-MW turbine originated or why you are running it at such a high (50 degree) pitch angle, but the problem you are running into may have more to do with the model specifications or operational conditions than the BEM algorithm.

I've had trouble using FAST with large rotors and I suspect it is because large turbines are generally really flexible--too flexible for the current version of FAST. Once we add BeamDyn to FAST, I think the higher-fidelity blade model will do a *much* better job of simulating very large turbines.

Have you looked at your blade tip deflections? Try setting the initial azimuth angle to 90 degrees and the rotor speed to zero to to see how much the blade droops with 0 or 90 degrees of pitch.