How to compile OpenFAST into a dynamic library about openfast HOT 25 CLOSED

I don’t think the developer tools update automatically when you update the OS. Try opening Xcode and see if you’re prompted to install stuff.

from openfast.

Do you want to use OpenFAST dynamic library with Simulink, or do you want to access FAST routines via the C++ interface in C/C++ codes (like SOWFA)? If it is the former, we currently have an open issue #59 where @bjonkman has listed several shortcomings of our current build configuration that we are working to address.

To access OpenFAST routines via the C++ API, you will also need additional libraries (MPI, HDF5, and YAML C++). This script, in the OpenFAST repository, shows an example of how you can invoke CMake configuration command by providing paths to these optional libraries that might have been installed in non-standard locations.

from openfast.

@sayerhs Thank you. Actually I want to use OpenFAST with Python by compiling all the modules in the modules-ext folder and modules-local folder into a dynamic library. I did this with FAST v7 and v8 in the past.

Since I can obtain a single program openfast.exe, maybe I don't need these additional libraries?

from openfast.

Ah. You can use the CMake -DBUILD_SHARED_LIBS option to tell CMake that you want shared libraries instead of static libraries. This is set to OFF by default in the OpenFAST CMake files. See Installation Docs for more info on this and the CMAKE_INSTALL_PREFIX options.

cmake -DBUILD_SHARED_LIBS=ON -DCMAKE_INSTALL_PREFIX=<install_loc> <path_to_src> 
make # Compile source code
make install 

After these steps you should see all the compiled module libraries in <install_loc>/lib.

from openfast.

Are you using SWIG or f2py to access OpenFAST subroutines from Python? If so, then you'll need the dynamic libraries and not the openfast.exe.

You can interact with openfast.exe via python subprocess and process the output files, this approach does not require shared libraries. openfast.exe will function fine with statically linked libraries.

from openfast.

@sayerhs Yes, I use f90wrap (builds on f2py) to access OpenFAST.

I obtained the dynamic libraries on Linux with the BUILD_SHARED_LIBS option. However, the compilation was failed on Windows cygwin:

[ 34%] Linking Fortran shared library cygaerodyn14lib.dll
CMakeFiles/aerodyn14lib.dir/src/DWM.f90.o:DWM.f90:(.text+0x93c): undefined reference to `__inflowwind_MOD_inflowwind_end'

from openfast.

Can you try your Cygwin build with dev branch please? I suspect this is fixed by the changes @rafaelmudafort introduced in pull request #57. If the issue still persists, please let us know.

from openfast.

@sayerhs Build with dev branch on cygwin successed, thank you!

Some small defects,

1. After make install, some dlls are copied into the bin folder, while the other dlls are copied into the lib folder. Whether all the dlls should be put into a same folder?
2. The cygnwtclibs.dll are not copied neither into the lib folder nor into the bin folder.

from openfast.

Thanks for the feedback. The expected behavior is, as you mention, that all dlls end up in the lib folder and not in bin folder; and cygnwtclibs.dll should be copied over along with other libraries. We will update the CMake build setup to address these issues on Windows/Cygwin platform.

from openfast.

@sayerhs Do you have any plans to support compiling openfast with mingw on Windows?

I used to compile FAST v8 with mingw, and f2py can use mingw to compile python extension module. I don't know whether f2py support cygwin well or not, and if not what should I do to compile openfast with mingw?

from openfast.

@yagweb We haven't tested it with MinGW. Are you finding issues when you attempt to compile using MinGW?

from openfast.

@sayerhs I succeed in generating the MinGW makefiles with the cmd command below,

cmake ^
   -DCMAKE_INSTALL_PREFIX=%openfast_dir%bin/ ^
   -G "MinGW Makefiles" ^
   -DBLAS_LIBRARIES=<full_path_of_libblas.dll> ^
   -DLAPACK_LIBRARIES=<full_path_of_liblapack.dll> ^
   -DCMAKE_BUILD_TYPE=RELEASE ^
   -DFPE_TRAP_ENABLED=OFF ^
../

The libblas.dll and liblapack.dll was build from the source code here.

However, the make process failed at,

[ 28%] Linking Fortran executable aerodyn.exe
../nwtc-library/libnwtclibs.a(NWTC_LAPACK.f90.obj):NWTC_LAPACK.f90:(.text+0x8d88): undefined reference to `sgemm_'
../nwtc-library/libnwtclibs.a(NWTC_LAPACK.f90.obj):NWTC_LAPACK.f90:(.text+0x9638): undefined reference to `dgemm_'
collect2.exe: error: ld returned 1 exit status

It seems it didn't find the BLAS_LIBRARIES, what should I do?

from openfast.

@yagweb Can you please turn on VERBOSE mode and share the linker command line that is being executed?

make VERBOSE=1 aerodyn should do the trick I think.

from openfast.

@sayerhs Here is the output of make VERBOSE=1 aerodyn

[ 89%] Linking Fortran executable aerodyn.exe
cd /d F:\cyPHM\openfast\build-mingw\modules-local\aerodyn && "C:\Program Files\CMake\bin\cmake.exe" -E cmake_link_script CMakeFiles\aerodyn.dir\link.txt --verbose=1
"C:\Program Files\CMake\bin\cmake.exe" -E remove -f CMakeFiles\aerodyn.dir/objects.a
C:\PROGRA~1\MINGW-~1\X86_64~1.0-P\mingw64\bin\ar.exe cr CMakeFiles\aerodyn.dir/objects.a @CMakeFiles\aerodyn.dir\objects1.rsp
C:\PROGRA~1\MINGW-~1\X86_64~1.0-P\mingw64\bin\gfortran.exe  -cpp  -ffree-line-length-none -fdefault-real-8 -O3 -DNDEBUG -O3   -Wl,--whole-archive CMakeFiles\aerodyn.dir/objects.a -Wl,--no-whole-archive  -o aerodyn.exe -Wl,--out-implib,libaerodyn.dll.a -Wl,--major-image-version,0,--minor-image-version,0 @CMakeFiles\aerodyn.dir\linklibs.rsp
../nwtc-library/libnwtclibs.a(NWTC_LAPACK.f90.obj):NWTC_LAPACK.f90:(.text+0x8d88): undefined reference to `sgemm_'
../nwtc-library/libnwtclibs.a(NWTC_LAPACK.f90.obj):NWTC_LAPACK.f90:(.text+0x9638): undefined reference to `dgemm_'
collect2.exe: error: ld returned 1 exit status

There is no blas and lapack libraries in the gfortran link command which caused this error.

I add the blas and lapack libraries to the link command manually, then the aerodyn.exe is generated.

cd /d ..\modules-local\aerodyn

C:\PROGRA~1\MINGW-~1\X86_64~1.0-P\mingw64\bin\gfortran.exe  -cpp  
-ffree-line-length-none -fdefault-real-8 -O3 -DNDEBUG -O3  
-Wl,--whole-archive CMakeFiles\aerodyn.dir/objects.a -Wl,--no-whole-archive  
-o aerodyn.exe -Wl,--out-implib,libaerodyn.dll.a 
-Wl,--major-image-version,0,--minor-image-version,0 
@CMakeFiles\aerodyn.dir\linklibs.rsp 
-llibblas -lliblapack -L<folder_of_the_libblas>

I think i used the BLAS_LIBRARIES and LAPACK_LIBRARIES in a wrong way.

from openfast.

@yagweb The only suggestion I can think of is providing BLAS_LIBRARIES and LAPACK_LIBRARIES within quotes and seeing if that fixes your issue.

from openfast.

@sayerhs The quotes are not working. But I found a workaround shown as below,

BLAS_LIBRARIES:FILEPATH="-lblas -L<folder_of_the_libblas>" 
LAPACK_LIBRARIES:FILEPATH="-lblas -llapack -L<folder_of_the_libblas>"

Now the aerodyn module is compiled. But a new error occurs,

[ 71%] Building C object modules-ext/map/CMakeFiles/mapcpplib.dir/src/mapapi.c.obj
In file included from F:\cyPHM\openfast\modules-ext\map\src\mapapi.c:31:0:
F:\cyPHM\openfast\modules-ext\map\src\outputstream.h:36:16: error: conflicting types for 'fopen_s'
 MAP_ERROR_CODE fopen_s(FILE** f, const char* name, const char* mode);
                ^~~~~~~
In file included from C:/PROGRA~1/MINGW-~1/X86_64~1.0-P/mingw64/x86_64-w64-mingw32/include/stdio.h:1034:0,
                 from F:\cyPHM\openfast\modules-ext\map\src\mapsys.h:27,
                 from F:\cyPHM\openfast\modules-ext\map\src\map.h:28,
                 from F:\cyPHM\openfast\modules-ext\map\src\mapapi.c:24:

from openfast.

@yagweb Thanks for the feedback. We will include this in our documentation for the benefit of future MinGW users.

from openfast.

I'm having an issue similar to yagweb (11/8/17) on fortran compiling aerodyn except this is my initial installation. I don't fully understand providing the BLAS or LAPACK libraries within quotes, though I feel confident that I could install them if needed, however, I have openblas, so I shouldn't need those. I thought perhaps that that might be broken so I acquired a copy of intel parallel studio (MKL included). So maybe I have conflicting packages?

I was able to install openfast with brew install, however, I need to be able access the shared libraries so I can call functions from Julia.

I'm running MacOS 10.15.4

I downloaded the binaries via git, navigated into the folder, made a directory named build, ran cmake .. then ran make. This is the error code:

[ 27%] Building Fortran object modules/aerodyn/CMakeFiles/aerodyn_driver.dir/src/AeroDyn_Driver_Subs.f90.o [ 27%] Building Fortran object modules/aerodyn/CMakeFiles/aerodyn_driver.dir/src/AeroDyn_Driver.f90.o [ 28%] Linking Fortran executable aerodyn_driver Undefined symbols for architecture x86_64: "_dgbsv_", referenced from: _nwtc_lapack_mp_lapack_dgbsv_ in libnwtclibs.a(NWTC_LAPACK.f90.o) (maybe you meant: _nwtc_lapack_mp_lapack_dgbsv_) "_dgemm_", referenced from: _nwtc_lapack_mp_lapack_dgemm_ in libnwtclibs.a(NWTC_LAPACK.f90.o) (maybe you meant: _nwtc_lapack_mp_lapack_dgemm_) "_dgesv_", referenced from: _nwtc_lapack_mp_lapack_dgesv_ in libnwtclibs.a(NWTC_LAPACK.f90.o) (maybe you meant: _nwtc_lapack_mp_lapack_dgesv_) "_dgesvd_", referenced from: _nwtc_lapack_mp_lapack_dgesvd_ in libnwtclibs.a(NWTC_LAPACK.f90.o) (maybe you meant: _nwtc_lapack_mp_lapack_dgesvd_) "_dgetrf_", referenced from: _nwtc_lapack_mp_lapack_dgetrf_ in libnwtclibs.a(NWTC_LAPACK.f90.o) (maybe you meant: _nwtc_lapack_mp_lapack_dgetrf_) "_dgetri_", referenced from: _nwtc_lapack_mp_lapack_dgetri_ in libnwtclibs.a(NWTC_LAPACK.f90.o) (maybe you meant: _nwtc_lapack_mp_lapack_dgetri_) "_dgetrs_", referenced from: _nwtc_lapack_mp_lapack_dgetrs_ in libnwtclibs.a(NWTC_LAPACK.f90.o) _nwtc_lapack_mp_lapack_dgetrs1_ in libnwtclibs.a(NWTC_LAPACK.f90.o) (maybe you meant: _nwtc_lapack_mp_lapack_dgetrs_) "_dggev_", referenced from: _nwtc_lapack_mp_lapack_dggev_ in libnwtclibs.a(NWTC_LAPACK.f90.o) (maybe you meant: _nwtc_lapack_mp_lapack_dggev_) "_dposv_", referenced from: _nwtc_lapack_mp_lapack_dposv_ in libnwtclibs.a(NWTC_LAPACK.f90.o) (maybe you meant: _nwtc_lapack_mp_lapack_dposv_) "_dpptrf_", referenced from: _nwtc_lapack_mp_lapack_dpptrf_ in libnwtclibs.a(NWTC_LAPACK.f90.o) (maybe you meant: _nwtc_lapack_mp_lapack_dpptrf_) "_sgbsv_", referenced from: _nwtc_lapack_mp_lapack_sgbsv_ in libnwtclibs.a(NWTC_LAPACK.f90.o) (maybe you meant: _nwtc_lapack_mp_lapack_sgbsv_) "_sgemm_", referenced from: _nwtc_lapack_mp_lapack_sgemm_ in libnwtclibs.a(NWTC_LAPACK.f90.o) (maybe you meant: _nwtc_lapack_mp_lapack_sgemm_) "_sgesv_", referenced from: _nwtc_lapack_mp_lapack_sgesv_ in libnwtclibs.a(NWTC_LAPACK.f90.o) (maybe you meant: _nwtc_lapack_mp_lapack_sgesv_) "_sgesvd_", referenced from: _nwtc_lapack_mp_lapack_sgesvd_ in libnwtclibs.a(NWTC_LAPACK.f90.o) (maybe you meant: _nwtc_lapack_mp_lapack_sgesvd_) "_sgetrf_", referenced from: _nwtc_lapack_mp_lapack_sgetrf_ in libnwtclibs.a(NWTC_LAPACK.f90.o) (maybe you meant: _nwtc_lapack_mp_lapack_sgetrf_) "_sgetri_", referenced from: _nwtc_lapack_mp_lapack_sgetri_ in libnwtclibs.a(NWTC_LAPACK.f90.o) (maybe you meant: _nwtc_lapack_mp_lapack_sgetri_) "_sgetrs_", referenced from: _nwtc_lapack_mp_lapack_sgetrs_ in libnwtclibs.a(NWTC_LAPACK.f90.o) _nwtc_lapack_mp_lapack_sgetrs1_ in libnwtclibs.a(NWTC_LAPACK.f90.o) (maybe you meant: _nwtc_lapack_mp_lapack_sgetrs_) "_sggev_", referenced from: _nwtc_lapack_mp_lapack_sggev_ in libnwtclibs.a(NWTC_LAPACK.f90.o) (maybe you meant: _nwtc_lapack_mp_lapack_sggev_) "_sposv_", referenced from: _nwtc_lapack_mp_lapack_sposv_ in libnwtclibs.a(NWTC_LAPACK.f90.o) (maybe you meant: _nwtc_lapack_mp_lapack_sposv_) "_spptrf_", referenced from: _nwtc_lapack_mp_lapack_spptrf_ in libnwtclibs.a(NWTC_LAPACK.f90.o) (maybe you meant: _nwtc_lapack_mp_lapack_spptrf_) ld: symbol(s) not found for architecture x86_64 make[2]: *** [modules/aerodyn/aerodyn_driver] Error 1 make[1]: *** [modules/aerodyn/CMakeFiles/aerodyn_driver.dir/all] Error 2 make: *** [all] Error 2

from openfast.

@Cardoza2 CMake should do the work of finding the math libraries for you so long as they're installed in the usual place. On Mac, that's /usr/local/lib/. There are probably some other default search paths, as well.

How did you install OpenBLAS and MKL? If you want CMake to find the MKL libraries, you'll probably have to run (or source) the compilervars.sh script provided with the Parallel Studio installation so that those libraries are added to your path. Otherwise, I suggest sticking with either Homebrew or Conda for all of the packages. That is, pick one of those two and install CMake, BLAS, and Lapack. Then, running cmake .. from the build directory should find everything it needs.

Also, I'm very interested in your efforts to couple OpenFAST with Julia. Feel free to get in touch with me directly to talk about the strategy there and whether we might be able to distribute some efforts. We have work within NREL along the same lines right now.

from openfast.

OpenBLAS was previously installed when I went to install it with homebrew. I installed MKL when I downloaded the Intel Parallel studios student edition. It came with an installer that I ran. I tried something with sourcing it, but I probably was off in the weeds. I'll look into that a little more.

from openfast.

@rafmudaf On MacOS the default location for blas/lapack recommended would be:

/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/Accelerate.framework

If homebrew is installed, then developer tools is most likely already available. CMake/OpenFAST should find this without further prodding.

from openfast.

@sayerhs good point, the Accelerate library is probably already installed at the location you point out. I was referring to the location for a different math library installed either manually or with Homebrew. In any case, like you say, CMake should be finding Accelerate or the another math library without any additional direction.

from openfast.

Thank you guys. It worked when I ran source /opt/intel/bin/compilervars.sh intel64 before running cmake. Not entirely sure why it didn't find the Accelerate library or the developer tools... so that's odd.

from openfast.

Yep it is indeed odd. You can see the Xcode tools path:

(pyfast) >>mbp@~/Development/openfast/build (dev *$)$ xcode-select -p
/Applications/Xcode.app/Contents/Developer

What does yours say? CMake find Accelerate for me at

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/Accelerate.framework

This is interesting because I'm on macOS 10.14, but I guess I have the 10.15 SDK installed.

from openfast.

So that command returns /Library/Developer/CommandLineTools.

I don't remember updating to 10.15 SDK, but it should have updated when I updated macOS 10.15, right?

from openfast.