Facing Issue in compiling with VS2022

[KausikDalui]

When I am compiling in Visual Studio 2022 (in Windows 11) I am getting error as per attachment. I have not made any changes to source code. I have downloaded the files through a git clone as per https://openfast.readthedocs.io/en/main/source/install/index.html#get-the-code, section 3.2.2. I have given the snap of the solution explorer and FAST Property Page. Kindly help me resolve the issue.

I would like to mention here that I first tried to compile in 'Building OpenFAST on Windows with CMake and Cygwin 64-bit' option. It was working fine until I didn't change anything in the source code. But when I replace the 'SubDyn.f90' file with the file provided by Bentley SACS for their integration with OpenFAST, I was getting error. this process required to link a static library file as additional dependency which I was not able to do in CMake environment. It would be appreciated, if anybody can reflect this issue as well. Thanks & Regards.
snap from VS2022.pdf

[KausikDalui]

I would like to give an update. the above issue has been resolved by adding system variable for git. But after correcting I am getting two error while linking as below:

FAST_Prog.f90
ifort: remark #10448: Intel(R) Fortran Compiler Classic (ifort) is now deprecated and will be discontinued late 2024. Intel recommends that customers transition now to using the LLVM-based Intel(R) Fortran Compiler (ifx) for continued Windows* and Linux* support, new language support, new language features, and optimizations. Use '/Qdiag-disable:10448' to disable this message.
Linking...
FASTlib_x64_Debug.lib(mapapi.obj) : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification
libucrt.lib(frexp.obj) : error LNK2005: frexp already defined in libmmt.lib(frexp_iface_c99.obj)
LINK : warning LNK4098: defaultlib 'LIBCMTD' conflicts with use of other libs; use /NODEFAULTLIB:library
....\build\bin\openfast_x64_Debug.exe : fatal error LNK1169: one or more multiply defined symbols found

[KausikDalui]

I would like to provide an update on the error mentioned above. When I use the /FORCE:MULTIPLE option under Linker-Command Line in [FAST (IFORT)], the executable is generated without errors.
@ebranlard
Now I am seeking advice on the following:

I am using SACS software (by Bentley) to simulate the substructure jacket and tower in SACS, along with the wind turbine and its loading from OpenFAST. Bentley provides a dedicated SACS_FAST interface module for this analysis. This module requires replacing the Subdyn.f90 file with their version. The Subdyn.f90 module provided by SACS is as follows:

Module SubDyn

USE SubDyn_Types
USE SubDyn_Output
USE SD_FEM
!DEC$ ATTRIBUTES DLLIMPORT :: SD_Init
!DEC$ ATTRIBUTES DLLIMPORT :: SD_CalcOutput
!DEC$ ATTRIBUTES DLLIMPORT :: SD_UpdateStates
!DEC$ ATTRIBUTES DLLIMPORT :: SD_End

IMPLICIT NONE

PRIVATE

!............................
! NOTE: for debugging, add preprocessor definition SD_SUMMARY_DEBUG
! this will add additional matrices to the SubDyn summary file.
!............................

TYPE(ProgDesc), PARAMETER :: SD_ProgDesc = ProgDesc( 'SubDyn', 'v1.03.00', '11-Apr-2016' )

CONTAINS

The above code is the exact SubDyn module provided by Bentley. When using this module, I encountered an Explicit Interface Error in FAST_Lin.f90. It appears that the subroutines SD_GetOP, SD_JacobianPContState, and SD_JacobianPInput are being called in FAST_Lin.f90. Therefore, I added these subroutines from the original Subdyn.f90 to the Bentley-provided module.

Additionally, the module requires a static library file to be linked as an additional dependency to the FAST project. I have added the static library file in FASTlib (IFORT) as follows:

With this setup, I can successfully compile FASTlib (IFORT). However, when attempting to compile FAST (IFORT), I encounter the following errors. The output log from the FAST (IFORT) compilation is provided below:

Build started at 16:05...
1>------ Build started: Project: FAST (IFORT), Configuration: Debug x64 ------
Linking...
FASTlib_x64_Debug.lib(mapapi.obj) : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification
libucrtd.lib(frexp.obj) : warning LNK4006: frexp already defined in libmmt.lib(frexp_iface_c99.obj); second definition ignored
FASTlib_x64_Debug.lib(FAST_Subs.obj) : error LNK2019: unresolved external symbol SD_INIT referenced in function FAST_SUBS_mp_FAST_INITIALIZEALL
FASTlib_x64_Debug.lib(FAST_Subs.obj) : error LNK2019: unresolved external symbol SD_END referenced in function FAST_SUBS_mp_FAST_ENDMODS
FASTlib_x64_Debug.lib(FAST_Solver.obj) : error LNK2019: unresolved external symbol SD_CALCOUTPUT referenced in function FAST_SOLVER_mp_FULLOPT1_INPUTOUTPUTSOLVE
FASTlib_x64_Debug.lib(FAST_Solver.obj) : error LNK2019: unresolved external symbol SD_UPDATESTATES referenced in function FAST_SOLVER_mp_FAST_ADVANCESTATES
FASTlib_x64_Debug.lib(SubDyn.obj) : error LNK2019: unresolved external symbol SD_CALCCONTSTATEDERIV referenced in function SUBDYN_mp_SD_GETOP
FASTlib_x64_Debug.lib(SubDyn.obj) : error LNK2019: unresolved external symbol __imp_SD_CALCOUTPUT referenced in function SUBDYN_mp_SD_JACOBIANPINPUT
....\build\bin\openfast_x64_Debug.exe : fatal error LNK1120: 6 unresolved externals

Build log written to "file://D:/OpenFAST_Final/vs-build/FAST/x64/Debug/BuildLog.htm"
FAST - 7 error(s), 2 warning(s)
========== Build: 0 succeeded, 1 failed, 3 up-to-date, 0 skipped ==========
========== Build completed at 16:05 and took 00.846 seconds ==========

Could you please provide a solution for this issue?

[bjonkman]

I would not recommend using the /FORCE:MULTIPLE linking option. Instead, I would attempt to figure out what is causing the linking errors. Likely, the SACS library you are attempting to link with the executable has different libraries and/or build options than the configuration you are attempting to build.

Since you are building with a debug configuration of FAST, I would guess that there is a conflict with the Debug Multithreaded libraries it normally builds with:

Could you try building the Release configuration with your static library instead?

[KausikDalui]

@bjonkman Thanks for your response. As per my understanding, /FORCE:MULTIPLE command Used has nothing to do with the external library that I am trying to link with. Actually, before replacing the Subdyn module and linking the external static library, I tried to compile the OpenFAST as it is. So, without changing anything I tried to compile it and I got LNK2005 error. Though it was in debug mode; I have changed it to Release mode and I got the same error (without using /FORCE:MULTIPLE COMMAND). Here I have attached the build log for your reference. Awaiting your feedback.
Build_Log_Release_Mode.txt

[bjonkman]

I agree that /FORCE:MULTIPLE is not related to your external library. I just don't think it is good practice to use that command since it could likely result in a problem when running the executable.

I would start with the unchanged OpenFAST code (original SubDyn and no linking to an additional external library). Then make sure you are starting from a fresh build (either do a "Rebuild Solution" or "Clean Solution" and then "Build"):

It looks like you are building the Fortran projects with Intel® Fortran Compiler Classic 2021.12.0 [Intel(R) 64]. What version of the C compiler is the MAP++ dll using? This is the Platform Toolset in the project properties box:

[KausikDalui]

Dear @bjonkman, thanks for response. As you suggested, I started with unchanged OpenFAST code and clean and build the solution. I got the same LNK2005 error.
I am using IFORT Intel Fortarn Compiler Classic and regarding C++ compiler version, I can see that it is v143. kindly refer the below snaps from my visual studio FAST project:

Awaiting your feedback.

[bjonkman]

Some things to try:

1. Do you get the linking error with both Debug and Release configurations? Or just Debug? I have had issues with certain versions of the 2019 Math Kernel Library's static debug libraries, but I have not tried the 2021 version you seem to be using.
2. Can you build this using a different Platform Toolset in MAP? I don't know what C compilers you have available in Visual Studio, but you could try a different one and see if there is still a conflict.

Just FYI: I am using the 2024.1 version of the IFORT compiler with VS 2022 without issue. I installed the oneAPI base toolkit, HPC toolkit and 32-bit base toolkit.

[KausikDalui]

Dear @bjonkman, downgrading Intel oneAPI Base Toolkit to 2024.1, I am able to compile it successfully. Thank you for your valuable support in resolving the issue.

I would appreciate your continued assistance on the issue which I explained in my third comment of this thread. to summarize the issue, I need to replace SubDyn.f90 and link a static library as an additional dependency to my FAST project in Visual Studio.

[bjonkman]

Since I don't really know what SubDyn changes you are implementing, I don't know how much help I will be. If you are still having issues with the build, I would recommend:

1. Verify that the version of SubDyn they are replacing is from the same version of OpenFAST, or contact them for help in updating their version of SubDyn. If they are missing the SubDyn routines for linearization, it may be much more difficult than just copying the new routines to your version of SubDyn.
2. Make sure that the static library you are linking with OpenFAST was created with compatible build options. There might be linking conflicts if it uses different runtime libraries than OpenFAST is using.

[KausikDalui]

@bjonkman , thank you for your input. I'm working on gathering the requested information from Bentley.

In the meantime, I've attempted to use FASTv8 with the SubDyn file provided by Bentley. In this case, I have not made any modification to the SubDyn module provided by Bentley. Unfortunately, I'm encountering linking errors. My solution explorer looks like below:

To provide more context, I've attached screenshots of my FAST project configuration, compilation output, and the SubDyn module. I've added the necessary directories for *mod files and the static library to the linker input.


Build_Log_ReleaseX64_FASTv8.txt
SubDyn_SACS.txt

I'm hoping you can provide guidance on the potential causes of the linking error and possible solutions. Please note that my programming experience is limited, and I have a civil engineering background.

Thank you for your assistance
P.S. I have tried in Release Mode too and similar error I was getting.

[bjonkman]

I would first deal with this line from the build log: C:\Program Files (x86)\Bentley\Engineering\SACS 12 CONNECT Edition\SACS_FAST_Mod_DLL.lib : warning LNK4272: library machine type 'x86' conflicts with target machine type 'x64'

You can't mix libraries for 32-bit and 64-bit architectures, so you will have to build your OpenFAST (or FAST8) configuration with Platform set to Win32 (or x86 if that's not an option)

The second issue refers to unresolved symbols:

FAST_Solver.obj : error LNK2019: unresolved external symbol SD_CALCOUTPUT referenced in function FAST_SOLVER_mp_ED_SD_HD_BD_ORCA_INPUTOUTPUTSOLVE
FAST_Solver.obj : error LNK2019: unresolved external symbol SD_UPDATESTATES referenced in function FAST_SOLVER_mp_FAST_ADVANCESTATES
FAST_Subs.obj : error LNK2019: unresolved external symbol SD_INIT referenced in function FAST_SUBS_mp_FAST_INITIALIZEALL
FAST_Subs.obj : error LNK2019: unresolved external symbol SD_END referenced in function FAST_SUBS_mp_FAST_ENDMODS

The PRIVATE statement in your SubDyn module tells the compiler/linker that the subroutines aren't by default defined outside of the SubDyn module. This allows modules to have routines that potentially have the same names as routines in other modules without causing issues. In OpenFAST, there are PUBLIC statements for specific routines to allow the OpenFAST glue code to call them. You can try to add public statements for the routines that it needs, or you could remove the PRIVATE statement in SubDyn.