Dear all,
I have a wind turbine build up in Bladed 4.3 and this model works as wanted.
Now I would like to have the same in FAST 8.16 with AD15.
The controller is a bladed-style *.dll with a *.in file. Unfortunately the controller and its parameters are a black box to me.
All controller records in Servodyn are set to the same values as in Bladed.
With PCMode=5 and VSControl=5.
Values in Elastodyn and Aerodyn are replaced with equivalent values from the Bladed-model. The airfoils are also replaced. Their UA coefficients are calculated based on the approach taken in AirfoilPrep_v2.02 but without 3D correction because Bladed don’t correct cl, cd and cm with a 3d model.
Mode shapes are replaced as well but their influence should be small on the shown parameters.
Attached is a wind ramp from 3 to 22 m/s over 1000 sek. As one can see the graphs differ significant.
Can someone give a hint on what could be the reason?
I think that there is more than one problem:
(1) For higher wind speed (450-1000s) the FAST model should be able to produce more power with a smaller pitch angle → controller problem?
It seems like the above rated set point for GenTq is lower than in Bladed?
(2) For lower wind speeds (200-450s) the FAST model should produce more power → aerodynamic problem?
Best regards,
Simon
Dear Simon,
Clearly there is a problem, but I’m not sure what would cause these differences between FAST and Bladed. I suggest that you simplify the model to debug. E.g. do you get the same aerodynamic torque and thrust out of FAST and Bladed when you disable all structural DOFs, disable the controller, and prescribe a fixed rotor speed and blade-pitch angle for each mean hub-height wind speed?
Best regards,
Dear Jason,
thank you for your advice. With the same hub height wind speed, rpm and pitch angle I get more or less the same torque and power in Bladed and FAST so I guess aerodynamics is not the main problem.
So I think one can conclude, that the problem is related to the turbines control. Do you agree?
Any advice what to test next?
Best regards,
Simon
Dear Simon,
Yes, I agree that FAST does not seem to be interacting well with the controller. But it is still hard for me to understand why.
Do you get the behavior you expect with the controller and only minimal structural DOFs enabled e.g. with only the generator DOF enabled (GenDOF = True)?
Best regards,
Dear Jason,
even when I’m disabling all DOFs except the generator DOF I get almost the same wrong behavior as before.
I had a look at the controller to avoid problems.
It expects pitch position demand and not pitch rate demand, so this should be no problem.
Apart from that I’m not aware of things FAST is not capable when it comes to the latest Bladed Controller Dll Interface.
Any hint is appreciated.
Best regards,
Simon
Dear Simon,
I’m not sure what would cause this problem as I have not seen it before. You may need to debug by tracking the inputs and outputs to the controller to see what is different between Bladed and FAST.
Best regards,
Dear Jason,
as you mentioned I created a wrapper to output in- and outputs for the DLL in Bladed and FAST.
Now I’m comparing the avrSWAP-array that is input to the DLL. Some questions evolved:
-
What size is the avrSWAP-array? The more values I output in the wrapper the more values I get. Even with 1000 values extracted from the avrSWAP-array. Any idea why I get so many values?
-
In the Bladed-Dll-Input the below-rated torque-speed look-up table starts at a different record-no. Could that be a problem?
-
How is avrSWAP[15] and avrSWAP[23] (measured electrical power and measured generator torque) calculated? I would assume that these values are calculated based on e.g. the aerodynamic torque and the generator speed internally in FAST without direct influence from the DLL.
Best regards,
Simon
Update to 3: I think this problem is discussed here already: ServoDyn - Measured Electrical Power signal not being sent to Bladed-style DLL - #4 by Jason.Jonkman. To test this I need a 32-bit compiled version of Openfast. Can you help with that?
Dear Simon,
Here are my answers to your questions:
-
You can see how FAST fills the avrSWAP() array in routine BladedDLLInterface.f90/Fill_avrSWAP(). If you don’t have array bounds checking enabled, then you can access data outside that allocated for the array (taking adjacent elements of memory).
-
Yes, that sounds like a problem. Again, see how FAST fills the avrSWAP() array (question 1). Perhaps the version of Bladed you are using uses a slightly older or newer DLL controller interface?
3 (updated). I haven’t compiled OpenFAST in 32 bits myself, but OpenFAST includes several compile scripts that you can use to compile OpenFAST yourself (depending on your preferred compiler).
Best regards,
Dear Jason,
thank you for your response.
to 1. Where can I enable array bounds checking?
to 2. Im using Bladed 4.3.101. I will check that issue later.
to 3. I tried to compile OpenFAST as 32 bit version with MinGW32 with the skripts you provide. Unfortunately I got a error at the end of the compilation:
“f951.exe: out of memory allocation 65536 bytes
make[2]: *** [modules-local/fast-library/CMakeFile/opengast_postlib.dir/src/FAST_Subs.f90.obj] Error 1
make[1]: *** [modules-local/fast-library/CMakeFile/opengast_postlib.dir/all] Error 2”
Do you have a idea what is causing the error?
Is there a way to compile OpenFAST as 32 bit without using Visual Studio on Windows?
Best regards,
Simon
Dear Simon,
Array bounds checking is a compile-time option (/check:bounds in Visual Studio). We normally disable this in release mode to speed up the solution.
I use Visual Studio myself, and have no experience with the CMake build scripts. And I’m not sure the CMake experts at NREL regularly check this forum. I suggest that you post CMake-related OpenFAST compiling questions on the OpenFAST issues page on github: github.com/OpenFAST/openfast/issues.
Best regards,
Array bounds checking won’t necessarily help with the Bladed-style DLL. The arrays between FAST/Bladed and the controller DLL pass an address, so the compiler isn’t going to be able to provide bounds checking that way.
The aeroelastic code that calls the Bladed DLL indicates how long the array is allowed to be (record 25 gives the location of the torque-speed look-up table and other parameters indicate how long that array can be see documentation), so as long as record 25 is consistent with the location of the table, having that different in Bladed isn’t necessarily a problem.
I would make sure you have the latest code updates from OpenFAST (probably the dev branch?) because there was a bug that gave the controller incorrect ElecPwr and GenTrq. If you have that code and the torque-speed tables start at different places, then I’d also check that the controller isn’t using features that exist in Bladed but aren’t implemented in FAST.
Dear all,
my controller issue has been resolved with OpenFAST 1.0.0 with the 32bit version (github.com/OpenFAST/openfast/re … tag/v1.0.0).
Now the comparison of input (logged with a wrapper) to the controller is identical between Bladed 4.3 and OpenFAST 1.0.0.
Best regards,
Simon
