search

OpenFAST / openfast

Main repository for the NREL-supported OpenFAST whole-turbine and FAST.Farm wind farm simulation codes.
http://openfast.readthedocs.io
Apache License 2.0
651 stars 446 forks source link

Build Error: Kind -1 not supported for type REAL #941

Closed ArnoldTUB closed 1 year ago

ArnoldTUB commented 2 years ago

Bug description When executing make in the /OpenFAST/build directory after executing cmake .. I receive the following error messages

/OpenFAST/modules/nwtc-library/src/SysGnuLinux.f90:139:13:

  139 |    REAL(QuKi), INTENT(IN)     :: x             ! input
      |             1
Error: Kind -1 not supported for type REAL at (1)
/OpenFAST/modules/nwtc-library/src/SysGnuLinux.f90:140:13:
/OpenFAST/modules/nwtc-library/src/SysGnuLinux.f90:170:25:

  170 | FUNCTION NWTC_GammaR16( x )
      |                         1
Error: Symbol 'x' at (1) has no IMPLICIT type

amongst similar ones (the variable QuKi's kind not being supported for type REAL at several lines and other variables not having an IMPLICIT type)

To Reproduce I followed the documentary to compile OpenFAST from source code (on Mac) at https://openfast.readthedocs.io/en/main/source/install/index.html#compile-from-source:

  1. brew install git cmake make openblas gcc
  2. git clone https://github.com/OpenFAST/OpenFAST.git
  3. cd OpenFAST mkdir build cd build
  4. cmake ..
  5. make

I also tried to to set DOUBLE_PRECISION to OFF which did reduce the amount of errors.

System Information (please complete the following information):

Thanks in advance for your support!

andrew-platt commented 2 years ago

Which version of GCC are you using? And which version of the Fortran compiler?

ArnoldTUB commented 2 years ago

GNU Fortran (Homebrew GCC 11.2.0_3) 11.2.0

bjonkman commented 2 years ago

Which version of GNU fortran are you using? If your compiler doesn't support QuKi, there are some possible workarounds in the first bullet point in https://github.com/OpenFAST/openfast/issues/88.

ArnoldTUB commented 2 years ago

I am not sure if I understand. When executing gfortran -v in the terminal I receive

Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/opt/homebrew/Cellar/gcc/11.2.0_3/libexec/gcc/aarch64-apple-darwin21/11/lto-wrapper Target: aarch64-apple-darwin21 Configured with: ../configure --prefix=/opt/homebrew/Cellar/gcc/11.2.0_3 --libdir=/opt/homebrew/Cellar/gcc/11.2.0_3/lib/gcc/11 --disable-nls --enable-checking=release --with-gcc-major-version-only --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-11 --with-gmp=/opt/homebrew/opt/gmp --with-mpfr=/opt/homebrew/opt/mpfr --with-mpc=/opt/homebrew/opt/libmpc --with-isl=/opt/homebrew/opt/isl --with-zstd=/opt/homebrew/opt/zstd --with-pkgversion='Homebrew GCC 11.2.0_3' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues --build=aarch64-apple-darwin21 --with-system-zlib --disable-multilib --with-native-system-header-dir=/usr/include --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.2.0 (Homebrew GCC 11.2.0_3)

Note the last line: gcc version 11.2.0 (Homebrew GCC 11.2.0_3) So how exactly do I check version of GNU fortran I am using?

bjonkman commented 2 years ago

Sorry, I misread your original comment. You do have version 11.2.0 (gcc is the compiler collection that includes c and gfortran).

That compiler version should support REAL(16), so it seems like either QuKi isn't getting set properly in SingPrec.f90 or the compiler thinks your target architecture doesn't support quad-type reals.

As a quick check, you could modify SingPrec.f90 in the NWTC Library source code. Remove (or comment out) lines 43:

INTEGER, PARAMETER              :: QuKi     = real128    !< Kind for 16-byte, floating-point numbers

and 47:

INTEGER, PARAMETER              :: QuKi     = SELECTED_REAL_KIND( 20, 500 )     !< Kind for 16-byte, floating-point numbers

Then add this around line 55:

INTEGER, PARAMETER              :: QuKi     = 16     !< Kind for 16-byte, floating-point numbers

Then build again and see if that fixes the issue or gives you a different error.

annacclark commented 2 years ago

Hello! I have been trying to install OpenFAST as well and have run into the same issue as @ArnoldTUB with the same system specs (except I am on macOS Big Sur 11.6 rather than Monterey). @bjonkman, After altering SingPrec.f90 per your suggestion, I tried a fresh build and unfortunately received the same error messages (this is with DOUBLE_PRECISION set to OFF): 

-- Build files have been written to: /Users/clark/opt/anaconda3/envs/openfast_env/OpenFAST/build
(base) clark@Clarks-Air build % make
Scanning dependencies of target versioninfolib
[  0%] Building Fortran object modules/version/CMakeFiles/versioninfolib.dir/src/VersionInfo.f90.o
[  0%] Linking Fortran static library libversioninfolib.a
[  0%] Built target versioninfolib
Scanning dependencies of target nwtclibs
[  0%] Building Fortran object modules/nwtc-library/CMakeFiles/nwtclibs.dir/src/SingPrec.f90.o
[  0%] Building Fortran object modules/nwtc-library/CMakeFiles/nwtclibs.dir/src/NWTC_Base.f90.o
[  0%] Building Fortran object modules/nwtc-library/CMakeFiles/nwtclibs.dir/src/SysGnuLinux.f90.o
/Users/clark/opt/anaconda3/envs/openfast_env/OpenFAST/modules/nwtc-library/src/SysGnuLinux.f90:139:13:
 139 |    REAL(QuKi), INTENT(IN)     :: x             ! input
      |             1
Error: Kind 16 not supported for type REAL at (1)
/Users/clark/opt/anaconda3/envs/openfast_env/OpenFAST/modules/nwtc-library/src/SysGnuLinux.f90:140:13:

  140 |    REAL(QuKi)                 :: NWTC_ERFR16   ! result
      |             1
Error: Kind 16 not supported for type REAL at (1)
/Users/clark/opt/anaconda3/envs/openfast_env/OpenFAST/modules/nwtc-library/src/SysGnuLinux.f90:134:0:

  134 | FUNCTION NWTC_ERFR16( x )
      | 
Error: Function result 'nwtc_erfr16' at (1) has no IMPLICIT type
/Users/clark/opt/anaconda3/envs/openfast_env/OpenFAST/modules/nwtc-library/src/SysGnuLinux.f90:175:13:

  175 |    REAL(QuKi), INTENT(IN)     :: x             ! input
      |             1
Error: Kind 16 not supported for type REAL at (1)
/Users/clark/opt/anaconda3/envs/openfast_env/OpenFAST/modules/nwtc-library/src/SysGnuLinux.f90:176:13:

  176 |    REAL(QuKi)                 :: NWTC_GammaR16  ! result
      |             1
Error: Kind 16 not supported for type REAL at (1)
/Users/clark/opt/anaconda3/envs/openfast_env/OpenFAST/modules/nwtc-library/src/SysGnuLinux.f90:170:0:

  170 | FUNCTION NWTC_GammaR16( x )
      | 
Error: Function result 'nwtc_gammar16' at (1) has no IMPLICIT type
/Users/clark/opt/anaconda3/envs/openfast_env/OpenFAST/modules/nwtc-library/src/SysGnuLinux.f90:134:23:

  134 | FUNCTION NWTC_ERFR16( x )
      |                       1
Error: Symbol 'x' at (1) has no IMPLICIT type
/Users/clark/opt/anaconda3/envs/openfast_env/OpenFAST/modules/nwtc-library/src/SysGnuLinux.f90:170:25:

  170 | FUNCTION NWTC_GammaR16( x )
      |                         1
Error: Symbol 'x' at (1) has no IMPLICIT type
make[2]: *** [modules/nwtc-library/CMakeFiles/nwtclibs.dir/src/SysGnuLinux.f90.o] Error 1
make[1]: *** [modules/nwtc-library/CMakeFiles/nwtclibs.dir/all] Error 2
make: *** [all] Error 2
(base) clark@Clarks-Air build %

Any troubleshooting suggestions would be greatly appreciated! Thanks.

ArnoldTUB commented 2 years ago

@bjonkman First of all, thank you very much for your suggestions. I have implemented the changes suggested by you. After saving the changes in SingPrec.f90 I executed cmake .. and make and received a similar error:

Error: Kind 16 not supported for type REAL at (1) Note, that it is kind 16 now instead of -1.

bjonkman commented 2 years ago

Thanks for checking those changes. It seems like your systems do not support quad precision. (Maybe @andrew-platt or @rafmudaf can explain what's going on there?)

For single-precision builds, you should be able to use the code changes on this branch to avoid issues with the limitation on 16-byte reals: https://github.com/bjonkman/openfast/tree/test/SingPrec_noQuad. This won't build in double precision, though. That will require more code changes than I have time for at the moment. 😃

andrew-platt commented 2 years ago

Hi @ArnoldTUB and @annacclark. Are either of you running MacBooks with the new M1 chipset? One possibility is the new M1 chipset doesn't support QuKi, but I have no way of confirming this.

Another possibility is that the gfortran compiler isn't actually getting set as you are expecting in the cmake setup process. You may need to do export FCC=<path to gfortran executable> prior to running cmake. You can check exactly which compiler is used by looking for CMAKE_Fortran_COMPILER= in the CMakeCache.txt file in your build directory. As I recall, MacOS may default to an older fortran compiler that is distributed with Xcode and is does not support QuKi (it has been a while since I've run into this, so I may be incorrectly remembering).

@rafmudaf, I noticed that @annacclark is using anaconda. Do you know which compiler version is used there? I still haven't gotten up to speed with using the anaconda builds.

sayerhs commented 2 years ago

I'd encountered this issue in #502 and submitted a fix in #512 can you check if HAS_FORTRAN2008_FEATURES was activated in your build?

annacclark commented 2 years ago

Hi all, thank you so much for your feedback and responses!

@andrew-platt I am using a Mac with the new M1 chip, so there is a possibility that this is what has been causing the issue. Given the lack of success I have had with other suggestions, I am thinking this is the most likely culprit, but I would absolutely be open to any other troubleshooting tips.

@sayerhs based on your response, I tried a fresh build specifying -DHAS_FORTRAN2008_FEATURES=ON (as well as -DDOUBLE_PRECISION=OFF) when executing CMake but I received a message that this flag was not used by CMake:

CMake Warning:
Manually-specified variables were not used by the project:

HAS_FORTRAN2008_FEATURES

When I then tried to compile all the files, I received the same error messages as before, namely that certain variables have no implicit type and that QuKi is not supported. Please let me know if I interpreted your questions regarding HAS_FORTRAN2008_FEATURES correctly. Thank you!

139 |    REAL(QuKi), INTENT(IN)     :: x             ! input
      |             1
Error: Kind 16 not supported for type REAL at (1)
/Users/clark/opt/anaconda3/envs/openfast_env/OpenFAST/modules/nwtc-library/src/SysGnuLinux.f90:140:13:

  140 |    REAL(QuKi)                 :: NWTC_ERFR16   ! result
      |             1
Error: Kind 16 not supported for type REAL at (1)
/Users/clark/opt/anaconda3/envs/openfast_env/OpenFAST/modules/nwtc-library/src/SysGnuLinux.f90:134:0:

  134 | FUNCTION NWTC_ERFR16( x )
      | 
Error: Function result 'nwtc_erfr16' at (1) has no IMPLICIT type
/Users/clark/opt/anaconda3/envs/openfast_env/OpenFAST/modules/nwtc-library/src/SysGnuLinux.f90:175:13:

  175 |    REAL(QuKi), INTENT(IN)     :: x             ! input
      |             1
Error: Kind 16 not supported for type REAL at (1)
/Users/clark/opt/anaconda3/envs/openfast_env/OpenFAST/modules/nwtc-library/src/SysGnuLinux.f90:176:13:

  176 |    REAL(QuKi)                 :: NWTC_GammaR16  ! result
      |             1
Error: Kind 16 not supported for type REAL at (1)
/Users/clark/opt/anaconda3/envs/openfast_env/OpenFAST/modules/nwtc-library/src/SysGnuLinux.f90:170:0:

  170 | FUNCTION NWTC_GammaR16( x )
      | 
Error: Function result 'nwtc_gammar16' at (1) has no IMPLICIT type
/Users/clark/opt/anaconda3/envs/openfast_env/OpenFAST/modules/nwtc-library/src/SysGnuLinux.f90:134:23:

  134 | FUNCTION NWTC_ERFR16( x )
      |                       1
Error: Symbol 'x' at (1) has no IMPLICIT type
/Users/clark/opt/anaconda3/envs/openfast_env/OpenFAST/modules/nwtc-library/src/SysGnuLinux.f90:170:25:

  170 | FUNCTION NWTC_GammaR16( x )
      |                         1
Error: Symbol 'x' at (1) has no IMPLICIT type
ArnoldTUB commented 2 years ago

I want to also thank you @bjonkman @andrew-platt @sayerhs!

First of all, my Mac does use a M1 chipset. Fortran compiler is set correctly according to CmakeCache.txt.

For -DHAS_FORTRAN2008_FEATURES=ON, I receive the same result as @annacclark.

The SingPrec_NoQuad code didn't work either, unfortunately (-DDOUBLE_PRECISION=OFF).

Please let me know if you have other suggestions.

sayerhs commented 2 years ago

Thanks @annacclark and @ArnoldTUB , I've a MacBook with the M1 chip, I'll test this on that machine and post any workarounds that I can figure out.

bjonkman commented 2 years ago

@ArnoldTUB , what error(s) did you get with the SingPrec_NoQuad branch?

ArnoldTUB commented 2 years ago

@bjonkman pretty much the same errors as with the original code. The first one, for instance:

/OpenFAST_Single/openfast/modules/nwtc-library/src/SysGnuLinux.f90:139:13:

  139 |    REAL(QuKi), INTENT(IN)     :: x             ! input
      |             1
Error: Kind -1 not supported for type REAL at (1)
/OpenFAST_Single/openfast/modules/nwtc-library/src/SysGnuLinux.f90:140:13:

Followed by these no IMPLICIT type errors

bjonkman commented 2 years ago

Are you sure this is from a clean build? Or with the correct branch? In my SingPrec_NoQuad branch, QuKi = 8, so I would expect the error to say Kind 8 not supported for type REAL if it were building that code.

ArnoldTUB commented 2 years ago

Apparently, something went wrong and I did not build the correct branch. After double checking whether I used the correct branch, I successfully build from source (-DDOUBLE_PRECISION=OFF -BUILD_SHARED_LIBS=ON)! Now I wonder if the program's performance is anyhow affected by not using quad type reals. Anyway, thanks a lot so far!

bjonkman commented 2 years ago

@ArnoldTUB, Single-precision builds do not use the quad-precision routines, so I wouldn't expect any differences in results other than from (possible) compiler optimizations.

annacclark commented 2 years ago

@ArnoldTUB would you mind sharing the steps you took to successfully build from the source? I'm still having trouble unfortunately, and would appreciate comparing what I did to what you did to troubleshoot. Thanks!

(For reference, I deleted the main OpenFAST branch from my machine, cloned the SingPrec_NoQuad branch that @bjonkman kindly shared, and altered SingPrec.f90 as before, before building with the cmake .. command. However, I'm still receiving the same error messages that Kind 16 not supported for type REAL at (1) and Symbol 'x' at (1) has no IMPLICIT type after issuing the make command.)

bjonkman commented 2 years ago

@annacclark , Make sure you have checked out the SingPrec_noQuad branch. You shouldn't have to change SingPrec.f90 in that branch, and it would not say Kind 16 not supported because there are no quad-precision variables.

git checkout test/SingPrec_noQuad
annacclark commented 2 years ago

Thank you! I checked out the correct branch, as you suggested, and just finished successfully building it. I really appreciate your time and help!

ArnoldTUB commented 2 years ago

Glad it worked out for you as well @annacclark! Now, I want to create an S-Function to couple Simulink and OpenFAST. However, building with BUILD_OPENFAST_SIMULINK_API=ON yields another error: 

ld: warning: ignoring file /Applications/MATLAB_R2021b.app/bin/maci64/libmex.dylib, building for macOS-arm64 but attempting to link with file built for macOS-x86_64
Undefined symbols for architecture arm64:
  "_mexprintf_", referenced from:
      ___syssubs_MOD_writescr in SysMatlabLinuxGnu.f90.o
      ___syssubs_MOD_wrnr in SysMatlabLinuxGnu.f90.o
ld: symbol(s) not found for architecture arm64
collect2: error: ld returned 1 exit status
make[3]: *** [modules/nwtc-library/libnwtclibs.dylib] Error 1
make[2]: *** [modules/nwtc-library/CMakeFiles/nwtclibs.dir/all] Error 2
make[1]: *** [glue-codes/openfast/CMakeFiles/openfast.dir/rule] Error 2
make: *** [openfast] Error 2

It seems to me that the M1 chip's architecture poses another problem. Do you have an idea how to work around this one?

P.S.: Please let me know if I should open another issue for this specific problem. In that case I would close this one.

bjonkman commented 2 years ago

The mexPrintF is defined in Matlab's libmex library; it allows the OpenFAST library to print messages to the Matlab console. In the Windows/Intel version of the SysMatlab*.f90 file, there is a preprocessor definition called CONSOLE_FILE that writes all the screen output to a text file instead using mexPrintF. I've copied those parts into the Linux version of that file and added them to the latest commit of my test/SingPrec_noQuad branch. You could probably get the code to build with those changes since it won't need the libmex file.

However, I am concerned that Simulink won't recognize it. It appears that your gcc compiler is building arm64 code but that your Matlab library is built using the x86-64. Is there another architecture listed under /Applications/MATLAB_R2021b.app/bin/?

carlosluissb commented 1 year ago

Glad it worked out for you as well @annacclark! Now, I want to create an S-Function to couple Simulink and OpenFAST. However, building with BUILD_OPENFAST_SIMULINK_API=ON yields another error:

ld: warning: ignoring file /Applications/MATLAB_R2021b.app/bin/maci64/libmex.dylib, building for macOS-arm64 but attempting to link with file built for macOS-x86_64
Undefined symbols for architecture arm64:
  "_mexprintf_", referenced from:
      ___syssubs_MOD_writescr in SysMatlabLinuxGnu.f90.o
      ___syssubs_MOD_wrnr in SysMatlabLinuxGnu.f90.o
ld: symbol(s) not found for architecture arm64
collect2: error: ld returned 1 exit status
make[3]: *** [modules/nwtc-library/libnwtclibs.dylib] Error 1
make[2]: *** [modules/nwtc-library/CMakeFiles/nwtclibs.dir/all] Error 2
make[1]: *** [glue-codes/openfast/CMakeFiles/openfast.dir/rule] Error 2
make: *** [openfast] Error 2

It seems to me that the M1 chip's architecture poses another problem. Do you have an idea how to work around this one?

P.S.: Please let me know if I should open another issue for this specific problem. In that case I would close this one.

Hello, greetings to all. I have this same problem if anyone knows how to solve it, I'm interested in using OpenFast with Simulink to test Pitch controllers.

ArnoldTUB commented 1 year ago

Hello everyone! A solution for my problem has been found in this issue. To everyone that had a similar problem, please give the suggested solution there a read.