openfast icon indicating copy to clipboard operation
openfast copied to clipboard

Build Error: Kind -1 not supported for type REAL

Open ArnoldTUB opened this issue 4 years ago • 24 comments

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):

  • OS: MacOS Monterey 12.0.1
  • Compiler: all up to date as brew install git cmake make openblas gcc has been used

Thanks in advance for your support!

ArnoldTUB avatar Dec 10 '21 16:12 ArnoldTUB

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

andrew-platt avatar Dec 10 '21 17:12 andrew-platt

GNU Fortran (Homebrew GCC 11.2.0_3) 11.2.0

ArnoldTUB avatar Dec 11 '21 21:12 ArnoldTUB

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.

bjonkman avatar Dec 13 '21 16:12 bjonkman

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?

ArnoldTUB avatar Dec 13 '21 17:12 ArnoldTUB

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.

bjonkman avatar Dec 13 '21 17:12 bjonkman

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.

annacclark avatar Dec 14 '21 05:12 annacclark

@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.

ArnoldTUB avatar Dec 14 '21 11:12 ArnoldTUB

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. 😃

bjonkman avatar Dec 14 '21 16:12 bjonkman

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.

andrew-platt avatar Dec 14 '21 17:12 andrew-platt

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?

sayerhs avatar Dec 14 '21 17:12 sayerhs

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

annacclark avatar Dec 15 '21 04:12 annacclark

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.

ArnoldTUB avatar Dec 15 '21 11:12 ArnoldTUB

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.

sayerhs avatar Dec 15 '21 11:12 sayerhs

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

bjonkman avatar Dec 15 '21 15:12 bjonkman

@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

ArnoldTUB avatar Dec 15 '21 15:12 ArnoldTUB

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.

bjonkman avatar Dec 15 '21 15:12 bjonkman

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!

ArnoldTUB avatar Dec 15 '21 16:12 ArnoldTUB

@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.

bjonkman avatar Dec 15 '21 17:12 bjonkman

@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.)

annacclark avatar Dec 15 '21 18:12 annacclark

@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

bjonkman avatar Dec 15 '21 19:12 bjonkman

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

annacclark avatar Dec 15 '21 20:12 annacclark

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.

ArnoldTUB avatar Dec 16 '21 10:12 ArnoldTUB

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/?

bjonkman avatar Dec 20 '21 18:12 bjonkman

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.

carlosluissb avatar Jul 29 '22 10:07 carlosluissb

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.

ArnoldTUB avatar Nov 25 '22 13:11 ArnoldTUB