LINKING APPLICATION ABORTED - FASTv8 / Simulink

[hbasbas]

Bug description
I am trying to run FASTv8 on a real-time target (dSPACE1006). It consists of differents steps of a building process : (1) compiling the Simulink model, (2) Linking the application and (3) load the code in the dSPACE.

Here is my error message :
_----------------------------------------------------------------------
Starting build procedure with RTI 7.1 (RTI1006, 02-Nov-2013)
Model: "OpenLoop" (D:\HIL_Hedi\2019\FAST\HediFiles\FASTv8\Simulink\Samples\OpenLoop.mdl)

*** Using configuration set : "Configuration"
*** Working directory : "D:\HIL_Hedi\2019\FAST\HediFiles\FASTv8\Simulink\Samples"
*** Initializing code generation

Starting Simulink Coder build procedure for model: OpenLoop

Generating code into build folder: D:\HIL_Hedi\2019\FAST\HediFiles\FASTv8\Simulink\Samples\OpenLoop_rti1006

---

FAST (v8.16.00a-bjj, 27-Jul-2016)

Copyright (C) 2016 National Renewable Energy Laboratory

This program comes with ABSOLUTELY NO WARRANTY. See the "license.txt" file distributed with this
software for details.

---

Running FAST (v8.16.00a-bjj, 27-Jul-2016), compiled as a DLL S-Function for Simulink as a 32-bit
application using single precision
linked with NWTC Subroutine Library (v2.09.00, 23-Jul-2016)

Heading of the FAST input file:
FAST Certification Test #24: NREL 5.0 MW Baseline Wind Turbine with OC3 Hywind Configuration,
for use in offshore analysis

Running ElastoDyn (v1.04.00a-bjj, 26-Jul-2016).

Running AeroDyn (v15.03.00, 27-Jul-2016).

Running AirfoilInfo (v1.01.00a-bjj, 5-Apr-2016).

Running BEM (v1.02.00, 29-Jun-2016).
Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0. BladeNode = 1, Blade = 1
Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0. BladeNode = 2, Blade = 1
Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0. BladeNode = 3, Blade = 1
Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0. BladeNode = 4, Blade = 1
Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0. BladeNode = 1, Blade = 2
Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0. BladeNode = 2, Blade = 2
Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0. BladeNode = 3, Blade = 2
Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0. BladeNode = 4, Blade = 2
Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0. BladeNode = 1, Blade = 3
Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0. BladeNode = 2, Blade = 3
Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0. BladeNode = 3, Blade = 3
Warning: Turning off Unsteady Aerodynamics because C_nalpha is 0. BladeNode = 4, Blade = 3

Running InflowWind (v3.03.00, 26-Jul-2016).
Opening InflowWind input file:
....\CertTest\5MW_Baseline/NRELOffshrBsline5MW_InflowWind_12mps.dat

Reading a 31x31 grid (145 m wide, 17.5 m to 162.5 m above ground) with a characteristic wind
speed of 12 m/s. This full-field file was generated by TurbSim (v1.06.00, 21-Sep-2012) on
07-Jan-2014 at 12:50:45.

Processed 1442 time steps of 20-Hz full-field data (72.05 seconds).

Running ServoDyn (v1.06.00a-bjj, 26-Jul-2016).

Running ServoDyn Interface for Bladed Controllers (using Intel Visual Fortran for
Windows/Matlab, 14-Oct-2015).

Running HydroDyn (v2.05.01, 27-Jul-2016).
Generating incident wave kinematics and current time history.
Reading in WAMIT output with root name "....\CertTest\5MW_Baseline/HydroData/Spar".
Computing radiation impulse response functions and wave diffraction forces.

FAST_InitializeAll:SrvD_Init:ValidatePrimaryData:Yaw angle and rate are not commanded from Simulink model.
ValidatePrimaryData:Pitch angles are not commanded from Simulink model.
ValidatePrimaryData:Generator torque and power are not commanded from Simulink model.
ValidatePrimaryData:HSS brake is not commanded from Simulink model.
Timestep: 0 of 60 seconds.

FAST completed.

*** INFO: For use with RTI the recommended setting of the option
"Software environment/Target function library" is C89/C90 (ANSI).
Current setting is C99 (ISO).
*** Optional User System Description File openloop_usr.sdf not available

Invoking Target Language Compiler on OpenLoop.rtw

Using System Target File: C:\Program Files (x86)\dSPACE RCPHIL 2013-B\MATLAB\RTI\RTI1006\TLC\rti1006.tlc

.

Loading TLC function libraries

.....

Initial pass through model to cache user defined code

..
*** Postprocessing RTI blocks
*** Starting I/O block checking
*** Passed I/O block checking

Caching model source code

.....................................

Writing header file OpenLoop.h

.

Writing header file OpenLoop_types.h

Writing source file OpenLoop.c

Writing header file rtwtypes.h

.

Writing header file OpenLoop_private.h

Writing header file rtmodel.h

Writing source file OpenLoop_data.c

.

Writing header file rt_nonfinite.h

Writing source file rt_nonfinite.c

Writing header file rt_defines.h

.

Writing header file rtGetInf.h

Writing source file rtGetInf.c

Writing header file rtGetNaN.h

.

Writing source file rtGetNaN.c

TLC code generation complete.

Generating TLC interface API.

........
*** Generating file OpenLoop_rti.c
*** Generating file OpenLoop_rti.mk
*** Generating Variable Description File OpenLoop.trc

---

NOTE: The following option in the Configuration Parameters dialog has been
used:

  Optimization:
  "Conditional input branch execution" On

  This leads to code optimization in which blocks are not computed if their
  outputs are not required in the simulation step, for example, if their
  output values are used as input for a Switch block and the Switch
  currently routes another signal. When the corresponding output signals
  are displayed in ControlDesk, their values are static.

  To ensure that the blocks are computed, turn off the 
  "Conditional input branch execution" option and rebuild the model.

---

---

NOTE: The following options in the Configuration Parameters dialog have been used:

  Optimization:
  "Signal storage reuse"  on
  "Reuse block outputs"   on

  As a consequence, in general no block output variables are written to the
  -> OpenLoop.trc
  file and are therefore not accessible from within ControlDesk.

  You can ensure that a specific block output is accessible by declaring
  its Simulink signal as a test point. To do so, select the signal line and
  choose "Signal properties..." from the Edit menu. In the Signal Properties
  dialog, select the "Test point" option.

---

..
*** Found User-Code File OpenLoop_usr.c from 14-janv.-2021 11:24:00
*** Found User Makefile OpenLoop_usr.mk from 14-janv.-2021 11:24:00
*** Optional User Variable Description File OpenLoop_usr.trc not available
.

Processing Template Makefile: C:\Program Files (x86)\dSPACE RCPHIL 2013-B\MATLAB\RTI\RTI1006\RTI\rti1006.tmf

OpenLoop.mk which is generated from C:\Program Files (x86)\dSPACE RCPHIL 2013-B\MATLAB\RTI\RTI1006\RTI\rti1006.tmf is up to date

Building OpenLoop: dsmake -f OpenLoop.mk GENERATE_REPORT=0 EXTMODE_STATIC_ALLOC=0 TMW_EXTMODE_TESTING=0 EXTMODE_STATIC_ALLOC_SIZE=1000000 EXTMODE_TRANSPORT=0 MAT_FILE=0 NCLIENT="OPTION_DISABLED"

BUILDING APPLICATION "OpenLoop" (Single Timer Task Mode)

WORK DIRECTORY "D:\HIL_Hedi\2019\FAST\HediFiles\FASTv8\Simulink\Samples"
BUILD DIRECTORY "D:\HIL_Hedi\2019\FAST\HediFiles\FASTv8\Simulink\Samples\OpenLoop_rti1006"
TARGET COMPILER "C:\Program Files (x86)\dSPACE RCPHIL 2013-B\Compiler\x86Tools" (DS1006 Compiler Vs 2.3, GCC Vs 3.3.5)

COMPILING "OpenLoop.c"
COMPILING "OpenLoop_data.c"
COMPILING "OpenLoop_trc_ptr.c"
COMPILING "rtGetInf.c"
COMPILING "rtGetNaN.c"
COMPILING "rt_nonfinite.c"
COMPILING "C:\Program Files (x86)\dSPACE RCPHIL 2013-B\MATLAB\RTI\RTI\C\rti_sim_engine.c"

LINKING APPLICATION ...
..\OpenLoop.x86: In function mdlTerminate': ..\OpenLoop.x86(.text+0x8d): undefined reference to FAST_End'
..\OpenLoop.x86: In function mdlInitializeSizes': ..\OpenLoop.x86(.text+0x273): undefined reference to FAST_Sizes'
..\OpenLoop.x86: In function mdlStart': ..\OpenLoop.x86(.text+0x4e8): undefined reference to FAST_Start'
..\OpenLoop.x86: In function mdlOutputs': ..\OpenLoop.x86(.text+0x610): undefined reference to FAST_Start'
..\OpenLoop.x86: In function mdlUpdate': ..\OpenLoop.x86(.text+0x700): undefined reference to FAST_Update'
-- call "C:\Program Files (x86)\dSPACE RCPHIL 2013-B\Compiler\x86Tools\BIN\x86-ld.exe" -T "C:\Program Files (x86)\dSPACE RCPHIL 2013-B\DS1006\RTLib\extsym1006.lk" -o NUL ..\OpenLoop.x86
LINKING FAILED (2)(1)

MAKE PROCESS ABORTED

---

*** Errors occurred during make process.
*** Inspect MATLAB Command Window for details.
*** Aborting RTI build procedure for model OpenLoop.

*** Stopped RTI build procedure for model: OpenLoop._

End of the error message
It seems that it cannot find the FAST_End and ohters functions. By checking with "Dependency Walker", the mex32 (because I am using a 32bits versions of MatlabR2012b connecter to the 32bits dSPACE) the functions are well included in the mex file.

Does someone has an idea please ?

Best regards,

[jjonkman]

Dear @hbasbas,

I have no experience compiling FAST / OpenFAST for real-time applications. A similar question was asked on our forum, but I'm not sure if anyone has solved it yet: https://wind.nrel.gov/forum/wind/viewtopic.php?f=4&t=2403&p=13761.

I've eliminated the "bug" label because this feature has never been supported.

Best regards,

[hbasbas]

Dear @jjonkman

I saw the post of Cheng Zhang but it is not exactly the same thing : he has variable conflict which gives problem for the compilation stage. I had his errors which can be easily fix by using the RT libraries of matlab insteaf of the common ones. However, my problem is in the linking step which use the GNU linker command (x86-ld.exe). It cannot find the function "FAST_XX" which are normaly include in the mex32 file, the FAST_Library_Win32.dll and FAST_Library_Win32.lib right ?
I am not sure to understand what the linker should find : a dll file, lib file or it searchs in the mex32 file ?

[bjonkman]

Not sure I can give you much help, but it looks like the linking command for OpenLoop.x86 is not finding the definitions of the FAST_Library.f90 routines. These routines are actually part of the FAST_Library*.dll that is called from the mex function. Did you build the FAST_Library_Win32.dll with the same compiler you are using for the mex file (gcc I assume)? Can you add the FAST_Library_Win32.lib file to the linking command? (gcc might also be able to link with the DLL directly instead of the .lib file)

[hbasbas]

Thank you for your answer @bjonkman !
I also think that it is a problem of compilation since the linking command is well performed (I think). It includes the good libraries in the command but it still cannot find the FAST function.

Thank you for this advice ; in fact, I compiled the FAST_Library_Win32.dll in Visual Studio 2019 with Intel Fortran Compiler downloaded with the "Intel Parallel Studio XE 2020" package. While the mex file is compiled with Microsoft Software Development Kit (SDK) 7.1 in C:\Program Files (x86)\Microsoft Visual Studio 10.0. I also tried to make the mex file with this compiler : Microsoft Visual C++ 2010 in C:\Program Files (x86)\Microsoft Visual Studio 10.0 but I have the same problem. I have a third choice for the mex file: the Lcc-win32 C 2.4.1 in C:\PROGRA2\Matlab\R2012b\sys\lcc which cannot make the mex file due to this error : "_unrecognized option -STACK:999999999 C:\PROGRA2\MATLAB\R2012B\BIN\MEX.PL: Error: Link of '..\Samples\FAST_SFunc.mexw32' failed_"

So you suggest me to use the GCC 3.3.5 compiler to create the "FAST_Library_Win32.dll" library and to create the mex file also ? Is the version (3.3.5) of the compiler is important or simply the type of compiler ? And how compile Fastv8 with gcc, I think it is not possible with Visual Studio ?!

For your last question : I tried to include the lib file in the linking command but it still does not work as I wrote at the beginning of my message ...

[bjonkman]

If you try to build with static libraries, you will need to make sure the compilers for Fortran and C/C++ that you use are compatible. If you are NOT building with static libraries, then theoretically it should not matter as long as you are using the same calling conventions (you should check that, too). However, it might be easier to use compatible compilers just to take away another layer of potential problems.

Compatible compilers:

• Intel Fortran with Intel C/C++ (same Intel versions)
• Intel Fortran with Visual Studio C/C++ (Visual Studio version that is integrated with Intel Fortran)
• gfortran with gcc (same gcc versions)

There is probably a make file in the FAST8 archive that you can modify to help you with building the FAST library with gfortran/gcc (you are correct that you can't use Visual Studio to build with gcc).

I personally do not recommend using the LCC compiler that comes with Matlab.

[hbasbas]

@bjonkman thank you for the precisions

As the real-time target use this compiler : gcc 3.3.5, I will remake the compilation but this time with gfortran to create the libraries. However, it is mentionned in the "CompilingInstruction_FASTv8.pdf" that the gcc compiler must be at least version 4.6.1 while my target will use the 3.3.5 version. Is it possible that this difference of version produces conflicts during the compilation or the linking process ?

Another question : is there some recommendation for mex compilers expect that you do not recommend the LCC one ?

[hbasbas]

@bjonkman I tried your instructions :

I have the GNU Fortran compiler version 9.2.0

1. I use the make file given when downloading FASTv8
2. I modify FAST_driver to FAST_Library to get the library file
3. I have to modify the FFLAGS to avoid memory error during the compilation : FFLAGS = -O0 -m$(BITS) -fbacktrace -ffree-line-length-none -x f95-cpp-input -DDOUBLE_PRECISION -fdefault-real-8 -g
4. The compilation completed, I obtain a DLL file : FAST_Library_gwin32.dll.

However, the mex command need a .lib file, right ? How could I modify the makefile to obtain a .lib file instead of the DLL ?

Also, for the mex command you told me that I must use a gcc compiler which are not supported by my MATLAB version (R2012a). Thus, I use gnumex to allow gcc compiler in Matlab but Maltab does not certified it : http://gnumex.sourceforge.net/
Maybe you have some recommandations for this ?

[bjonkman]

I'm not sure you can have gcc build both the .dll and an associated .lib file at the same time, but you can specify the .dll it generated on the mex link command instead of using the .lib file there.

I don't know anything about gnumex.

[hbasbas]

Ok thank you @bjonkman

With all your recommendations, I think I understand the problem. It seems to be at the beginning with FAST_Library.f90 where these lines are defined :

#ifndef IMPLICIT_DLLEXPORT
!GCC$ ATTRIBUTES DLLEXPORT :: FAST_Sizes
#endif

Maybe when compiling with Intel Fortran with Visual Studio, these lines are not taken into account, thus these functions are not export for gcc ?

[bjonkman]

If you haven't defined IMPLICIT_DLLEXPORT in your build, you should be fine. Those lines were added because linux-based machines don't like the DLLEXPORT attribute (they implicitly export the symbols for the subroutines defined in the DLL). On Windows, you typically need to specify which subroutines are going to be available to call. The !GCC$ tells the gcc compiler to use those lines, otherwise it is a comment. Likewise, there should be a !DEC$ line where DLLEXPORT is defined for the Intel compiler (and considered a comment line for all other compilers).

My version of the OpenFAST code has it defined like this:

#ifndef IMPLICIT_DLLEXPORT
!DEC$ ATTRIBUTES DLLEXPORT :: FAST_Sizes
!GCC$ ATTRIBUTES DLLEXPORT :: FAST_Sizes
#endif

If you open the DLL you created using Dependency Walker, it should list all the subroutines were built with that DLLEXPORT attribute.

[hbasbas]

Thank you @bjonkman for the guidelines. I completed the compilation using gfortran. However, I am facing a problem with the mex command : it needs a .lib file ... However the given makefile produce only .exe or .dll file and the mex file cannot be built with dll file. Is there a solution to produce both .dll and .lib as Visual Studio/Intel Fortran ?

[Domotopeng]

Hello, everyone!
I have some problems while running "Run_Test01_SIG.m".
I used the latest version of openfast v2.5.0, and successfully compiled "FAST_SFunc.mexw64" with matlab2020a and visual studio 2019, but when I run "Run_Test01_SIG.m", matlab is crashing. I have tried many times and still can't solve this problem.
Attached is the crash report of matlab2020a and the results of Create_FAST_SFunc.

Best wishes!
ChenPeng

Picture Translation: cl: Command line warning D9025 :rewriting "/MD" (with "/MT")
MEX has been successfully completed

issue.txt

[bjonkman]

@hbasbas: I think you can change the libName variable to include the .dll part of the library name generated with gfortran. So, use something like libName = 'openfastlib.dll' and see if that works.

@Domotopeng:
The compiling warning you mention is normal. Matlab internally wants to use dynamic libraries (/MD), but we tell it to build with static libraries (MT), so it warns that it was specified twice and is going to use the last specification.

Can you check that your OpenFAST model runs outside of Simulink? You could also try to use the dev branch of OpenFAST instead of v2.5.0 to see if that fixes the problem.

[hbasbas]

@bjonkman I tested your command and I obtained this error :

MEX cannot find library 'FAST_Library_x64.dll', specified with the -l option.
MEX searched for a file with one of the following names:
libFAST_Library_x64.dll.a
FAST_Library_x64.dll.lib
libFAST_Library_x64.dll.lib

So it does not work ...

[bjonkman]

Perhaps instead of using the -l option, you can just add the dll at the end of the linking line? You'd have to remove the ['-l' libName], ... line and then change the last line from

'FAST_SFunc.c');

to

'FAST_SFunc.c FAST_Library_x64.dll');

I have built code where I linked with the .dll instead of the .lib file from gcc, but I don't remember the exact syntax, so you might need to play around with the arguments and their order with this mex command.

[hbasbas]

@bjonkman I tried many differents writtings for the mex command and I obtained this error message :

_>> create_FAST_SFunc

C:\PROGRA~2\MATLAB\R2012B\BIN\MEX.PL: Error: mex cannot link to 'FAST_Library_gwin32.dll' directly.
Instead, you must link to the file 'FAST_Library_gwin32.lib' which corresponds to 'FAST_Library_gwin32.dll'.

Error using mex (line 206)
Unable to complete successfully._

It seems that we obligatory need the lib file for mex, right ?

[bjonkman]

I'm not sure I can give you any more help on this. I would suggest that you try to build a test driver in C that calls the FAST_Library dll, and after you get that to work outside of Matlab, go back and try it in the mex process.

[hbasbas]

@bjonkman Ok thank you.

And I saw that, it can be possible to create a lib file by creating a def file with gfortran and then a lib file with another tools ?
Do you think it is possible ? With this, I could make the mex file ..

[hbasbas]

Dear @bjonkman, I am coming back with my dSPACE implementation.

It seems possible to do it in this link : https://docs.acados.org/embedded_workflow/index.html#prerequisites

It is for another open-source code (acados) but maybe we could use the same process using CMake ? Is there a simple way to make it with the code already written for CMake ?

Best regards,

[hbasbas]

Dear @bjonkman,

Concerning the implementation of Openfast on a dspace target, it seems possible to do it based on this Matlab forum: https://fr.mathworks.com/matlabcentral/answers/788544-fatal-error-lnk1112-in-simulink-real-time-with-s-function?s_tid=prof_contriblnk

If I understand well, we should add in the linking process some libraries from the Intel Compiler C++ installation folder ?

Best regards