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.
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:
Microsoft Visual Studio 2010 for windows (Version 10.0.30319.1 RTMRel) and
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).
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?
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 the order matters.
I am still unable to step into the source code in debug 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.
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.
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?
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!
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 ‘ FAST_TowerWindLoad.exe: Native’ has exited with code 1 (0x1).
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
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.:
Does it need to be created again? How, if that’s the case?
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.
Your discon.dll must be somewhere the OS can find it. Your screen shot did not show how you started FAST, so it’s hard for me to tell. If you somehow specify a path when you execute FAST, the OS may not find the DLL. For instance, if FAST.exe and DISCON.DLL are in C:\FAST and you execute FAST in the C:\MyModel folder by typing C:\FAST\FAST.exe, it will not be able to find the DLL. You have to have the DLL in your current directory when you execute FAST. However, it may be possible that having the C:\FAST folder is in your search path will work too, but I have not tested it.
If someone test it, please let us know if it works.
This is the path to my FAST_1.exe file and DISCON.dll. Both are in Ozan_run folder.
Just to be more clear about my previous post, I compiled FAST using Microsoft Visual Studio (as instructed in manual) and I didn’t use Compile_FAST.bat file anywhere. The manual mentions how to generate a FAST_dll using this Compile_FAST.bat file, but am not sure I have to do a similar thing when I use MS Visual Studio to compile FAST.
I got FAST_1.exe after compilation and I am using this for my simulations, when it gives this DISCON.dll error (could be loaded: in previous post)!
I would really appreciate a response on these lines as I want to compile recent version of FAST to get spanwise blade forces.
Just to be clear: you compiled with a 32-bit version of the compiler? People have had problems when they compiled with a 64-bit compiler and then tried to load a dll created with a 32-bit compiler. (If you got the DLL from Jason’s models on the web, it was compiled with a 32-bit compiler.)
I am trying to compile FAST(by command line with Compile_FAST) using Intel(R) Fortran Compiler for running applications on IA32, Version 10.0.025 build environment but compilation aborts with series of errors. The snap shot of errors is herewith. I will be thankful for feedback on errors and guidance to solve this problem.