Dear NREL team,
I noticed that for the latest openFAST release (2.2.0) there are presently no pre-compiled binaries available on GitHub, as was the case for previous releases. Is there any reason for this?
I would like to use the latest release, as there are some bugfixes which are helpful, but I never succeeded in compiling the source code successfully using the available software in my (corporate) environment. So it would be much appreciated if the binaries can be made available on GitHub.
Best regards,
Ebert Vlasveld
Hello - I’ve had trouble compiling the binaries in a consistent manner for Windows. Specifically, statically linking the Intel libraries into the OpenFAST binaries presents some problems and the alternative is to require user to also install the Intel libraries on their computer.
All that to say that I’m working on it. I’ll likely upload the binaries as they are very soon, and then continue to try to bundle everything in a better way going forward.
Hi Rafael,
Thanks for your prompt reply.
I understand the problem, but was this also not the case for previous releases (I had to install those Intel libraries also to get 2.1.0 working)? Speaking entirely for myself of course, but first having to installing the intel libraries is for me only a minor issue.
Anyway, I will be patient and wait for the final uploaded bundle 
Thanks & best regards,
Ebert
The v2.2.0 binaries are now available on the GitHub Releases page
Hi Rafael,
I am trying to run openFAST 2.2.0 (32bit) but are running into trouble due to my controller library being compiled in 32bit. Apparently, v2.2.0 expects the controller DISCON.dll to be compiled in 64 bit?
The exact same simulation is running fine in V2.1.0.
Is there something to be done from my side in order to let openFAST work with my 32b DISCON.dll? I tried installing both the latest fortran redistributable libraries as well as the ones you linked to in the GitHub page.
Best regards
Dear Ebert,
Are you running the Windows 32-bit executable (rather than the 64-bit executable)? You can’t mix addressing schemes. The 32-bit executable requires 32-bit DLLs; likewise, a 64-bit executable require 64-bit DLLs.
Best regards,
Thanks for the response Jason.
I am not using the 64bit executable together with a 32bit controller library; I use the 32bit executable. However, openFAST throws an error message (in attachment) suggesting that my controller is compiled in 64bit (which it is not).
If I run exactly the same simulation, only calling the V2.1.0 (32bit) executable instead, it runs without problems. I have to add that this concerns a user-defined controller library, so I will have to try this with the baseline controller as well.
Best regards
Dear Ebert,
Actually, the error implies that you are running OpenFAST compiled in 64 bits, so, it wants the DLL to be in 64 bits. It sounds like your DLL is 32 bits, so, that could be the problem. Run the 32-bit executable of OpenFAST instead.
Best regards,
Hi NREL Team, hi Ebert,
I just downloaded the openFAST v2.2.0 binaries from GitHub. After some troubles to get it running, I recognized that openfast_Win32.exe is actually a 64-bit version. This might also be the reason for Ebert’s problems.
Since I also have a 32-bit Controller-DLL, I would appreciate it, if someone could provide a 32-bit compiled version of openFAST v2.2.0.
Best Regards,
Marvin
Hi Marvin,
This issue has now been opened on the OpenFAST issues page–you can track the progress here: github.com/OpenFAST/openfast/issues/389.
Best regards,
Thanks for bringing this to my attention. I’ll recompile and upload the 32 bit binaries ASAP.
Ok the new binaries are available on the latest OpenFAST release page, including the real 32 bit binary.
Hi Rafael,
Thanks for the quick fix. Always nice to have a supportive community like this.
Best Regards,
Marvin
Thanks Marvin and Rafael, this indeed fixed the problem.
Regards
Dear NREL team,
I have previosly run a case using v2.2.0 binaries (openfast_x64.exe in a windows computer).
The case is IEA 3.4 MW turbine, steady 7.5 m/s wind, using “DISCON_IEA_landbased.dll” for turbine contol.
Now I repeat the same case with OpenFAST v3.1.0 (in linux, where I compiled the code) and use the same parameters in all input files. Now, RtAeroPwr turns out to be 2.5 % lower with the new version, compared to the v2.2.0.
Is such a difference in turbine power normal considering the changes in the code ?
I’m new to OpenFAST and it’s hard to judge for me.
The only difference from my side is regarding the compilation of "DISCON_IEA_landbased.dll".
In case of v2.2.0, I was using the pre-compiled .dll from github (IEAWindTask37/IEA-3.4-130-RWT). In the case, of v3.1.0, I compiled the DISCON_IEA_landbased.F90 But I used the CMakeLists.txt of the DISCON.dll from 5 MW test case, assuming it doesn’t matter (and could not find the same for 3.4 MW).
Dear @Salur.Basbug,
Certainly new functionality has been added to AeroDyn and AeroDyn has been made more robust between OpenFAST v2.2 and v3.1–see the release notes associated with each release here: https://github.com/OpenFAST/openfast/releases--but I can’t think of a specific AeroDyn change that would cause the power to drop by 2.5% between versions.
To ensure that the controller is not playing a role, you could always disable the controller–e.g., by disabling the generator DOF in ElastoDyn (GenDOF = False)–and rerunning the OpenFAST v2.2 and v3.1 simulations and see how the results compare in that case.
To isolate a specific change to AeroDyn, I would suggest stepping through the various releases (from v2.2 to v2.3, from v2.3 to v2.4, etc.) to see if you can identify a specific release that is resulting in the change.
Best regards,
Thanks a lot for the tips Jason. The option to use GenDOF = False will be useful for me also in the future.
Even with GenDOF = False, the power difference between the versions 3.1 & 2.2 remains. Moreover, I compiled the version 2.2 in linux (as I did 3.1) , and run them with the same DISCON.dll. This test also resulted in different rotor power, by 2.5 %. I will check the version differences from the link you gave.
Best regards
