Compiling Fast v8 using gfortran

Hi,

Thanks to the provided make files I have been able to compile FAST v8.08.00c-bjj using gfortran under Windows. The problema arrives when I test the resulting .exe using Test25. Then I get the following error message:

[code]…
Timestep: 0 of 60 seconds.

Message from SrvD_CalcOutput:
SrvD_CalcOutput:Running with torque and pitch control of the NREL offshore 5MW baseline wind
turbine from DISCON.dll as written by J. Jonkman of NREL/NWTC for use in the IEA Annex XXIII OC3
studies. Includes modifications for the Hywind spar.

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0 6f610f4e
#1 6f6913eb
#2 004010f8[/code]

So maybe someone has found a similar problema and knows of a workaround.

Many thanks!

Hi, David.

As noted in the “Compiling” section of the FAST v8.08 documentation, none of the offshore models (tests 19-25) will run with the executable generated by the distributed makefile. We develop our code in Intel Fortran and haven’t spent much time with gfortran–occasionally we find some strange differences between compilers. There is apparently a memory problem with the code in gfortran, but we have not been able to track it down. If you do figure out the problem, please let us know so we can fix it in the code we distribute.

Hi,

Thanks for your reply. Sorry for not spotting the explanation in the documentation. Regarding the compilation using gfortran I have tried to pursue it a bit further and I have found a couple of things.

If FAST is compiled using debugging options, ie

FFLAGS = -g -O0 -fbacktrace -ffree-line-length-none -x f95-cpp-input -fcheck=all

Then FAST finds an error because the variable CalcTwrAero gets somehow initialized and therefore FAST looks for the Twr data file path in the wrong line. I solved the issue by adding the following code in AeroSubs.f90 Line 374

P%TwrProps%CalcTwrAero = .FALSE.     ! We don't want to read the tower file!

After this I am able to debug. The SEGFAULT error appears in

FAST_Prog.f90, Line 1124 CALL HydroDyn_CopyInput (HD_Input(j), HD_Input(j+1), MESH_UPDATECOPY, Errstat, ErrMsg) -> ->HydroDyn_Types.f90, Line 2762 CALL Morison_CopyInput( SrcInputData%Morison, DstInputData%Morison, CtrlCode, ErrStat, ErrMsg ) -> ->Morison_Types.f90, Line 6251 CALL MeshCopy( SrcInputData%DistribMesh, DstInputData%DistribMesh, CtrlCode, ErrStat, ErrMsg ) -> ->ModMesh.f90, Line 1439 IF ( ALLOCATED(SrcMesh%Orientation ) .AND. ALLOCATED(DestMesh%Orientation ) ) DestMesh%Orientation = SrcMesh%Orientation

I think that the problema is related to the stack management of automated arrays being different in ifort and gfortran but using the different gfortran command options (-fno-automatic, -fmax-stack-var-size=n, etc) I have not been able yet to solve the problem.

Anyonelse working on this issue?

As I suspect that the issue is related to a memory limitation I was trying now to compile a 64 bit version suing the following modified make file:

[code] # 32-bit or 64-bit?
#BITS = 32
BITS = 64

Location of source files for FAST, AeroDyn, InflowWind, and the NWTC Library.

You will probably need to change these for your system.

FAST_DIR = …/Source

NWTC_Lib_DIR = $(FAST_DIR)/dependencies/NWTC_Library
NETLIB_DIR = $(FAST_DIR)/dependencies/NetLib
ED_DIR = $(FAST_DIR)/dependencies/ElastoDyn
SrvD_DIR = $(FAST_DIR)/dependencies/ServoDyn
AD_DIR = $(FAST_DIR)/dependencies/AeroDyn
IfW_DIR = $(FAST_DIR)/dependencies/InflowWind
HD_DIR = $(FAST_DIR)/dependencies/HydroDyn
SD_DIR = $(FAST_DIR)/dependencies/SubDyn
MAP_DIR = $(FAST_DIR)/dependencies/MAP
FEAM_DIR = $(FAST_DIR)/dependencies/FEAMooring
IceF_DIR = $(FAST_DIR)/dependencies/IceFloe
IceD_DIR = $(FAST_DIR)/dependencies/IceDyn

HD_DIR_Reg = $(HD_DIR)
BIN_DIR = …/bin

ifeq ($(OS),Windows_NT)
Registry = $(BIN_DIR)/Registry_win32.exe
MAP_lib = $(MAP_DIR)/MAP_x64.lib
LAPACK_LINK = -llapack -lblas -LC:/LAPACK/x64
else
Registry = registry.exe
MAP_lib = $(MAP_DIR)/MAP.so
LAPACK_LINK = -llapack -lblas
endif

Name of compiler to use and flags to use.

FC = gfortran

FFLAGS = -g -O0 -fbacktrace -ffree-line-length-none -x f95-cpp-input -fcheck=all

LDFLAGS = -O2 -m$(BITS) -fbacktrace

Precision.

Use “SingPrec” for single precision and “DoubPrec” for double precision. You may also need to change an option switch to make constants DP.

PREC = SingPrec

Destination and RootName for executable

OUTPUT_NAME = FAST
DEST_DIR = …/bin
#DEST_DIR = .

#==========================================================#

You should not need to change anything beyond this point

#==========================================================#

…[/code]

FAST compiles succesfully but it crashed on execution. Have anyone else tried this?

Thanks.

I have been able to compile a 64bit version using gfortran. The crash I was getting was produced, I think, because a mixture of 32 and 64bits libraries. In case someone else is interested what I did is:

  • Donwload MinGW w64 from here

sourceforge.net/projects/mingw-w64/

  • Install the 64bits version and select the sjlj option

  • Change the makefile accordingly (I posted mine in a previous post).

  • You may need to add a -static or -static-libgfortran, -static-libgcc options to the LDFLAGS

  • If DISCON.DLL is needed use a 64 bit version.

And that would be all. Still I am getting a Segmentation Fault error. Just a different one!!

Best Regards.

Hi David.

Nice catch on the uninitialized variable in AeroDyn. I’ve fixed it in my version of the code.

I have previously spent some time trying to track down the seg faults with gfortran–it’s a daunting task because sometimes the seg faults move when I add print statments and sometimes I track one down to a segment of the code that cannot possibly be what’s the actual cause of the problem. For what it is worth, I have been able to run the first 18 FAST CertTests (all of the ones without HydroDyn) using the grfortran executable, and I am told that the HydroDyn stand-alone driver runs when compiled with gfortran.

Hi David,

I downloaded and installed MinGW w64 on my computer (windows 8; 64 bit). How can I compile the makefile? If I go with the command prompt to the path where the makefile lies and type in “make” it tells me, that he does not know this command. What did I wrong?

Thanks!

Achim,

You should see mingw32-make.exe in the \bin directory. Make sure that folder is on your search path, and you can call it using “mingw32-make”. Otherwise you’ll have to specify the full path name to the file.

Dear Bonnie,

thank you. Now I get this error, which says that the ‘precision.mod’ was created by a different version of GNU Fortran.

Compilation_Error2.png

What is wrong now?

Best regards
Achim

The error message says that the precision module was compiled earlier using a different version of the gcc compiler (perhaps you tried compiling with 32-bit earlier?). Type mingw32-make clean and it should delete that precision.mod file and create a new one with the compiler you are using.

Thank you,

that helped! But now I got a new “error”:

Compilation_Error3.png

The CompilingInstructions_FASTv8.pdf says, that there has to be an message like “FAST_iwin64.exe was created.”, but I don’t get a message like this.

Probably I did something wrong with the described linking options -llapack and -lblas?

In the makefile are this settings:

[code] # 32-bit or 64-bit?
#BITS = 32
BITS = 64

Location of source files for FAST, and its modules.

FAST_DIR = …/Source

NWTC_Lib_DIR = $(FAST_DIR)/dependencies/NWTC_Library
NETLIB_DIR = $(FAST_DIR)/dependencies/NetLib
ED_DIR = $(FAST_DIR)/dependencies/ElastoDyn
SrvD_DIR = $(FAST_DIR)/dependencies/ServoDyn
AD_DIR = $(FAST_DIR)/dependencies/AeroDyn
IfW_DIR = $(FAST_DIR)/dependencies/InflowWind
HD_DIR = $(FAST_DIR)/dependencies/HydroDyn
SD_DIR = $(FAST_DIR)/dependencies/SubDyn
MAP_DIR = $(FAST_DIR)/dependencies/MAP
FEAM_DIR = $(FAST_DIR)/dependencies/FEAMooring
MD_DIR = $(FAST_DIR)/dependencies/MoorDyn
IceF_DIR = $(FAST_DIR)/dependencies/IceFloe
IceD_DIR = $(FAST_DIR)/dependencies/IceDyn

TMD_DIR = $(SrvD_DIR)
DWM_DIR = $(AD_DIR)
HD_DIR_Reg = $(HD_DIR)
IfW_DIR_Reg = $(IfW_DIR)
BIN_DIR = …/bin

Names and locations of the Registry, MAP libraries, and instructions for linking with LAPACK.

You will probably need to change these for your system.

ifeq ($(OS),Windows_NT)
Registry = $(BIN_DIR)/Registry_win32.exe
MAP_lib = $(MAP_DIR)/MAP_x64.lib
LAPACK_LINK = -llapack -lblas -LC:/LAPACK/x64
#MAP_lib = $(MAP_DIR)/MAP_Win32.lib
#LAPACK_LINK = -llapack -lblas -LC:/LAPACK/win32
else
Registry = registry.exe
MAP_lib = $(MAP_DIR)/MAP.so
LAPACK_LINK = -llapack -lblas
endif

Name of compiler to use and flags to use.

FC = gfortran

FFLAGS = -g -O0 -fbacktrace -ffree-line-length-none -x f95-cpp-input -fcheck=all

LDFLAGS = -O2 -m$(BITS) -fbacktrace

Name of compiler to use and flags to use.

#FC = gfortran

#FFLAGS = -O2 -m$(BITS) -fbacktrace -ffree-line-length-none -x f95-cpp-input
#LDFLAGS = -O2 -m$(BITS) -fbacktrace -Wl,–stack=999999999,–large-address-aware

#FFLAGS = -O0 -m$(BITS) -fbacktrace -ffree-line-length-none -x f95-cpp-input -g -pg
#LDFLAGS = -O0 -m$(BITS) -fbacktrace -Wl,–stack=999999999,–large-address-aware -g -pg

#-DDOUBLE_PRECISION

-mthreads

some useful gfortran options:

-DFPE_TRAP_ENABLED

-Wl,–large-address-aware # not necessary when $(BITS) is 64 (64-bit target)

-Wl,–stack=999999999 # not necessary when $(BITS) is 64

-Wconversion-extra -Wconversion

-fdefault-real-8 -fcheck=bounds,do,mem,pointer -std=f2003 -O0 -v -Wall

-pg # generate debugging info for debugger

Option Index (The GNU Fortran Compiler)

makefile:

–warn-undefined-variables

Destination and RootName for executable

OUTPUT_NAME = FAST
DEST_DIR = …\bin[/code]

The 64 bit files libblas.dll, libblas.lib, liblapack.dll and liblapack.lib are in the folder “C:/LAPACK/x64” and my windwos search path points to this folder, too.

Thank you for your patience.

The message that “FAST_iwin64.exe was created” applies only to the Compile_FAST.bat script. There isn’t a message from the makefile. The absence of errors should indicate success.

It looks like it was successful–there will be an executable in the <FAST_v8>\bin folder. Based on what I see of your compiler, it should be called FAST_gwin64.exe.

Hi Bonnie,

thank you again! I work my way little by little ahead :slight_smile:

Now I get this:

Compilation_Error4.png

What can I do now?

Unfortunately, I have no idea why you would be getting a segmentation fault at that point in your code. The error means that you are accessing memory that you shouldn’t be. You could check if it’s something in your model (i.e., if you turn off different features, does it go away?) or try to compile with debugging information and see if that provides a better idea of where the problem is.

Hello,

I am trying to build FAST x64 (icl.cs.utk.edu/lapack-for-windows/lapack/ (as indicated in document Compiling FAST v8…) but I got the following error:

FASTLinkingError.PNG

I thought the binaries were maybe not suitable for my system, so I have also tried to compile them myself (I know this might not be the most optimized method but at least I want the build to finish). I followed the instructions from “Build Instructions for LAPACK 3.5.0 for Windows with Visual Studio” from the LAPACK for Windows page. It doesn’t work either:

FASTLinkingError2.PNG

Any ideas to solve this?

I think the “Skipping incompatible…” message is because the project is targeting a 64 bit build, but the makefile is pointing to 32 bit lapack/blas binaries. The good news is the linker finds lapack/blas libraries; it is just telling you it’s not compatible for your build.

Using pre-built libraries would be my first choice on Windows. I’d first make sure the downloaded pre-built lapack/blas is compatible with the number of bits you are targeting, then repeat the FAST building with the first approach.

Thank you Marco, that is a good suggestion but it was the first thing I checked. I am pointing to the x64 binaries as you can see in the images attached ("C:/LAPACKprecompile/x64) and yes, I downloaded them again from icl.cs.utk.edu/lapack-for-windows/lapack/ in case I saved them incorrectly.

I really don’t know what I am doing wrong.

Hi, Ana.

Do you have the .lib files in that directory? The error message says it’s skipping the .dll files, not the .lib files. gfortran can link with the .dll files only if they were generated with gfortran; otherwise it needs the .lib files.

Hello Bonnie,

Thank you for your feedback. Yes, I have both .dll and .lib in the same directory… I have also tried including that directory in Windows path but it doesn’t work either.

As I was stuck with the precompiled libraries, I tried compiling them again. Apparently I did something wrong the first time because I have finally managed to complete the build:

For those with the same problem, I followed the instruccions from “Build Instructions to create LAPACK and LAPACKE 3.5.0 dlls for Windows with MinGW” in icl.cs.utk.edu/lapack-for-windows/lapack/#build

Hello again,
I am now running some tests with my build before changing any source code in FAST. I have run Test01.fst both with my FAST executable (FAST_gwin64.exe) and the distributed one (FAST_x64.exe).
What I get is a SLOW simulation (awful time ratio):

instead of a FAST one:

I think the problem comes from the compiled libraries not being optimised. Therefore I would really like to make the build work with the precompiled libraries, any help out there?