Hi all,
I want to exploit every feature of FAST code, so I’m at that point where I want to take advantage of the WTG controller developed for Bladed.
I have my environment set up to compile FAST with G95 compiler (see my old posts on this forum), everything seems to build fine as usual except that it complains about module kernel32
used by the BladeDLLInterface on line 71
USE kernel32
Could you spread some light on that because I’ve no clue? Is that kernel32 supposed to be “the” system library? Do I have to link some system’s .dll?
Thanks in advance.
Stefano
Dear Stefano,
Kernel32 referes to the Kernel32.lib (static library) file that is supplied with compilers to aid developers in writing code that can access basic Windows 32 API functionality. Kernel32.lib comes with the Microsoft Visual Studio GUI that we use with the Compaq Visual Fortran and Intel Visual Fortran compilers. It also comes with e.g. MATLAB so that you can compile your own mex functions that can be integrated within MATLAB.
Does the G95 compiler not come with a Kernel32.lib file? If not, than you may not be able to use the BladedDLLInterface.f90 file as is. Instead, you will have to strip out MODULE DLL_Interface from the BladedDLLinterface.f90 file and replace it with a direct interface to the Bladed-style DLL. This will require that you have a DISCON.lib file before compiling FAST. FAST v6.00 actually functioned this way (not needing Kernel32.lib); you can access this old version here : wind.nrel.gov/designcodes/simula … T_v600.exe. However, the use of Kernel32.lib makes it far easier to link FAST to Bladed-style DLLs.
Best regards,
Hi Jason,
back on the subject after a while… what you said is perfectly clear!
we can statically link at compile time with discon.lib but I don’t really like it. not flexible at all (btw, I found on the NREL public folder the BladedDLLInterface4Linux.f90 … and can you confirm the statical linking is what the guy from CENER does?)
At the time I’m still investigating FAST compiling on free fortran compilers on Win but I moved to gfortran (before I compiled with g95 which development seems interrupted) …I’m working on FAST 7 and newer … while I’m good with standard exe and SFunc I’m still having problem with the BladedDLL for which I’m trying to use ISO_C_BINDING module… that should provide an interface to kernel32 LoadLibrary and GetProcAddress as the kernel32.lib on IVF does
As soon as I find a solution I will post here files, makefile (already have a cleaner solution than the one posted before) and findings
Cheers,
Stefano
Stefano,
Jason is on paternity leave for the rest of the month and Bonnie will be out even longer. I’m afraid I do not know the answer to your question. I haven’t compiled FAST in many years, so I can’t help you.
If someone else out there has worked with compiling FAST and the DLLs, please feel free to speak up.
Marshall
Dear Marshall,
congratulations to Jason and Bonnie. Probably I’ve found a way 
…I’ve to test a couple of things. I’ll let you know as soon as possible.
Cheers,
Ste
Dear Stefano,
Thanks for the congratulations. We are having fun adjusting to our new way of life .
You are correct–everyone I know who uses the GH Bladed-style controllers in FAST on Linux, uses statically linked libraries.
Best regards,
Hi,
I’m going on with DLL related work in FAST. I partially implemented part of the work as per this previous post
[url]FAST feature request]
After the test of various combination of OS/compilers/prog-languages actually I’m quite satisfied with following (peculiar is that is free)
- Linux OS (Fedora distro)
- Intel FORTRAN Compiler for Linux
- custom BladedDLLInterface …( the external library could be C or FORTRAN, actually C cause I’m more proficient with it)
- “very” custom FAST build, this allow for:
- custom DLL,procedure specified in the primary input file and not hard-code at compile-time)
- real-time simulation with external hardware-in-the-loop (if required external condition are met, as speed of the overall system/communication )
I added an option to “slow down” sim to stick to real-time, if somehow the sim is already slower or near real time thi feature is unusable
PS: differently from CENER I link and load dinamically also on Linux
TODO
- feed aerodyn with a real wind coming from external controller (will be hh wind of course)… this is really interesting for me! is this possible? I’m studing the aerodyn interface
- as usual, explain a little better with a blog article on my page
- turn code OS/Compiler independent (that thing about ISO_C_BINDING I mentioned before) !!!
all these things basically allow me to use FAST-RT (as I refer to for distinguish from normal FAST) as a simulator for real turbine controller… trying to emulate what Bladed does
maybe I’m missing something else I did in the development process… but as a philosophy I tryed to change the minimum in the original code
maybe someone else is interested and maybe the features can be implemented in a future release… when the time come
cheers, as usual
ste
Dear Stefano,
Thanks for the update.
We do plan to make the Bladed DLL Interface a built-in option in a future release of FAST (instead of a user-defined option as it currently is now) .
We are also developing a real-time version of FAST by interfacing it to LabView.
The “hub-height” file option is often used to feed measured wind data (from an anemometer) into AeroDyn. But because the hub-height file assumes uniform (or sheared) flow over the rotor disk, this approach may not be adequete for the modeling of large utility-scale wind turbines.
Best regards,
Hi,
I would like to share the code for BladedInterface I came up with.
You will find it for download at [url]http://www.stefanocottafavi.com/?p=360[/url]
The file is a zip with two .f90; they allow for dynamic linking of a control routine both on linux and win. They also should be cross-compiler at least for the latest FORTRAN compilers that support ISO_C_BINDING (tested with ifort on linux, gfortran on both linux and win)
Feel free to ask if you have any doubt.
That’s great, Stefano! Thank you for being so generous.
Marshall