-
Notifications
You must be signed in to change notification settings - Fork 451
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issues when building OpenFAST on Windows under Cygwin #144
Comments
I was having the same problem, but instead of adding the url as "http://www.gtlib.gatech.edu" I added it as "http://www.gtlib.gatech.edu/pub/cygwin/" and it worked. |
I tried again with http://www.gtlib.gatech.edu/pub/cygwin/, but there seems to be no difference from using other official mirrors for cygwin. I updated the versions to the newest versions of all necessary packages and rebooted as well. I think the main problem is issues with the OpenBLAS version of BLAS. Should older version of the cygwin packages be used in order to make the build work? |
I may suggest starting from scratch and following the installation instructions exactly , as this is what I did yesterday and was successful in compiling. Namely selecting the packages to install:
|
I have meticulously followed the steps in the documentation before, and after much back and forth I have concluded that there must be something different with my setup that is causing the problem (see below). The docs still needs to be updated with the correct cygwin mirror web address and the makefile will have to be added to the source if the cmake-step should be skipped. I have not found out exactly what the cause of the problem was, but I have clues that it might be linked to concurrent installations of cygwin and ubuntu for windows 10. It might also be that I am installing this with administrator privilileges under a non-administrator user and the mixing of users seems to create folders and files that have different owners. I have though successfully compiled OpenFAST under Cygwin now on a different computer following the instructions. I am able to run openfast -h, but I get an error when running an actual fst file that is working fine with the precompiled version for windows ("Exception: STATUS_STACK_OVERFLOW at rip=."). I have tried transferring this compilation over to the first computer, following the instructions for cmd runs, but get the same error. I will probably be using the linux-version of OpenFAST now, as this is the only remaining free option available to my knowledge. |
Did you use a Bladed style dll? I compiled openfast following the docs and get the same error ("Exception: STATUS_STACK_OVERFLOW at rip=003F96EA5D6...") when running a fst wich worked well under the precompiled version of openfast. The program terminates after running ServoDyn. Is there anything I have to account for using Bladed style dll? Any idea, what I could do to fix this? |
Yes, I used the Bladed style dll / DISCON for Hywind OC3. When compiling under linux I have no problem using this library. |
I built Openfast on Windows with Cygwin64 and Cmake but when running any of the regression tests I keep getting the same problem. The last one I've tried, the 5MW_OC4Jckt_DLL_WTurb_WavesIrr_MGrowth test, runs correctly until this message appears: "15999 [] openfast 12504 cygwin_exception::open_stackdumpfile: Dumping stack trace to openfast.exe.stackdump". What am I missing? Anyone knows? I'll leave a screenshot so you can see in more detail. Thank you very much in advance. |
This must be a problem with the compilation of ServoDyn in cygwin - I started with a new cygwin, installed the packages as per the instructions (also the proposed repository). Servodyn seems to run ok on The error mentioned at "#144 (comment)" Stacktrace:
Some results on what runs and what not that maybe will help others more experienced to figure out what is wrong. Detailed output from FAST: for
for
|
My guess (without having looked at the details of the OpenFAST build for cygwin): The code in the Sys*.f90 files that opens DLLs may be incorrect or the build could be using the wrong Sys*.f90 file for Cygwin. These are very system-specific calls. |
I had build the openfast successfully by cygwin on Windows10. but when I run the openfast.exe on cmd I have the following output: Running ElastoDyn. How to fix this problem? |
When I compiling the openfast, the following warning message exits. I doubted that this will lead to stackdump problem when run.
warning: ‘__builtin_memset’: specified size 18446744073709551598 exceeds maximum object s |
I am having similar errors as the above comments. I have compiled openFAST meticulously following the steps in the documentation using CMake and Cygwin. If I run the r-test "5MW_OC4Semi_WSt_WavesWN" similar but different error appers as well: Any solutions would be really appreciated. Thank you very much beforehand! |
I also receive a similar error: openfast 6056 cygwin_exception::open_stackdumpfile: Dumping stack trace to openfast.exe.stackdump If it is any help the AOC, AWT, ideal beam, and SWRT simulations all seem to run fine, but the WP and 5MW baseline simulations produced the error above. I compiled the appropriate .dll files required for servodyn to run, but don't think those are the issue, since the error only appears when the Aerodyn flag is on (regardless of servodyn flag being on/off). If I turn off the aerodynamics in the simulation, all runs complete without error. |
I also receive a similar error for OpenFAST-v2.0.0-dirty and Test 18: Maybe this helps to track down the error:
|
In my case, there is also a large difference in speed between the cygwin compiled version and the one compiled with Visual Studio:
I would expect more or less double of the time for double precision compared to single precision, but no difference between both double precision versions (cygwin and Visual Studio). Is this normal? |
Hello everyone ; I installed openfast on windows using cmake and cygwin. I need to understand Any suggestion or solution would be really appreciated. |
The documentation issue described here is fixed by #262. I will open a new issue for the seg fault and post recent work in this area there. |
@philipalkhoury I was able to run the regression tests when I changed the optimization setting to
In Release mode, the default fortran flags (imposed by cmake) are:
Whereas in Release with Debug Info mode (RelWithDebInfo), the fortran flags are:
UPDATE: The comment above is incorrect, I mistook MinGW for Cygwin. I'm working on the problems listed here with Cygwin, but I not yet been able to run the regression test cases. |
Hello, Sorry for bothering with this issue again, but I am encountering the same, or a very similar one. I have compiled the latest version of OpenFAST on the dev branch (26/07/2019, version OpenFAST-v2.1.0-164-gacc3f980-dirty) with Cygwin on Windows. It works fine (although very slowly) for most simulations as long as AeroDyn v15 is deactivated. As soon as I turn it on, simulations crash with this message "Segmentation fault (core dumped)". Files named "openfast.exe.stackdump" are left in the build directory when it happens. I do not understand their content but it starts with "Exception: STATUS_STACK_OVERFLOW". The regression tests that use AeroDyn v15 fail for the same reason (the ones using v14 seem to work). I have successfully recompiled several times with the RelWithDebInfo option as advised above only to find the same error in the end. Is there something I missed to make it work? Thank you very much in advance for your help. |
@AntoineHEN the seg fault issue seems to be specific to Cygwin and AeroDyn 15 and it is as yet unsolved. You could try debugging with compiler flags or configuring gdb. I tried the latter but had no luck. Other options for running OpenFAST on Windows are:
|
@rafmudaf: the stack overflow message makes me wonder if this is just a problem with the stack size. Have you checked if cmake has specified the stack reserve size for the linker on cygwin? The default stack reserve size is not very large. |
@bjonkman it looks like thats the problem! CMake was not setting a specific stack size, but I added these lines and at least the first 8 aerodyn15 tests have passed:
If everything checks out, I'll submit the pull request soon. |
Thank you very much @bjonkman and @rafmudaf for your swift answers and investigation! |
@AntoineHEN please pull the latest commits from the
Its a good idea to delete your existing build directory and start from scratch:
|
@rafmudaf yes it works! Thank you again for your help and your quick fix of the code. On another subject, so this might not be the right thread to address it: ctest has never worked for me because there seems to be a problem of paths compatibility between Cygwin and Python (because of the use of "cygdrive/C/ etc" and not just "C:"). Thank you! |
Great to hear! Yes, we can address the ctest problem in another issue. |
I am trying to build OpenFAST on Windows with CMake and Cygwin. I get an error everytime it is trying to build the Registry files. I tried it with 'make all', 'make aerodyn_driver', 'make beamdyn_driver' and it always fails at a registry file. A sample error message is below:
I installed all the Cygwin packages as listed in the docs. Is there some issue with my Environment Variables? |
Which branch are you working from? And did you deviate at all from the build instructions? I haven't seen this error before. If you haven't done this already, I recommend that you remove your build directory, checkout the |
@rafmudaf I was working off the master branch. I switched to dev, and I am facing the same issue. I am following the build process exactly as listed in the docs. I also did a `make clean' then removed the build directory and repeated the process, and the same result. Please see the screendumps in the attached files. |
Thank you, this is great information. I asked whether you deviated from the installation procedures because I noticed that the failed assertion was related to a symlink and there shouldn't be any of those in the build process:
The @bjonkman do you have any clues to offer here? |
I guessed |
I know the Registry code has some special cases for getting the include path names when using cygwin. Maybe that logic assumes something incorrect about cygwin directory names? I'm not sure. |
@vineesh14 here's the command to run the registry manually for inflowwind:
Can you run that and report back? |
@rafmudaf here's the output from the commands. |
I have several issues when following the documentation for building OpenFAST under Cygwin:
In 2.4.1-1 I am unable to use http://www.gtlib.gatech.edu as download site. I am able to access it through a web browser and can find Cygwin there, but the installer complains that it cannot find necessary files there.
I am unable to run "make" directly in any of the folders after installing cygwin with a download site from the list with the packages in 2.4.1-2, rebooting and cloning the OpenFAST repository. There seems to be no makefile in any of the folders.
When trying to run cmake with "FC=gfortran cmake ../" i get the following output. I have installed the openBLAS libary, as described in the docs, and cannot continue after this issue with the build as no makefile is made.
-- The CXX compiler identification is GNU 7.3.0
-- The C compiler identification is GNU 7.3.0
-- The Fortran compiler identification is GNU 7.3.0
-- Check for working CXX compiler: /usr/bin/c++.exe
-- Check for working CXX compiler: /usr/bin/c++.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - failed
-- Detecting CXX compile features
-- Detecting CXX compile features - failed
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Detecting C compile features
-- Detecting C compile features - failed
-- Check for working Fortran compiler: /usr/bin/gfortran.exe
-- Check for working Fortran compiler: /usr/bin/gfortran.exe -- works
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - failed
-- Checking whether /usr/bin/gfortran.exe supports Fortran 90
-- Checking whether /usr/bin/gfortran.exe supports Fortran 90 -- yes
-- Looking for Fortran sgemm
-- Looking for Fortran sgemm - not found
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - found
-- Found Threads: TRUE
CMake Error at /usr/share/cmake-3.6.2/Modules/FindBLAS.cmake:690 (message):
A required library with BLAS API not found. Please specify library
location.
Call Stack (most recent call first):
CMakeLists.txt:56 (find_package)
The text was updated successfully, but these errors were encountered: