Issue when I run simulink model which depends on openfast S-Function mex

[JoaquinPerCarr]

Hi everyone,

I'm trying to run a Simulink model after run other .m which has specific variables for the Simulink model. After few attempts I can't find the way to run that without crashing.

My machine's characteristics are in file 'Issue 1' that I attach, and the crashes are in issue 1 and 2. All OpenFAST files are in C:/, including the files referred to .m and simulink models, that I need to run the simulations properly. Moreover, for give you more extra information, all the OpenFAST files are in Matlab path.

Issue1.txt
Issue2.txt

For confidential issues I can't attach the simulink model but I hope you could help me because I can't follow doing my final project at university.

Best regards,

Joaquín

[bjonkman]

I'm a little confused by the traceback stack. It looks like the problem happens in routine FAST_OpFM_Init but I am not sure why the OpenFAST-Simulink interface would be in that routine at all. As far as I know, that routine should only be called with the interface of OpenFAST with a CFD code (not Simulink).

1. Which version of OpenFAST are you using?
2. Did you build the mex library and OpenFAST-Simulink DLL (if so, how?), or are you using precompiled binaries?
3. Did you modify the source code or build scripts before building?
4. Do the example OpenFAST Simulink models run without crashing?

[JoaquinPerCarr]

1 - I don't know how I can see that but I think I'm using 1.0.0
2- Yes I built the mex library. First I use Visual Studio 2015 and compiling the file Simulink-Openfast with the options Release_Matlab and x64 option. The name of the resultant file is OpenFAST-Simulink_x64(I attach an image), and I can find it in build/bin.
To obtain fast solution I use the same program too.

3- I don't touch the mex file, I only modify the .m for load to the workspace the variables and after I execute the simulink model (both are on the same location as predeterminated models [C:\Users\CASA\Documents\code\openfast\glue-codes\simulink\examples, and .m that generates S-function in build/bin you can find it in .....openfast\glue-codes\simulink\src])
4- No, it don't

[bjonkman]

1. If you are actually on v1.0.0, you should definitely upgrade to the latest version of OpenFAST (master branch). However, I'd be surprised if v1.0.0 had the Release_Matlab option, so I'm guessing it is a different version. You should be able to see the version number in a file called <openfast>\vs-build\gitVersionInfo.h. Or, you can see it printed on the screen when you run OpenFAST.

2. What you describe is building the OpenFAST_Simulink_x64.DLL file. The mex file is typically built using openfast\glue-codes\simulink\src\create_FAST_SFunc.m. Did you also build this? On your system it should create FAST_SFunc.mex64. Given the modification date of FAST_SFunc on your screen shot, I would assume you also built this, but I am just double-checking that it didn't come from another OpenFAST build.

I would work on getting the example OpenLoop model to work with one of the OpenFAST r-test cases before trying to debug what is going on with your particular Simulink model. That way you can share all the details of what you are doing.

Make sure you built the FAST_SFunc with the same compiler that you used when building OpenFAST-Simulink_x64.DLL (i.e., run mex -setup in Matlab and make it use Visual Studio C/C++ and Intel Fortran).

[JoaquinPerCarr]

Hello @bjonkman,

1. Sorry for the version info, I check that and it is V2.3.0 ---> #define GIT_VERSION_INFO 'v2.3.0-548-g43191a90'

2 - Yes, I execute create_FAST_SFunc.m and I obtain FAST_SFunc.mex64 in build/bin.

To show you all the steps I did, I'm going to attach some screenshots:

First, I execute mex -setup to confirm that I use the same compiler---Visual Studio 2015. This is correct.
Next step is generate S-Function running create_FAST_SFunc.m and I obtain FAST_SFunc.mex64.

Next step is running Run_OpenLoop.m:

You can see that Matlab has a problem in this step and It needs to close in that moment.

Best regards,

Joaquín

[bjonkman]

I think this probably points to an issue in the OpenFAST-Simulink_x64.DLL file. Did the code print anything else to the Matlab command window before it crashed? (I can't see if there is anything printed under the execution time.) As I mentioned, the traceback you show says it is in a routine that shouldn't be called for this build. Can you show me how you built that DLL?

[JoaquinPerCarr]

No, the code didn't show anything else apart of that.
The process to obtain .dll file is:

1- I execute fast solution (release_x64 double); after I use python for running test and the test I'm keen on, pass ok.

2- Next step, to do the integration Openfast Simulink, I open Visual Studio 2015 and I execute the fortran File called OpenFAST-Simulink and in properties-input, I change to aim correctly to libmex.lib (default path is not the correct one)
3- I run OpenFAST-Simulink (release Matlab x64 )and after I run FAST(Release Matlab x64) and It was all I did

¿Do you need screenshots of all the steps?

[bjonkman]

Could you open the FAST.sln file and build with Release_Matlab | x64 from that solution file instead of the OpenFAST-Simulink.sln file you are using? If you don't have that option (with the OpenFAST-Simulink project in the FAST solution file), I would recommend using the latest OpenFAST master branch so that you are building with that one.

[JoaquinPerCarr]

I have built FAST.sln solution with this configuration and I obtained this I show you in the screenshot below:

I don't know how to do the build with de master solution. Should I download only the new fortran Openfast-Simulink?

Which steps I need to follow to obtain the .dll that are you looking for? (If you pretend that)

[hbasbas]

Hello everyone,

I don't know if I can join the discussion, I have exactly the same problem.

I am using VS 2019 Community with Intel Parallel Studio XE 2020. I have recently downloaded the master version of OpenFAST so I should have the last one.

I compile the DLL file with the FAST.sln solution with different configurations :

1. In "Release_Double_x64" mode : the compilation works without errors. Then, I create the mex file with the "create_FAST_Sfunc.m" ==> it works. I run the "RUN_OpenLoop" file and I obtain the screenshot in attachment.
   

2. In "Release_64" mode : same problem when reaching the Simulink simulation

3. In "Release_Matlab_64" mode (only for OpenFast-Simulink and FASTlib projects, right ?) : I cannot compile the FAST VS solution (see in attachment)
   

[bjonkman]

@hbasbas: You need to generate a OpenFAST-Simulink-x64.dll from the Visual Studio project, so you really only need to build the version in your step 3 (except you do also need to run the create_FAST_SFunc.m file after completing step 3). If you are running the FAST_SFunc in Matlab before creating the DLL, then I would guess that it is calling another version of this dll from some other place on your Matlab path. If you type which OpenFAST-Simulink-x64.dll, in the Matlab command window, it should give you the full path to the DLL it is using.

The reason your Release_Matlab | x64 configuration (which is the one you need to use) is not building appears to be that you have a different version of Matlab than the project was configured for. You'll need to open the configuration properties for the OpenFAST-Simulink project file (right click on the project, then select properties and go to the linker input line. You'll need to change it to point to the version of Matlab you are using:

[bjonkman]

@JoaquinPerCarr , to get the master branch with git, you can checkout the master branch and then pull the new code.

It's possible that you have another copy of the DLL on your Matlab path that is causing confusion, too. Try which OpenFAST-Simulink_x64.dll in the Matlab command window and see if it is pointing to the correct one.

[JoaquinPerCarr]

Hi @bjonkman:

I did that you said to me. First I downloaded all master openfast files, then I change the old fortran OpenFAST-Simulink and I copied the new one. I built FAST with Release_Matlab_x64 and OpenFAST-Simulink_Release_Matlab_x64 to obtain the new .dll.

I repeated all the process such as that I explained you at first moment in this discussion and I had the same results, Matlab crashes when I execute simulink. i attach a screenshot when I use which OpenFAST-Simulink:

[hbasbas]

Hello,

@bjonkman : thank you for you reply. Thanks to your recommendations, the compilation works. I would like to precise (to possible others users) that it is important to insert the quotation between the path. Due to the space of "Program File", VS tries to find an object file.
However, Matlab continues to crash when executing the Simulink simulation :

Is it possible that the versions of Matlab, of Visual Studio and Intel Parallel Studio XE are responsible of the Matlab crash ?

@JoaquinPerCarr : In the "which" command, it seems that you specified the wrong file : you write "-x64" instead of "_x64"

[hbasbas]

Ohterwise, is it possible to share the compiled file .mex64 of the openfast-master version. I only need to change the input file (.dat) but the source code must be the same for me. Moreover, I will identify the problem :
If it does not work with it, this should means I have a problem with my Matlab version or others. If it works, this means that the Visual Studio compilation is not well configured.

[bjonkman]

Okay, I think I see what the problem is.

If you open <openfast>\modules\openfast-library\src\FAST_Library.h, change the definition of CHANNEL_LENGTH from 10 to 20:

#define CHANNEL_LENGTH 20

Then re-run the create_FAST_SFunc.m file and try again.

I will get a pull request with this fix into OpenFAST.

[hbasbas]

Thank you very much. It works !

[JoaquinPerCarr]

Hi @bjonkman,

If I do this, I obtain this:

I can see that simulink doesn't open and It doesn't do anything else.

[bjonkman]

If you read the error message below the part you circled, you will see that OpenFAST can't find the input file you asked it to run. Run_OpenLoop.m was set up for the old FAST (v8) CertTest cases so you'd have to change the names of the input files. I ran the following code to test the OpenLoop model:

addpath('C:\openfast\build\bin')
FAST_InputFileName = 'C:\openfast\build\reg_tests\glue-codes\openfast\5MW_Land_DLL_WTurb\5MW_Land_DLL_WTurb.fst';

TMax=30;

sim('OpenLoop.mdl',[0,TMax])

[JoaquinPerCarr]

I'm trying the next code because I'm keen on test 25:
Test25 = 'C:\Users\CASA\Documents\code\openfast\reg_tests\r-test\glue-codes\openfast\5MW_OC4Semi_WSt_WavesWN\5MW_OC4Semi_WSt_WavesWN.fst';

FAST_InputFileName = Test25;
disp(FAST_InputFileName)
TMax = 200;

sim('openloop.mdl',[0,TMax]);

I notice that the simulink model doesn't open automatically and I don't know why, but at first it seems to be that it works well

To sum up, do you think the only problem about my first issue was the code line #define CHANNEL_LENGTH 20 in .h file?

Thank you very much @bjonkman

[bjonkman]

I don't think Simulink needs to open the model when you run it with the sim() command.

The incorrect definition of CHANNEL_LENGTH in the .h file was what caused Matlab to shut down (and for anyone reading this in the future, the stack trace was not accurate: it wasn't actually in the FAST_OpFM_Init routine).

As for that being the only problem, let's hope so. :)

[JoaquinPerCarr]

I'm doing different things and I think the master openfast-Simulink is necessary

[JoaquinPerCarr]

I'm going to try run my first simulink model and I will say you if it works nicely

[JoaquinPerCarr]

Hi @bjonkman ,

I would like to ask you how can I see which OpenFAST version I have(dev/master). If there are any form to return to master version, I wish do it.

If it isn't possible, How can I remove/fix the errors(flags) that I show you in next screenshots? CalcSteady, Twr_Kdmp, and Bld_Kdmp are the main problem.

I'm seeing the OpenFAST documentation too. The errors I think that it could be for using dev version of OpenFAST. I don't know what to do.

Best regards,

Joaquín.

[jjonkman]

Dear @JoaquinPerCarr,

I'm not sure I really understand your question, but you appear to be using an older dev version of OpenFAST (somewhere between v2.3 and v2.4) and input file compatible with v2.3. As with any error in the input file processing, you can enable the Echo option to debug problems in the input file formatting.

Regardless, unless you have a specific reason to use this dev version of OpenFAST, I would recommend upgrading to the master branch of OpenFAST, v2.4. Example OpenFAST input files compatible with v2.4 are provided in the master branch of the r-test.

Best regards,

[bjonkman]

@JoaquinPerCarr ,

You can typically see the version of OpenFAST printed to the screen when you run OpenFAST. From your screen shot, I see that it is v2.3.0-548-g43191a90. This means that it is at the git hash 43191a90 and is 548 commits after the tagged version 2.3.0.

To switch to a different version, you can just use some git commands to checkout whatever branch and commit you want.

You could do

git checkout v2.4.0

which would checkout openfast version 2.4.0, but put you in a detached head state in git, or

git checkout master
git pull

which should give you the latest version of the master branch (assuming your master branch is pointing to the openfast repository). Keep in mind that the current state of your git repo may mean that you need to stash some changes before switching branches, etc.

Otherwise, just make sure that you are using example files from the r-test commit associated with the version of OpenFAST you are using.

[LaurenceWETI]

Hello everyone,

I could compile the S-Fuction and run the examples of OpenLoop and Test01_SIG. Now I am trying to extend the inputs of the S-Fuction to enable additionally inputs in addition to the original 8. But in the OpenFAST S-Function I don't have the option to change the NumAdditionalInputs as in FASTv8.
Any help would be appreciated.

Thank you in advance.

[bjonkman]

Are you using the correct combination of FAST_SFunc.mexw64 and OpenFAST-Simulink_x64? Sometimes there are multiple copies of each on the Matlab path. You can check by doing which FAST_SFunc and which OpenFAST-Simulink_x64 from the Matlab command window.

[Cookiewyf]

the matlab find the right mexw64 and openfast-simulink_x64.dll

[bjonkman]

Which model are you running?

[Cookiewyf]

I use openfast-2.6, and I run 5MW_Land_DLL_WTurb and AWT_YFix_WSt(Is this you want to know?and sorry about the jet lag)

[Cookiewyf]

Hi, @bjonkman I tried openfast-2.3 and 2.2, the matlab both crashed. I also tried to compile with VS2017, but it didn't work.I am very distressed about this problem,nad I don't know which part what went wrong.

Which model are you running?

Hi, @bjonkman I tried openfast-2.3 and 2.2, the matlab both crashed. I also tried to compile with VS2017, but it didn't work.I am very distressed about this problem,nad I don't know which part what went wrong.

[Cookiewyf]

Hi, @bjonkman I tried openfast-2.3 and 2.2, the matlab both crashed. I also tried to compile with VS2017, but it didn't work.I am very distressed about this problem,nad I don't know which part what went wrong.

Which model are you running?

Hi, @bjonkman I tried openfast-2.3 and 2.2, the matlab both crashed. I also tried to compile with VS2017, but it didn't work.I am very distressed about this problem,nad I don't know which part what went wrong.

[bjonkman]

I wouldn't recommend using so many different versions of openfast and/or visual studio. I think it will just confuse us more.

If you have any older versions of OpenFAST-Simulink_x64.dll, MAP_x64.dll, or FAST_SFunc.mexw64 on your computer, delete them before starting this process.

Then, starting with a clean version of OpenFAST v2.6, make ONLY these changes:

• remove those two lines of SysMatlabWindows.f90
• update the version of Matlab you are using set in the Visual Studio project's linking settings:
  
• retarget the Visual Studio solution, if necessary (i.e., if you don't have the same Windows SDK or Visual Studio Platform Toolset versions as the files stored in the OpenFAST repository, you will need to do this retargeting). To retarget, select the Project menu in Visual Studio, and retarget solution is the first option on that menu.

Build the Release_Matlab | x64 configuration in Visual Studio.

If you haven't already done so, please make sure that Matlab is set up to use the same C compiler as the version of Visual Studio you used to build OpenFAST. You can do this with the mex -setup command in Matlab. Then, run create_FAST_SFunc.m in Matlab.

Now you should have all the necessary files to run your simulink model. For example, if you are in the
<openfast>\glue-codes\simulink\examples directory in Matlab, this should run without crashing:

addpath('../../../build/bin'); % ideally this is a fixed (not relative) path where the OpenFAST Visual Studio build files are located
FAST_InputFileName = '../../../reg_tests/r-test/glue-codes/openfast/AOC_WSt/AOC_WSt.fst';
TMax               = 60; % seconds

sim('OpenLoop.mdl',[0,TMax]);

You could also run the other two OpenFAST models you mentioned with the OpenLoop Simulink model. (For the 5MW turbine models, you'd also need to make sure you have built an appropriate 64-bit controller DLL.)

[Cookiewyf]

I deleted all the old versions as you said, and build openfast-2.6 with VS2019. Matlab would still crash. In addition, I would like to ask how to know whether the C compiler version of VS2019 is the same as the C compiler version of matlab?I use "Microsoft Visual C++ 2019 (C)" to generate mexw64.
And I tried run 5MW_Land_DLL_WTurb in cmd, the openfast_x64.exe run well.
cmd.txt

[bjonkman]

Could you give more specifics on this issue?

• How exactly you are building the OpenFAST_Simulink dll and its associated mex function?
• What happens when you say "Matlab crashes"? Does Matlab shut down immediately after running the sim command? Or does something else happen?
• Are you running 'OpenLoopmdl' in Simulink? Or a different model?
• What version of Matlab are you using? (Please show the results from ver command in Matlab's command window.)

I wouldn't be too concerned about the C/C++ version in VS2019 (as long as it builds) because it is currently only used for MAP++ and the Registry. However, you can check by clicking on the properties of a C project like MAP_dll and looking at the platform toolset it uses.

[Cookiewyf]

I Screenshots the steps that how I build and use the matlab,and put it in a doc,and the crash.txt is report from matlab
build_step.docx
crash.txt

crash.mp4

[bjonkman]

Please choose Release_Matlab | x64 as the build configuration for creating Matlab, and then build the s-function in Matlab.

[Cookiewyf]

It works! Sorry for my stupid mistake，and thank you very very very much! I wiil do more tests tomorrow .Thank you very much for solving the problem that has troubled me for a long time.
Best wishes!

[LaurenceWETI]

Hello @bjonkman,

Is there any function that can be used in conjunction with WrScr to print matrices/arrays to Matlab command window? you suggested before to use CALL WrScr( trim( Num2Lstr( number ) ) ) to print numbers. However, this function can't be used to print matrices/arrays. for example if the mass matrix in BeamDyn need to be printed, this function is not valid: CALL WrScr( trim( Num2Lstr( p%Mass0_QP(1:6,1:6,1)) ) ) .

Best regards.
Laurence

[bjonkman]

@LaurenceWETI , there isn't currently a function to write matrices to the Matlab command window. You could modify a function like WrMatrix2R4 to do this, though. Here's what I would try:

SUBROUTINE WrMatrix2R4_new( A, ReFmt, MatName )      
      REAL(SiKi),             INTENT(IN) :: A(:,:)
      CHARACTER(*),           INTENT(IN) :: ReFmt   ! Format for printing ReKi numbers  
      CHARACTER(*), OPTIONAL, INTENT(IN) :: MatName
      INTEGER                            :: ErrStat

      INTEGER        :: nr, nc  ! size (rows and columns) of A
      INTEGER        :: i       ! indices into A
      CHARACTER(256) :: Fmt
      CHARACTER(2000) :: Line


      nr = SIZE(A,1)
      nc = SIZE(A,2)

      IF ( PRESENT(MatName) ) THEN
         WRITE( Line, '(A,": ",A," x ",A)', IOSTAT=ErrStat ) TRIM(MatName), TRIM(Num2LStr(nr)), TRIM(Num2LStr(nc))
         CALL WrScr(trim(Line))
      END IF
      
      Fmt = "(2x, "//TRIM(Num2LStr(nc))//"(1x,"//ReFmt//"))"

      DO i=1,nr
         WRITE(Line, Fmt, IOSTAT=ErrStat ) A(i,:)
         IF (ErrStat /= 0) THEN
            CALL WrScr('Error '//TRIM(Num2LStr(ErrStat))//' writing matrix in WrMatrix2R4().')
            RETURN
         END IF
         CALL WrScr(trim(Line))

      END DO

   RETURN
   END SUBROUTINE WrMatrix2R4_new

[FlavieDidier]

Hello everyone,

I don't know if I am posting in the right place.
Matlab crashes every time I try to run a Simulink model.

I am using version 2.4 of OpenFAST, Matlab 2021a and VS 2019.
I also changed the CHANNEL_LENGTH to 20 as recommended in the discussion above.

Best Regards,

Flavie

[eletroinf]

Hello Flavie,

I was stuck on this problem. No success with v2.4 and I don't remember if I discovered what was the problem.
Solution: Compile openfast 3.0.
Pay attention that Aerodyn file was changed if you are currently using v 2.3.0

Regards,
Ricardo

[FlavieDidier]

Thank you for you reply Ricardo, I try with OpenFAST 3.0 but unfortunately it didn't work either.

Best regards,

[hbasbas]

Hi,

@FlavieDidier Could you send the screenshot of the error message from Matlab please ?

Hedi

[FlavieDidier]

Hi @hbasbas,

Matlab crash immediately without any error message.

Regards,

[bjonkman]

@FlavieDidier Do the sample models provided with OpenFAST run?

[FlavieDidier]

@bjonkman If we are talking about Run_OpenLoop or Test01_SIG, then neither of them works with the FAST_InputFileName already specified.

[bjonkman]

neither of them works with the FAST_InputFileName already specified

I'm not exactly sure what you mean by that statement. Can you get the OpenLoop simulink model to run with one of the OpenFAST r-test cases? For example:

diary on
addpath('C:\openfast\build\bin')
FAST_InputFileName = 'C:\openfast\build\reg_tests\glue-codes\openfast\5MW_Land_DLL_WTurb\5MW_Land_DLL_WTurb.fst';

TMax=30;

sim('OpenLoop.mdl',[0,TMax])
diary off

You will have to change the paths to match your setup. Also notice that I added the diary command in Matlab. This should produce a file with the text output from the command window (the file will be in your current Matlab directory and will be called diary). If Matlab crashes, you can take a look at that file and it might help debug the issue.

It's really hard to know how to help without more detailed information about what you are running, how you are trying to run the model, and how the simulation is failing.

[FlavieDidier]

Hello @bjonkman,

Thank you for your explaination.
Matlab crashes when I run the following instructions :

  diary on
  addpath('D:/OpenFAST/openfast/build/bin')
  FAST_InputFileName = 'D:/OpenFAST/openfast/reg_tests/r-test/glue-codes/openfast /5MW_Land_DLL_WTurb\5MW_Land_DLL_WTurb.fst';

  TMax=30;

  sim('OpenLoop.mdl',[0,TMax])
  diary off

When I check the content of the diary file, nothing is written in it.

Best Regards,

[FlavieDidier]

• without the space between "openfast" and "/5MW" in the directory

[arhegazy]

Dear @bjonkman,

I have the same crashing problem. Although the r-tests work fine, the crash occurs when I try to use a different controller other than the *.dll provided. I compiled the S-function myself as well as tried using the precompiled binaries, yet the crash persists. I attached both the crash report and the diary file. Could you please share your email so that I can send you the files to check if you don't mind?

Best regards,

Crash report.txt
diary.txt

[bjonkman]

Hi @arhegazy,

In the diary file you sent, I don't see that you are calling an external DLL controller. I would expect to see something like Running ServoDyn Interface for Bladed Controllers in the output, so it appears that you are telling the code to use control signals from Simulink and not an external DLL (unless you have called the controller DLL from Simulink separately from OpenFAST). When you say "the *.dll provided", are you referring to the OpenFAST-Simulink_x64.dll file?

Both of the crashes appear to happen at 51 seconds into the simulation. Is there anything in particular that is happening at that time?

[arhegazy]

Hi @bjonkman,

Thanks for your response. I am telling the code to use control signals from Simulink instead of Discon.dll provided.
It was a mistake from my side in the control signal that caused the crash. Strangely, Simulink just crashed without stating that there was an issue in one of the controller lines. Now, it's fine. I managed to detect the error.
Thanks a lot for your reply!