Instructions for Compiling FAST

[Bonnie.Jonkman]

We frequently get asked questions about compiling FAST, so I have put together a set of instructions for compiling using Intel Visual Fortran (IVF) for Windows. You can access the pdf here:

http://wind.nrel.gov/public/bjonkman/De ... ctions.pdf

Please read this document carefully before posting compiling questions.

Thanks.

[Rebecca.Sykes]

Hi Bonnie,

To speed up batch processing I would like to have multiple FAST runs simultaneously on the same computer which has multiple cores. Are there any concerns associated with the storing of variables?

Also what are the implications of the required compiler settings specified in your report:

Because FAST v7.01.00a-bjj still has some unresolved issues relating to local variables and their initialization, you will also need to set Local Variable Storage to All Variables SAVE /Qsave, and set Initialize Local Saved Scalars to Zero to Yes (/Qzero). (Note that once we find and fix these issues, we will no longer compile with /Qsave and /Qzero.)

Thanks,
Rebecca

[Bonnie.Jonkman]

Rebecca,

You can run multiple copies of FAST simultaneously on the same computer without issue. The operating system takes care of issues associated with storing variables while running simultaneous simulations. (The only possible exception would be if you compiled FAST to call an external dll--like a controller--and then it would depend on the dll.)

The compiler settings I mentioned are mostly programming issues. It is sloppy programming not to initialize variables in the source code, and having to initialize all variables to zero (/Qzero) can result in doing unnecessary operations. Saving local variables between subroutine calls (or at least relying on the values between subroutine calls, which effectively makes the local variables act as global variables) makes it impossible to allow multiple instances running simultaneously within the same simulation (e.g., you try to model two turbines in the same simulation). Our codes need this capability to link with things like SOWFA. When people modify code, they should make sure they initialize their variables and don't rely on local variables retaining their values so that when we remove /Qzero and /Qsave, their code still works.

I hope that helps.

[Mark.Spring]

Having completed a small piece of new code (aerodynamic drag loads on the tower), I have had a frustrating time trying to compile FAST. Thanks for all your guidance (above and in the manual) and also the example DOS batch file. My problems may be compiler-specific, so I will declare the tools I am using:

1. Microsoft Visual Studio 2010 for windows (Version 10.0.30319.1 RTMRel) and
2. ifort from the DOS command line (Intel(R) Visual Fortran Compiler XE for applications running on IA-32, Version 13.0.0.089 Build 20120731)

Microsoft Visual Studio (Windows)
In order to solve various errors (of the form: #7002 Unresolved external symbol) I compiled the code in the *unchanged* form (i.e. the form distributed as FAST 7.01), modified the small number of files associated with my new code and then compiled those files only, one-by-one - the links with previously-compiled .MOD files were acceptable to the compiler which returned no errors. I still cannot get Microsoft Visual Studio to execute the code in debug mode (which would be useful).

ifort (DOS command line)
I have discovered the order in which the files are compiled is dictated by the order of the list passed to ifort (for instance NWTC_files or FAST_files in the NREL DOS batch). It was necessary to ensure that any SUBROUTINEs and FUNCTIONs referenced by my new SUBROUTINE were before the file containing the SUBROUTINE in the list and had successfully been compiled into a .MOD file before.

All SUBROUTINEs and FUNCTIONs are contained in a small number of modules (examples are AeroDyn, AeroSubs, FAST_Subs, FAST_IO_Subs). For new SUBROUTINEs or FUNCTIONs , it is therefore necessary to link to these MODULEs or to FUNCTIONs contained within them by USE statements (or USE, ONLY: statements).

[Bonnie.Jonkman]

Hi, Mark.

I'm not exactly if you are asking for help, but here are some comments:

USE statements create dependencies that you must follow when compiling the code. Any module that is specified in a USE statement must be compiled before it can be USE-associated in another part of the code. You have to watch out for circular dependencies (e.g., A subroutine in module A cannot use module B if module B USEs module A).

When you are using ifort (the DOS command line), you have to take care to specify the files in the correct order. Visual Studio *should* be smart enough to figure out the compile order by itself, but sometimes you may have to clean the solution first (i.e., delete all the intermediate files using Build -> Clean Solution).

Fortran does not require you to put subroutines in MODULES, but the code does typically run faster. You can alternatively specify an INTERFACE statement.

Can you explain what is happening when you try to "execute the code in debug mode?" It sounds like you have gotten it to compile.... Are you having trobule using the Visual Studio debugger?

[Mark.Spring]

Dear Bonnie,

Thanks for taking the time to read my post and to reply.

Your response confirms what I had discovered that from the DOS command prompts [i]the order matters[/i].

I am still unable to step into the source code in [i]debug[/i] mode. I have been trying to step into the code this morning with a colleague from the internal IT department, here at Lloyd's Register. I have been able to debug a small test program, written by my colleague, Alec Mackendrick. It's working smoothly without errors: all variables are visible in the Microsoft Visual Studio interface window. I have created a new project for compiling and debugging FAST. The structure is exactly as detailed in your "instructions for compiling FAST using IVF for Windows®". The files containing the source code are all unchanged from the files originally downloaded from the NWTC web site. The compiler appears to be missing a file called crt0.c This is not a file, explicitly included in the Microsoft Visual Studio project. It appears that it is not a generic file, which ships with Microsoft Visual Studio or the intel FORTRAN compiler. If it was, then Alec's test program would also have given the same error dialogue.

Do you know what crt.c is?

Kind Regards,

Mark

[Mark.Spring]

Do you know what crt0.c is?

[Marshall.Buhl]

Mark,

I don't know for sure what ct0.c is, but I suspect it is the C source code for crt0: http://en.wikipedia.org/wiki/Crt0

As for not being able to debug, please verify that you have selected Debug mode in VS. Have you set things correctly in the Debuging section of the FAST property pages (Project, FAST Properties...)? You need to specify the folder where the input file is in the Working Directory and the name of the input file in the Command Arguments field.


Marshall

[Neelabh.Gupta]

Hi,
I am using "Microsoft Visual Studio 2012" for compiling FAST (for interfacing it with GH Bladed style dll) using the instructions posted above. I am able to generate a FAST.exe with this, but when I try to use it for simulations it abruptly ends giving the error message as given below (in command prompt). Can anyone help me with this?

Snapshot of source files used

FAST_compilation.PNG (41.7 KiB) Viewed 31171 times

command prompt error

command_prompt_Error.PNG (30.59 KiB) Viewed 31171 times

Also, when I build the project using vs2012 it asks :' build solution for Intel static analysis' and 'build FAST_1 for Intel static analysis' (here FAST_1 is name of the project)
I am not sure which option should I use and if it is the correct way to approach. Sometimes the later option gives error, but I don't understand the reasoning.

I would really appreciate any help regarding this!

Thanks a lot in advance,
Neelabh

[Mark.Spring]

I am trying to compile FAST with Microsoft Visual Studio in "Debug" mode, but the compiler cannot find crt0.c

I select "continue" and it gets some way through the lines of code but always exits with the following error message. Any help would be very gratefully received. Many thanks.

'FAST_TowerWindLoad.exe': Loaded 'C:\wtg_sim\LRProjects\LRFAST\Branches\TowerWindLoad\cfg\Debug\FAST_TowerWindLoad.exe', Symbols loaded.
'FAST_TowerWindLoad.exe': Loaded 'C:\WINDOWS\system32\ntdll.dll', Cannot find or open the PDB file
'FAST_TowerWindLoad.exe': Loaded 'C:\WINDOWS\system32\kernel32.dll', Cannot find or open the PDB file
'FAST_TowerWindLoad.exe': Loaded 'C:\WINDOWS\system32\imagehlp.dll', Cannot find or open the PDB file
'FAST_TowerWindLoad.exe': Loaded 'C:\WINDOWS\system32\advapi32.dll', Cannot find or open the PDB file
'FAST_TowerWindLoad.exe': Loaded 'C:\WINDOWS\system32\rpcrt4.dll', Cannot find or open the PDB file
'FAST_TowerWindLoad.exe': Loaded 'C:\WINDOWS\system32\secur32.dll', Cannot find or open the PDB file
'FAST_TowerWindLoad.exe': Loaded 'C:\WINDOWS\system32\msvcrt.dll', Cannot find or open the PDB file
The program '[7700] FAST_TowerWindLoad.exe: Native' has exited with code 1 (0x1).


Kind Regards,

Mark Spring

[Marshall.Buhl]

Neelabh,

You compiled FAST to use a Bladed-style DLL for control. Did you create the DLL? Is it some place where it can be found by the operating system?


Marshall

[Marshall.Buhl]

Mark,

I'm afraid that crt0 is not our software, but is part of the compiler or OS. It should be in a library somewhere.

What OS are you running? What version of Visual Studio?


Marshall

[Mark.Spring]

Hi, Marshall,

Thanks for writing back. I suspected that the crt0.c was a system file. I investigated further with a colleague from our internal IT department (who originally installed the FORTRAN component for Microsoft Visual Studio). It seemed that the installation had been successfully completed. I have also tried searching online and cannot find a specific reference to this file being missing from anybody else's FORTRAN installation. As I have previously written, the compiler available from the DOS command prompt is quite happy to build an executable version of the code (ifort). Also Microsoft Visual Studio is quite happy to start debugging. It just seems to fall over when it tries to enter the source code for this crt0.c file. If possible, I would like to set options so that the debugger never tries to enter the lines of source code for a system file. The only files I am interested in letting the debugger enter are the FAST files!! I would be happy to skip over any other library files or included system subroutine files.

The operating system I am using is Windows XP (Build 2600.xpsp_sp3_gdr.120504-1619). The version of Microsoft Visual Studio is as follows (with all packaged add-ins).

Microsoft Visual Studio 2010 Team Explorer 01011-532-2002361-70647
Microsoft Visual Web Developer 2010 01011-532-2002316-70647
Intel (R) visual Fortran Package ID: w_fcompxe_2013.0.089
Microsoft Team Foundation Server 2010 Power Tools 10.0.41206.0
Microsoft Visual Studio Process Editor 1.0

Kind Regards,

Mark

[Neelabh.Gupta]

Neelabh,

You compiled FAST to use a Bladed-style DLL for control. Did you create the DLL? Is it some place where it can be found by the operating system?


Marshall

Thanks Marshall for a quick response.
I am using 'DISCON.dll' (torque and pitch control written by J.Jonkman') and its in the same location where my FAST_1.exe (generated after compilation), but it is for some reason not able to load it.:

DLL_error.PNG (30.04 KiB) Viewed 31157 times

Does it need to be created again? How, if that's the case?

Thanks again,
Neelabh

[Marshall.Buhl]

Mark,

You will not have a crt0.c on your computer. The compiler does not supply it, but supplies crt0.obj (or maybe crt0.o) only in binary form. It is optimized code, which means there is no debugging information in it (they want it to be fast). If a program bombs while executing that routine in debugging mode, it will leave you in that routine with no debugging information. This is as designed and not a problem. For people such as you an me, being in that routine is not very useful. However, the debugger allows you to set your focus anywhere in the call stack that can be found in one of the frames in your VS window. Clicking on a different routine in the stack will change the focus to it and you will be able to examine variables in that routine.


Marshall