Hi:
I am a new FAST user, and I tested the 1.5MW turbsine. I used PitchCntrl() and Pitch.ipt to do the pitch control, everything is good.
Then I download the 5MW files, and I also want to do the controls on this kind of turbine, but I found that there donot have control files that can be directly used by FAST.
In 5MW turbine, you use the DLL to do the controls, but I never use DLL before, could you give me some advices?
Thanks.
Hi Kuangmin,
All of the NREL 5-MW Baseline wind turbine FAST models ([url]National Wind Technology Center's Information Portal | Wind Research | NREL) 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: [url]National Wind Technology Center's Information Portal | Wind Research | NREL.
I hope that helps,
that does work.
Thanks for your patience.
Hi,
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 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.
Thanks in advance!
Best regards!
Hi Kuangmin,
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: 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 hope that helps.
Best regards,
Thanks a lot! Your advice helps really. I still have some questions.
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.
[color=blue]“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.
[color=blue]Aerodynamics loads calculated using AeroDyn(12.58, 28-Jun-2005)
forrt1: severe (157): Program Exception - access violation
Image PC Routine Line Source
DISCON.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?
Thanks again.
Best regards
Yinping
Hi Yinping Yang,
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.
Best regards,
Hi,
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:
[color=blue]Waring:
Small angle assumption violated in SUBROUTINE SmllRotTrans() due to a large blade deflection. The solution may be inaccurate.
Future warings suppressed. Simulation continuing…
Timestep: 1 of 630 seconds. Estimtated final completion at 16:51:11
FATAL ERROR in Subroutine FF_Interp.
FF wind array boundaries violated. Grid too small in Y direction.
IYLO=0
NYGrids=29
I tried grids from 1313 till 2929. This error still exists. I suspect the conroller could not be directly used in my model, or the aerodynamic properties of my model have problems.
Thanks in advance!
Yinping
Hi Yinping Yang,
I have used GH-Bladed DLLs successfuly with FAST before.
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:
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.
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?
Best regards,
Hi,
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.
To see what data this error report contains, click here.
Debug Send Error Report Don’t Send
I clicked the Debug button and the Debug informatin of the CVF compiler is like this:
Loaded ‘D:\FAST\Test\FAST.exe’, no matching symbolic information found.
Loaded ‘C:\WINDOWS\system32\ntdll.dll’, no matching symbolic information found.
Loaded ‘C:\WINDOWS\system32\kernel32.dll’, no matching symbolic information found.
Loaded ‘D:\Nordex\NxTest\discon.dll’, no matching symbolic information found.
Loaded ‘C:\WINDOWS\system32\version.dll’, no matching symbolic information found.
Loaded ‘C:\WINDOWS\system32\msvcrt.dll’, no matching symbolic information found.
Loaded ‘C:\WINDOWS\system32\advapi32.dll’, no matching symbolic information found.
Loaded ‘C:\WINDOWS\system32\rpcrt4.dll’, no matching symbolic information found.
Loaded ‘C:\WINDOWS\system32\user32.dll’, no matching symbolic information found.
Loaded ‘C:\WINDOWS\system32\gdi32.dll’, no matching symbolic information found.
Loaded ‘C:\WINDOWS\system32\winsta.dll’, no matching symbolic information found.
Loaded ‘C:\WINDOWS\system32\netapi32.dll’, no matching symbolic information found.
Loaded ‘C:\WINDOWS\system32\shlwapi.dll’, no matching symbolic information found.
Loaded ‘C:\WINDOWS\system32\imm32.dll’, no matching symbolic information found.
Loaded ‘C:\WINDOWS\system32\lpk.dll’, no matching symbolic information found.
Loaded ‘C:\WINDOWS\system32\usp10.dll’, no matching symbolic information found.
Loaded ‘C:\WINDOWS\system32\guard32.dll’, no matching symbolic information found.
Loaded ‘C:\WINDOWS\system32\ole32.dll’, no matching symbolic information found.
Loaded ‘C:\WINDOWS\system32\fltlib.dll’, no matching symbolic information found.
Loaded ‘C:\WINDOWS\system32\cssdll32.dll’, no matching symbolic information found.
Loaded ‘C:\WINDOWS\system32\shell32.dll’, no matching symbolic information found.
Loaded ‘C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2180_x-ww_a84f1ff9\comctl32.dll’, no matching symbolic information found.
Loaded ‘C:\WINDOWS\system32\comctl32.dll’, no matching symbolic information found.
Loaded ‘C:\WINDOWS\system32\apphelp.dll’, no matching symbolic information found.
The thread 0xBF4 has exited with code 0 (0x0).
The thread 0x520 has exited with code -1073740777 (0xC0000417).
The program ‘D:\FAST\Test\FAST.exe’ has exited with code -1073740777 (0xC0000417).
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.
Thanks very much
Best Regards
Yinping
Hi Yinping Yang,
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.
Best regards,
Dear Jason,
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?
Really appreciate!
Best regards,
Dear Lingling,
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.
Best regards,
Dear LingLing,
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.
It’s just a hunch. Jason knows far more about this stuff than I do.
Marshall
Dear Jason,
Really appreciate.
I am running the 13.2 MW rotor developed by SNL. I was thinking this is due to the flexibility of this long blade as you posted before.
Best regards,
Dear Marshall,
Really appreciate!
Did you also have troubles when running with SNL 13.2 MW rotor? I have tried the initial azimuth as 60 and 90 but the blade deflections are still as high as 50 meters. Do you have some other suggestions?
When will the FAST with BeamDyn be published? Looking forward to the new version.
Best regards,
Dear Lingling,
While I haven’t run the SNL 13.2-MW model myself, I have not heard others complain of similar problems. My guess is the problem is with your operational condition – running a simulation involving the turbine operating with a fixed pich of 50 degrees. Why do you want to simulate at this condition? Do you have similar problems when running simulations at more normal conditions?
Best regards,
Dear Jason,
Really appreciate!
No problem at all in other normal conditions! I just want to take a look of the pitch sensitivity of this rotor. I may skip this angle for time being!
Best regards,
Hi:
I am a new FAST user, and I tested the CART3 1.5MW turbine.But when i tried to run it in command prompt it shows like the following image.
Dear Mani,
Your image does not show up.
Also, I’m not aware of a CART3 1.5-MW turbine. Do you mean the CART3 600-kW turbine, the WindPACT 1.5-MW turbine, or something else?
Best regards,