Issues compiling AeroDyn Driver for #688 & OpenFAST\dev branch

[mayankchetan]

Bug description

I initially tried compiling the AeroDyn Driver using #688, but the AeroDyn_Driver_Types.f90 file does not generate correctly while compiling AeroDyn Driver via the visual studio solution. Next, I tried compiling the AeroDyn Driver using the dev branch and had issues with the Registry.lib file.

To Reproduce

Steps to reproduce the behavior for #688:

1. Clone https://github.com/ebranlard/openfast/tree/f/driver .
2. Compile AeroDyn Driver using AeroDyn_Driver.sln.
3. Run generated AeroDyn_Double_Driver.exe, but no outputs/does not run.
4. Clear solution and re-compile.
5. Error while generating AeroDyn_Driver_Types.f90.

Steps to reproduce the behavior for OpenFAST\dev branch:

1. Clone dev branch
2. Compile AeroDyn Driver using AeroDyn_Driver.sln
3. Error while generating Aerodyn Driver

Expected behavior

• No errors while generating AeroDyn_Driver_Types.f90 for AeroDyn driver update for multiple wind turbines, with arbitrary motions and geometries #688.
• No errors while generating AeroDyn Driver for dev branch.

Screenshots, if applicable

.txt appears where it's not expected

AeroDyn_Driver_Types.f90 doesn't complete generating via FAST registry

OpenFAST Version

• https://github.com/ebranlard/openfast/tree/f/driver
• dev

System Information (please complete the following information):

• OS: Windows 10 [20H2]
• Compiler: Intel OneAPI Fortran Compiler + Visual Studio 2019
• Compiler settings: Release x64, Release Double x64

Additional context

• Able to compile OpenFAST for both https://github.com/ebranlard/openfast/tree/f/driver branch & OpenFAST/dev branch with the current setup.

Note: Please let me know if I should split this into two issues, one for #688 and one for the dev branch.

[ebranlard]

Hi @mayankchetan

Thanks for your report, I had not caught this error which indeed occurs when you clean the solution. The RunRegistry.bat needed to include InflowWind as an include path for Aerodyn. I hope my latest commit fixes the issue.

As for your issue compiling dev I cannot reproduce it, but I have a different setup than you unfortunately (earlier Fortran and Visual studio). Are you able to compile the dev openfast.exe? There has been are a couple of open issues related to compiling openfast with visual studio lately. I wonder if some of them might help: #322 #714 #697 #649

If you think it's an aerodyn_driver issue, we can try to dive more into it, otherwise it might make sense to create a separate issue.

Thanks

[mayankchetan]

Hi @ebranlard,

Thank you for the update, I tried out your latest commit and it was able to resolve the AeroDyn_Driver_Types.f90 issue.

Sadly, it falls back to the dev branch issue for the AeroDyn driver that I have pointed above.

Yes, I am able to compile OpenFAST.exe for both the dev branch and f/driver branch (corresponding to #688).

Please let me know if there is any information that I can provide.

Thank you!

[ebranlard]

Ok, thank you for trying it out. So somehow the linker wants to add "Registry.lib" to the exe, but actually the registry is not to be linked with our exe. I don't know what's different between the aerodyn_driver project and the openfast project that triggers this on your setup.

@bjonkman do you have any feedback on this issue?

[ebranlard]

@mayankchetan are you able to compile the InflowWind, and UnsteadyAero drivers?

[bjonkman]

@ebranlard , there was another issue like this regarding OpenFAST a while back. It seems like newer versions of Visual Studio try to link a Registry library when the main project depends on the Registry executable (set in the project dependencies) and "link library dependencies" is enabled. In the OpenFAST solution file, I removed the dependency of the Registry from the main executable and that solved the issue. In this case, the solution file is set up a little differently so we might have to change the link dependencies. I would try changing "Link Library Dependencies" to "No" in the AeroDyn driver properties window and see if that fixes the issue.

[mayankchetan]

Thank you for the inputs @ebranlard @bjonkman, changing "Link Library Dependencies" to "No" helps with compiling the AeroDyn driver.

But looks like the compiled AeroDyn_Driver_x64_Double.exe is not responding to begin called or when I pass it the AeroDyn driver input file.

[ebranlard]

Thanks Bonnie, so we are making progress. I'll likely submit a pull request to fix the "Link Library Dependencies" issue.

The only time I've seen an exe that didn't reply, was for FastFarm compiled with OpenMP, and it depended on how I chose the runtime library option.

Can you try desactivating OpenMP and seeing if that works for you
Configuration Properties->Fortran->Language -> Process OpenMP directives: Disable

If you find that OpenMP is the issue, can you try activating it, but experimenting with different options for the Runtime library:
Configuration Properties->Fortran->Libraries -> Runtime Library
I think Bonnie recommends Multithread DLL, but I recall that in the past I had to used Multithreaded on my machine...

Let us know if that helps.

[mayankchetan]

Hi @ebranlard,

Looks like the "Link Library Dependencies" issue exists for other independent module drivers as well.

I've been trying the options you mentioned and along with other compiler settings like precision, but haven't had an AeroDyn Driver program run successfully. I was able to get a working BeamDyn Driver so I think that would eliminate the setup I have (compared the settings in the configuration properties, they were identical).

Since you mentioned fastfarm and OpenMP, I've seen that issue too when I tried compiling the OMP version. The single-threaded program runs fine.

do you have any other recommendations?

Thank you.