Compiling FAST under Linux with gfortran

Wind & Water Computer-Aided Engineering Software Tools
1

Hi,

when I try to compile FAST under Linux (Ubuntu) with gfortran I get in SysGnu.f90 the following errors:

[code]$> gfortran -c SysGnu.f90
SysGnu.f90:509.116:
=‘UNKNOWN’, FORM=‘BINARY’ , ACCESS=‘SEQUENTIAL’, RECL=RecLen , IOSTAT=IOS )
Warning: FORM specifier in OPEN statement at (1) has invalid value ‘BINARY’

SysGnu.f90:550.90:
LE=TRIM( InFile ), STATUS=‘OLD’, FORM=‘BINARY’, IOSTAT=IOS, ACTION=‘READ’ )
Warning: FORM specifier in OPEN statement at (1) has invalid value ‘BINARY’

SysGnu.f90:617.46:
OPEN ( CU , FILE=‘CON’ , STATUS=‘UNKNOWN’ , CARRIAGECONTROL=‘FORTRAN’, RECL=
Error: Syntax error in OPEN statement at (1)

SysGnu.f90:332.46:
CALL GETARG ( Number, ReturnVal, CallStat )
Error: Too many arguments in call to ‘getarg’ at (1)

SysGnu.f90:280.41:
CALL GETARG ( 0, ReturnVal, CallStat )
Error: Too many arguments in call to ‘getarg’ at (1)

SysGnu.f90:286.41:
CALL GETARG ( IArg, Arg, CallStat )
Error: Too many arguments in call to ‘getarg’ at (1)

SysGnu.f90:216.39:
CALL GETARG ( Arg_Num, Arg, Status )
Error: Too many arguments in call to ‘getarg’ at (1)[/code]
I have read through the forum and found some people using gfortran with Windows. Has anyone adopted the SysGnu.f90 to Linux?

2

We have an updated version of SysGnu.f90 in NWTC Subroutine Library v1.04.00c-mlb. It’s an alpha version modified to run on Linux. I’m not sure the function to print over text on the screen works as it does in Windows, but it should compile.

Let us know if you have issues with it.

3

Thank you, Bonnie, with the alpha-version the SysGnu.f90 compiles fine. However I am running into another error:

[code]…/…/FAST/Source/HydroCalc.f90:812.29:

  CALL RANDOM_SEED ( PUT=WaveSeed(1:2) )
                         1

Error: Size of ‘put’ argument of ‘random_seed’ intrinsic at (1) too small (2/8)
[/code]

Any suggestions what’s going wrong here?

Felix

4

Felix,

We have found that Fortran’s intrinsic random number generator, RANDOM_SEED, does not have a standard number of seeds. HydroDyn assumes 2 seeds works to initialize it, but it looks like your compiler needs 8. Here is some code you can put in place of the line that is giving you an error.

[code]!bjj: gfortran needs 8 or 12 seeds, not just 2…
!bjj start of proposed change v1.00.00a-bjj
!rm CALL RANDOM_SEED ( PUT=WaveSeed(1:2) )
CALL RANDOM_SEED ( SIZE = nSeeds )

  IF ( nSeeds /= 2 ) THEN
     CALL ProgWarn( ' The random number generator in use differs from the original code provided by NREL. This pRNG uses ' &
                              //TRIM(Int2LStr(nSeeds))//' seeds instead of the 2 in the HydroDyn input file.')
  END IF

  ALLOCATE ( TmpWaveSeeds ( nSeeds ), STAT=Sttus)
  IF (Sttus/= 0 ) THEN
     CALL ProgAbort( ' Error allocating space for TmpWaveSeeds array.' )
     RETURN
  END IF   

     ! We'll just populate this with odd seeds = Seed(1) and even seeds = Seed(2)
  DO I = 1,nSeeds,2
     TmpWaveSeeds(I) = WaveSeed(1)
  END DO
  DO I = 2,nSeeds,2
     TmpWaveSeeds(I) = WaveSeed(2)
  END DO
                 
              
  CALL RANDOM_SEED ( PUT=TmpWaveSeeds )
  DEALLOCATE(TmpWaveSeeds, STAT=Sttus)
  IF (Sttus/= 0 ) THEN
     CALL ProgWarn( ' Error deallocating space for TmpWaveSeeds array.' )
  END IF

!bjj end of proposed change [/code]

It requires that you declare these variables at the top of SUBROUTINE InitWaves(), too:

!bjj start of proposed change v1.00.00a-bjj INTEGER :: nSeeds ! number of seeds required to initialize the intrinsic random number generator INTEGER, ALLOCATABLE :: TmpWaveSeeds (:) ! A temporary array used for portability. IVF/CVF use a random number generator initialized with 2 seeds; other platforms can use different implementations (e.g. gfortran needs 8 or 12 seeds) !bjj end of proposed change

5

Bonnie,

thank you very much for providing the code. With your changes I am now able to compile FAST with gfortran running under Linux.
I only had one problem with SysGnu.f90. All output of FAST was written to a file called CONOUT$. Therefore I removed the “Open”-Statement in SUBROUTINE OpenCon. With that modification fast is running, the only difference I see is, that for each output (“Timestep: 81 of 660s …”) a new line is printed instead of printing into the last line like with windows. But that’s ok for me.

Compared to windows and IFORT it is running slower.

Felix

6

Felix,

Thanks for the feedback. I just added your comments on our list of things to do in the NWTC Library. It is interesting that opening ‘CONOUT$’ in SUBROUTINE OpenCon() actually created a text file for you–we had originally added ‘CONOUT$’ so that it wouldn’t create a text file for us. We will have to look into that more, I guess.

If you want, you could also remove the lines in FAST_IO.f90’s SUBROUTINE SimStatus() where it calls the SUBROUTINE WrOvr(). It won’t display any of the “Timestep: x of 660s” lines, so it should run a little faster.

7

Hello, I’m trying to compile fast (current release) under fedora 16 64-bit with gfortran.
I compile the source files by this order one by one:

[b]NWTC subroutine library files:[/b]
	SingPrec.f90
	SysGnuLinux.f90 
	NWTC_IO.f90
	NWTC_Num.f90
	NWTC_Aero.f90
	ModMesh.f90
	NWTC_Library.f90

[b]AeroDyn wind inflow source files:[/b]
	SharedInflowDefs.f90
	HHWind.f90
	FFWind.f90
	HAWCWind.f90
	FDWind.f90
	CTWind.f90
	UserWind.f90
	InflowWindMod.f90

[b]AeroDyn source files:[/b]
	SharedTypes.f90 
	AeroMods.f90
	GenSubs.f90
	AeroSubs.f90
	AeroDyn.f90

[b]FAST source files:[/b]
	fftpack.f
	FFTMod.f90
	HydroCalc.f90
	FAST_Mods.f90
	Noise.f90
	FAST_IO.f90
	FAST.f90
	FAST_Lin.f90
	FAST2ADAMS.f90

When I get to FAST2ADAMS.f90 I get the following error:

	../../FAST/FAST/Source/FAST2ADAMS.f90:2375.131:

	T( TmpVec1,  te3(K,J,:) ), ', ', DOT_PRODUCT( TmpVec1, -te1(K,J,:) ), ', ', 
        	                                                                   1                                                        
	Error: Expected expression in WRITE statement at (1)
	../../FAST/FAST/Source/FAST2ADAMS.f90:2376.57:

                                              DOT_PRODUCT( TmpVec1, -te2(K,J,:)
                                                         1
	Error: 'dot_product' at (1) is not a variable
	../../FAST/FAST/Source/FAST2ADAMS.f90:2377.131:

	T( TmpVec2,  te3(K,J,:) ), ', ', DOT_PRODUCT( TmpVec2, -te1(K,J,:) ), ', ', 
        	                                                                   1                                                        
	Error: Expected expression in WRITE statement at (1)
	../../FAST/FAST/Source/FAST2ADAMS.f90:2378.57:

                                              DOT_PRODUCT( TmpVec2, -te2(K,J,:)
                                                         1
	Error: 'dot_product' at (1) is not a variable
	../../FAST/FAST/Source/FAST2ADAMS.f90:3987.132:

           IDCntrl_A(K)     , BldNodes, UnAD,  "IDCntrl_A"//TRIM(Int2LStr(K
                                                                           1                                                         
	Error: Syntax error in argument list at (1)
	gmake: *** [build/Debug/GNU-Linux-x86/_ext/1789009535/FAST2ADAMS.o] Error 1

Can anyone tell me how to overtake this error?

8

Dear Samuel,

I see that those lines all go past column 132, which is the maximum line length in the Fortran 2003 standard. Apparently, Intel doesn’t care, so it works with the IVF compiler we use for development. I see that someone noticed the problem, because the version under development does not have that problem. Please just edit those lines to ensure they do not go past column 132.

Marshall

9

Dear Marshall,

Thank you very much, it worked :slight_smile:

Samuel

10

We try to ensure source code doesn’t go past column 132, but we occasionally miss some lines. (It’s very hard to catch in IVF, given the number of comments that extend past that limit.)

You can also try compiling with the -ffree-line-length-none compiler option in gfortran, which should allow source code to extend past column 132.

11

Hello,

I ve been trying to compile FAST (v7.01.00a-bjj) under CENTOS 6.3 64-bit using AeroDyn (v13.00.01a-bjj) and the NWTC Subroutine Library (v1.04.01) with gfortran (4.4.6).

I have compiled and linked the source files as follows:

gfortran -ffree-line-length-none -c SingPrec.f90
gfortran -ffree-line-length-none -c SysGnu.f90
gfortran -ffree-line-length-none -c NWTC_IO.f90
gfortran -ffree-line-length-none -c NWTC_Num.f90
gfortran -ffree-line-length-none -c NWTC_Aero.f90
gfortran -ffree-line-length-none -c NWTC_Library.f90
gfortran -ffree-line-length-none -c SharedInflowDefs.f90
gfortran -ffree-line-length-none -c HHWind.f90
gfortran -ffree-line-length-none -c FFWind.f90
gfortran -ffree-line-length-none -c HAWCWind.f90
gfortran -ffree-line-length-none -c FDWind.f90
gfortran -ffree-line-length-none -c CTWind.f90
gfortran -ffree-line-length-none -c UserWind.f90
gfortran -ffree-line-length-none -c InflowWindMod.f90
gfortran -ffree-line-length-none -c SharedTypes.f90
gfortran -ffree-line-length-none -c AeroMods.f90
gfortran -ffree-line-length-none -c GenSubs.f90
gfortran -ffree-line-length-none -c AeroSubs.f90
gfortran -ffree-line-length-none -c AeroDyn.f90
gfortran -ffree-line-length-none -c fftpack.f
gfortran -ffree-line-length-none -c FFTMod.f90
gfortran -ffree-line-length-none -c HydroCalc.f90
gfortran -ffree-line-length-none -c FAST_Mods.f90
gfortran -ffree-line-length-none -c Noise.f90
gfortran -ffree-line-length-none -c FAST_IO.f90
gfortran -ffree-line-length-none -c FAST.f90
gfortran -ffree-line-length-none -c FAST_Lin.f90
gfortran -ffree-line-length-none -c FAST2ADAMS.f90
gfortran -ffree-line-length-none -c PitchCntrl_ACH.f90
gfortran -ffree-line-length-none -c UserSubs.f90
gfortran -ffree-line-length-none -c UserVSCont_KP.f90
gfortran -ffree-line-length-none -c AeroCalc.f90
gfortran -ffree-line-length-none -c SetVersion.f90
gfortran -ffree-line-length-none -c FAST_Prog.f90
gfortran -o fast.seq SingPrec.o SysGnu.o NWTC_IO.o NWTC_Num.o NWTC_Aero.o NWTC_Library.o SharedInflowDefs.o HHWind.o FFWind.o HAWCWind.o FDWind.o CTWind.o UserWind.o InflowWindMod.o SharedTypes.o AeroMods.o GenSubs.o AeroSubs.o AeroDyn.o fftpack.o FFTMod.o HydroCalc.o FAST_Mods.o Noise.o FAST_IO.o FAST.o FAST_Lin.o FAST2ADAMS.o PitchCntrl_ACH.o UserSubs.o UserVSCont_KP.o AeroCalc.o SetVersion.o FAST_Prog.o

When trying to run the program from the working directory including (for example) the files:

AWT_ADAMS.dat AWT_Blades.dat AWT_Linear.dat AWT_Tower.dat Test02_AD.ipt Test02.fst

with the command ./…/path_to_executable Test02.fst, I get a file called CONOUT$ which says:

Using NWTC Subroutine Library (v1.04.01, 21-Feb-2012).

Running FAST (v7.01.00a-bjj, 16-Feb-2012).

Heading of the FAST input file: FAST certification Test #02: AWT-27CR2 with many DOFs with
startup and shutdown and steady wind.
+^G
The input file, “.\AWT_Tower.dat”, was not found.

Aborting FAST.

Any suggestions about what s going wrong here?

Many thanks for your help,

Marco

12

Marco,

Do you have a file called AWT_Tower.dat in the current directory for your terminal?

Marshall

13

Dear Marshall,

Thanks for your reply. In my working directory I have collected the following files:

  • AWT_ADAMS.dat
  • AWT_Blades.dat
  • AWT_Linear.dat
  • AWT_Tower.dat
  • Test02_AD.ipt
  • Test02.fst

which were copied from the CertTest directory in the FAST archive. Then, from my working directory, I run the program as follows:

./…/path_to_executable Test02.fst

Is this the correct way to run it?

Marco

14

Dear all,

I solved the problem by replacing the line

PathName = ‘.’//PathSep

in the subroutine GetPath contained in NWTC_IO.f90, with the following line:

PathName = ‘’

Regards,

Marco

15

Marco,

I’m glad you figured out a solution. An alternative solution is to change the PathSep variable at the top of your SysGnu.f90 file to be “/” instead of "".

Older versions of the NWTC Library have a single SysGnu.f90 file, which has some variables (like PathSep) set for Windows. We’ve now separated the file into SysGnuLinux.f90 and SysGunWin.f90

16

Bonnie,

Thank you.

From your answer I assume that I am working with a code in which there are many variables (including PathSep) set for Windows. I could identify PathSep just because the code couldn t even start. Now, I wondering if the other variables might affect somehow my calculations.

Could be “safe” using the old Library version (v1.04.01) just replacing the file SysGnu.f90 with the new SysGnuLinux.f90?

17

I don’t know about there being “many” changes for Windows vs. Linux, but there are some… like some of the functions that write to the screen. It shouldn’t affect any of your calculations, though.

You can certainly try to replace SysGnu.f90 with SysGnuLinux.f90. I briefly looked at the change log, and I can’t think of any reason that it wouldn’t work (though I could be wrong) :slight_smile:

18

Hello!

I am trying to compile the FAST (v7.01.00a-bjj) under Ubuntu 16.04 LTS with gfortran (5.4.0) using AeroDyn (v13.00.01a-bjj) and the NWTC Subroutine Library (v1.04.01). I have used the same method that Marco.Caboni did. I think the compiling of the fortran files went through well. However, the liking process printed some error message as below:

FAST.o: In function `__fastsubs_MOD_drvtrtrq': FAST.f90:(.text+0x3e46b): undefined reference to `uservscont_' FAST.f90:(.text+0x3e601): undefined reference to `userhssbr_' FAST.o: In function `__fastsubs_MOD_control': FAST.f90:(.text+0x3ea54): undefined reference to `useryawcont_' UserVSCont_KP.o: In function `usergen_': UserVSCont_KP.f90:(.text+0x5c): undefined reference to `uservscont_' collect2: error: ld returned 1 exit status

If anyone has solution to solve this problem, please help me to solve it.

Thank you.

Jin Woo Lee