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]

I am not aware of anything that would have changed the NumAdditionalInputs functionality between FAST v8 and the latest OpenFAST. What exactly isn't working?

[LaurenceWETI]

Hello @bjonkman,

Thank you for your replay. Actually, I would change the NumAdditionalInputs to import the blade element masses in the S-Function, which are more than 11 for the 5-MW model. I mean 11, because the maximum number of entries that are allowed for NumAdditionalInputs should not exceed the 11 entries, as I read in README_FAST8:

I already changed the data type of the blade element masses in ElastoDyn, and I could change the masses within a given simulation. Now I generate extra channels to export the blade element masses from ElastoDyn in Simulink. I would modify the masses in Simulink and import them in the S-Function, i.e. in ElastoDyn.

_Can ElastoDyn recognize the blade element masses that are imported from the S-Function?

_Can ElastoDyn notice the changes that are done in Simulink?

_Is that possible to input more than 11 inputs in addition to the origin 8 in the S-Function?

[bjonkman]

If you want more than 10 additional inputs to send to OpenFAST, you can change the value of MAXInitINPUTS in both FAST_Library.h and FAST_Library.f90 and recompile both the Matlab S-Function and the OpenFAST dll. (If you enter an array with more than MAXInitINPUTS+1 values in Simulink, you will probably get a segmentation fault).

MAXInitINPUTS defines the largest array that can be accepted from Simulink and passed to the OpenFAST Fortran code. OpenFAST doesn't do anything with those extra array values unless you tell it to, so if you want to pass values to ElastoDyn, you will have to make some extra changes in the code.

For starters, you'll have to look at InitInpAry in FAST_Library.f90, and then you'll have to pass some information to ElastoDyn. I'd recommend looking at the NWTC forum for some pointers on what you'll have to change:

• https://wind.nrel.gov/forum/wind/search.php?keywords=NumAdditionalInputs
• https://wind.nrel.gov/forum/wind/search.php?keywords=InitInpAry
• https://wind.nrel.gov/forum/wind/viewtopic.php?f=4&t=1171&hilit=InitInpAry

Please note, however, that the these additional inputs are values passed from the S-Function in Simulink to OpenFAST. The code isn't particularly set up to pass values to Simulink unless you are using the WriteOutput array (i.e., the OutList channels specified in each OpenFAST module).

[LaurenceWETI]

Hello @bjonkman,

Thank you for your quick replay and for the links. As a starter, I tried at the beginning to pass only one additional input in the S-Function. I used the rotor speed (RotSpeed) as an additional input, which is already used in the OutListParameters:

1. Set the rotor speed as Input in subroutine FAST_SetExternalInputs() in FAST_Library.f90

2. Rebuild the FASTlib from C:....\OpenFAST\vs-build\FASTlib\ FASTlib.sln

3. Run the OpenLoop with one additional input

4. Simulation crashed in Matlab/Simulink I see in subroutine FAST_Start () in FAST_Library.f90 that only 3 additional inputs are allowed. Do I have to change this to enable only one input?

[bjonkman]

The original FAST S-Function is set up so that if you say there are 3 additional inputs, it will assume you are simulating Lidar functionality. I don't think the code you show is used (I don't think that #ifdef is true), but there is similar logic in the FAST_Update subroutine.

I'd just change the line so that it doesn't produce an error if the number of additional inputs is 1:

   ELSEIF(  NumInputs_c /= NumFixedInputs .AND. NumInputs_c /= NumFixedInputs+3 .AND. NumInputs_c /= NumFixedInputs+1 ) THEN

This error handling is there because it would be very easy to get a segmentation fault when passing arrays of different sizes between Simulink and the Fortran code.

[LaurenceWETI]

Hello @bjonkman, Thank you for pointing that out. I changed the logic as you mentioned in the previous comment in subroutine FAST-Update, and then I recompiled the FAST DLL from \OpenFAST\vs-build\FASTlib\ FASTlib.sln with different configuration:

1. Relaseas Soultion Configuration, x64as Soultion Platform, and Build the solution using the Build->Build Soultion.

2. Relaseas Soultion Configuration, x64as Soultion Platform, and Build the solution using the Build->Rebuild FASTlib.

3. Relase_Matlabas Soultion Configuration, x64as Soultion Platform, and Build the solution using the Build->Rebuild FASTlib. After every compilation I run the OpenLoop_Test with the additional input and I received the same old error

Then I recompiled FAST from \OpenFAST\vs-build\FAST\ FASTlib.sln with Relase_Matlab, x64, and Build->Build Soultion the compilation crashed:

Line 341 in FAST_Library.f90 is the line where I added the logic for the additional input

It seems that I the structure of subroutine FAST_SetExtrenalInputs should be extend to allow such additional logic?

[bjonkman]

Did you add the new %RotSpeed field to the data structure you are using it in?

If you are adding fields to a data structure, you need to define them in the appropriate OpenFAST Registry input file. In your case, there should be an additional line in the definition of the FAST_ExternInputType. So, somewhere near line 626 in FAST_Registry.txt, you should add a line for the new RotSpeed field:

typedef ^   FAST_ExternInputType    ReKi    RotSpeed    -   -   -   "Rotor speed from Simulink"

Also, the only configuration you need to use is the Release_Matlab | x64 configuration. The other configurations are not used in the Simulink process at all, so you were just running the old code with your first 2 builds.

[LaurenceWETI]

Hello @bjonkman, First of all thank you very much for your help. I could add a one more additional input to the S-Function as Follow:

1. occupy the 9th element in the InputAry in FAST_Library.f90\ subroutine FAST_SetExternalInputs

2. define the additional input in FAST_Rgistery.txt\ FAST_ExternalInput data

3. link the additional external input to ElastoDyn in FAST_Solver.f90\ SUBROUTINE ED_SetExternalInput (I wrote this routine)

4. define the additional external input in ElastoDyn_Registry.txt

5. generate a new parameter in EladoDyn to overwrite and to export in the OutListParameter using the Write_ChckOutLst.m script

6. overwriting the new defined parameter in ElastoDyn with the additional input from Siimulink in ElastoDyn.f90\ SUBROUTINE ED_CalcOutput

7. set the RotMass in Simulink as a constant to overwrite the defined parameter in ElastoDyn.f90 RMSimulink

8. Plot the overwritten output RMSimulink over the time (1 s)

As you see, RMSimulink is constant zero over the time, and the overwriting did not work. I think what is missing is a switch in the input file of ElastoDyn that enables external inputs from Simulink as it is in the ServoDyn input file with the PCMode. Can you see any mistake in the implantation above? Is there anything that I missed by the overwriting?

[bjonkman]

You would have to request the new RMSimulink output channel in the OutList of the ElastoDyn input file so that the value in the m%AllOuts array gets put in the y%WriteOutput array (which is what is printed in output files and sent to Simulink). However, to get that in the WriteOutput array, you'd need to modify the SetOutParam() subroutine in ElastoDyn.f90 so that it recognizes the new output you are adding.

Alternatively, if you don't want to update the code in SetOutParam(), you could just overwrite an existing channel in ElastoDyn and request that channel instead.

[LaurenceWETI]

Hello @bjonkman, Thank you for replay. I already update the code in Subroutine SetOutParam() in ElastoDyn.f90 and the code in ElastoDyn_IO.f90, in order to add the new output channel RMSimulink. I am still wondering why the value of the additional external input u%ExternalRotMass from Simulink equals zero during the simulation, although I set this value to 1000 in Simulink? As you suggested I used an existing channel “SpnMxlb” to overwrite, but the result still the same. u%ExternalRotMass is always zero!

[LaurenceWETI]

Hello @bjonkman, I found where the problem was. I didn’t call SUBROUTINE ED_SetExternalInputs in SUBROUTINE ED_InputSolve in the FAST_Solver.f90. Thus, I had to modify the argument of SUBROUTINE ED_InputSolve to add the m_FAST data type.

[LaurenceWETI]

Hello @bjonkman, As you mentioned in a previous comment I changed the MAXInitINPUTSof the S-Function to allow 100 additionally inputs. My goal is to overwrite the blade element masses in ElastoDyn.f90\ p%BElmntMass. I could overwrite a one blade element mass through the S-Function. Now I am trying to overwrite all the blade element masses, which are 51 element for the three blades. I could compile FAST with the new modification but when I compile MATLAB I become this error:

Here is the error line in FAST_Library.f90

The blade element masse m_FAST%ExternInput%SpnMB is defined in FAST_Registery.txt:

Can you see if I miss anything by the definition of SPNMB?

[bjonkman]

You have defined SPNMB as a 2-dimensional allocatable array. I don't know what size you allocated it to be--hopefully you did this before calling FAST_SetExternalInputs--but you are setting it equal to a 1-dimensional array of size 52 (note: you might want to check that 51 that you're using or see if the InputAry indices should go from 9:59 instead). The error is saying that the arrays you are trying to set equal to each other are not the same shape (1-d vs 2-d), so they can't be equal.

Also, be careful in overwriting parameters (anything in the p% data structure). These values are not supposed to change after initialization, so (1) you will likely get errors saying that you can't change them in certain subroutines, (2) other parameters may depend on their initial values, too, so you'd need to make that consistent if you do change the code so you can modify the parameters during the simulation.

[LaurenceWETI]

Hello @bjonkman, Thank you for pointing that out. I changed the dimension of the SpnMb array from 2-d to 1-d array of 51 elements inFAST_Register.txt and ElastoDyn_Registery.txt. Then I defined a 3x17 matrix in Subroutine ED_CalcOutput()\ElastoDyn.f90

I used this matrix to reshape the 1-d array, which is imported from Simulink, to a 3x17 matrix

After reshaping, I overwrote the blade element masses with the values that are imported from Simulink

In order to update the values that are depending on the p%BElmntMass I called Subroutine UpdateCoeff(p, ErrStat, ErrMsg)

Subroutine UpdateCoeff (p, ErrStat, ErrMsg)\ElastoDyn.f90, which is generated by myself, is a very similar routine to Subroutine Coeff(p,InputFileData, ErrStat, ErrMsg) with the advantage of independence of input file data. This allows Subroutine UpdateCoeff() to be called in the time domain, i.e. in ED_CalcOutput(). Additionally, I changed the intent of the parameter data structure from only IN to INOUT. This is as you mentioned above to enable the p% data structure to be overwritten. With the code modifications above I could compile both FAST and Matlab without errors. But when I run the OpenLoop with the additional 51 inputs the simulation crashed after two simulation steps.

I couldn’t identify the reason of such error. Do you see anything wrong in my implementation that could produce this error? The overwriting of only one blade element mass is succeed. But for all blade elements it didn’t. I would be very grateful for any help. And thank you again for your quick replay

[bjonkman]

Based on how your arrays are allocated, it looks like you should have

p%BElmntMass(J,K) = ElemMass(K,J)

I am not sure that is the only issue, though. One way to debug this without having Matlab in the process is to just write a simple c driver code (copy the main calls from FAST_SFunc.c) and then build and run it through the Visual Studio debugger. I had something like this for FAST v8--it's a very useful tool to help find these kinds of errors.

[LaurenceWETI]

Hello @bjonkman, Thank you for pointing the mistake with Element (K,J). Unfortunately, it was obviously not the only issue. As you suggest I wrote a simple c driver:

But I couldn’t know the main calls from FAST_Sfunction.c that you meant to copy and paste in the driver above. Actually, I used to write pop-up messages in certain places in the FORTRAN code to trace the errors, this is how I’m debugging when I used the .exe

As you see this method won’t work for the S-Function. Can you help with debugging with VS?

[bjonkman]

If you use CALL WrScr(string) you can print things to the Matlab console for debugging. I would guess that using print * would create a fort.7 text file in the current Matlab directory (when you are running the Simulink model). Otherwise, you could just write to another file using WRITE(Unit,Fmt) data for your debugging info.

If you want to use the Visual Studio debugger, you should create a C code to call the appropriate parts of the DLL, something similar to this one that was written for the OpenFOAM interface: https://github.com/old-NWTC/FAST/blob/master/Source/FAST_Prog.c

Going through the FAST_SFunc.c file, I would guess that you'd need these routines for initialization:

       FAST_AllocateTurbines(&nTurbines, &ErrStat, ErrMsg);
       FAST_Sizes(&iTurb, &TMax, InitInputAry, InputFileName, &AbortErrLev, &NumOutputs, &dt, &ErrStat, ErrMsg, ChannelNames);
        FAST_Start(&iTurb, &NumInputs, &NumOutputs, InputAry, OutputAry, &ErrStat, ErrMsg);

Then for each time step (i.e., in a loop),

    FAST_Update(&iTurb, &NumInputs, &NumOutputs, InputAry, OutputAry, &ErrStat, ErrMsg);

And at the end, you'd need

      FAST_End(&iTurb, &tr);
      FAST_DeallocateTurbines(&ErrStat, ErrMsg);

[LaurenceWETI]

Hello @bjonkman,

Thank you for your help. CALL WrScr(string) is a brilliant function, it helped a lot. The only one disadvantage of this function is that I could only print string but no values in the comand window of Matlab. I’ll try also to debug the FAST_Sfunction.c with VS. Thanks a lot

[bjonkman]

There is also a Num2LStr() function (number-to-left-justified-string) that you can use in conjunction with WrScr, which can help print numerical values: CALL WrScr( trim( Num2Lstr( number ) ) )

[eletroinf]

I Have the same problem with openFAST 2.4.0-master and dev. Compilation with Visual studio and mex generated by C compiler installed by means of Matlab Add-on (Matlab 2018b).

The S-function generated using v 2.4.0 source files works fine with openFAST 2.3.0 that I also compiled with Visual Studio. So I think the problem is not with the S-function.

Neither my project nor the examples works - all them result in Matlab crash.

[eletroinf]

I just tried to generate S-function changing the parameter #define CHANNEL_LENGTH 20 in FAST_library.h file and I got the same problem. Here is my Matlab output:

---

           abort() detected at sex nov 27 09:49:16 2020 -0300

---

Configuration: Crash Decoding : Disabled - No sandbox or build area path Crash Mode : continue (default) Default Encoding : windows-1252 Deployed : false Graphics Driver : Unknown hardware Graphics card 1 : Intel Corporation ( 0x8086 ) Intel(R) UHD Graphics 630 Version 27.20.100.8681 (2020-9-5) Java Version : Java 1.8.0_152-b16 with Oracle Corporation Java HotSpot(TM) 64-Bit Server VM mixed mode MATLAB Architecture : win64 MATLAB Entitlement ID : 6257193 MATLAB Root : C:\Program Files\MATLAB\R2018b MATLAB Version : 9.5.0.944444 (R2018b) OpenGL : hardware Operating System : Microsoft Windows 10 Pro Process ID : 9896 Processor ID : x86 Family 6 Model 158 Stepping 10, GenuineIntel Session Key : 2e3cb4b1-3a3b-46b0-bf51-135d94257c8d Window System : Version 10.0 (Build 18363)

Fault Count: 1

Abnormal termination

Register State (captured): RAX = 00000000107aedd8 RBX = 00000000107aedd8 RCX = 00000000043ed920 RDX = 0000000000000000 RSP = 00000000043ed890 RBP = 00000000043f0e39 RSI = 0000000000000000 RDI = 0000000000000000

R8 = 00000000000dc430 R9 = 00007ffc4a14e930 R10 = 0000000000000014 R11 = 00000000000d5980 R12 = 00000000043ee558 R13 = 0000000000000000 R14 = 000000001079ed08 R15 = 00000000043edf90

RIP = 000000001055292a EFL = 00000206

CS = 0033 FS = 0053 GS = 002b

Stack Trace (captured): [ 0] 0x000000001054b2c3 bin\win64\libmwfl.dll+00045763 foundation::core::diag::thread_context::unspecified_bool+00000051 [ 1] 0x0000000010549288 bin\win64\libmwfl.dll+00037512 foundation::core::diag::stacktrace_base::capture+00000024 [ 2] 0x000000001054db80 bin\win64\libmwfl.dll+00056192 foundation::core::diag::symbols::getSymbolAddress+00009632 [ 3] 0x000000001055165f bin\win64\libmwfl.dll+00071263 foundation::core::diag::is_terminate_message_enabled+00000575 [ 4] 0x0000000016dbeb3f bin\win64\mcr.dll+01108799 QueryMLFcnTable_mcr+00047535 [ 5] 0x0000000016dbe277 bin\win64\mcr.dll+01106551 QueryMLFcnTable_mcr+00045287 [ 6] 0x0000000016dba2b0 bin\win64\mcr.dll+01090224 QueryMLFcnTable_mcr+00028960 [ 7] 0x0000000016dbbec7 bin\win64\mcr.dll+01097415 QueryMLFcnTable_mcr+00036151 [ 8] 0x00007ffc5307caad C:\WINDOWS\System32\ucrtbase.dll+00445101 raise+00000477 [ 9] 0x00007ffc5307dab1 C:\WINDOWS\System32\ucrtbase.dll+00449201 abort+00000049 [ 10] 0x00007ffc5307d20f C:\WINDOWS\System32\ucrtbase.dll+00446991 terminate+00000031 [ 11] 0x00007ffc4a142388 C:\Program Files\MATLAB\R2018b\bin\win64\VCRUNTIME140.dll+00009096 is_exception_typeof+00002312 [ 12] 0x00007ffc4a141ec2 C:\Program Files\MATLAB\R2018b\bin\win64\VCRUNTIME140.dll+00007874 is_exception_typeof+00001090 [ 13] 0x00007ffc4a14b950 C:\Program Files\MATLAB\R2018b\bin\win64\VCRUNTIME140.dll+00047440 _CxxFrameHandler3+00000144 [ 14] 0x00007ffc5554184f C:\WINDOWS\SYSTEM32\ntdll.dll+00661583 _chkstk+00000287 [ 15] 0x00007ffc5550a889 C:\WINDOWS\SYSTEM32\ntdll.dll+00436361 RtlRaiseException+00000921 [ 16] 0x00007ffc5550a643 C:\WINDOWS\SYSTEM32\ntdll.dll+00435779 RtlRaiseException+00000339 [ 17] 0x00007ffc532e3b29 C:\WINDOWS\System32\KERNELBASE.dll+00277289 RaiseException+00000105 [ 18] 0x00007ffc4a1444f2 C:\Program Files\MATLAB\R2018b\bin\win64\VCRUNTIME140.dll+00017650 CxxThrowException+00000194 [ 19] 0x000000000d89d18a bin\win64\libmwsl_services.dll+00512394 slsvStringOrID::untranslatedStr+00073226 [ 20] 0x000000000d8a2746 bin\win64\libmwsl_services.dll+00534342 slsvThrowIExceptionFromDiagnostic+00000310 [ 21] 0x000000017406c8a2 bin\win64\codermapping_core.dll+00051362 mds::BlockMapping::setBlock+00000354 [ 22] 0x0000000174094a28 bin\win64\codermapping_core.dll+00215592 sl::MappingManager::checkValidMappingType+00000168 [ 23] 0x00000001740966df bin\win64\codermapping_core.dll+00222943 sl::MappingManager::getActiveModelMapping+00000031 [ 24] 0x0000000174095e8a bin\win64\codermapping_core.dll+00220810 sl::MappingManager::detachBdListener+00000762 [ 25] 0x000000001a8a2c08 bin\win64\udd.dll+00404488 UDListener::removeListenerContainer+00002392 [ 26] 0x000000001a89ac8c bin\win64\udd.dll+00371852 UDEventInfo::send+00000092 [ 27] 0x000000025e7367d0 bin\win64\libmwconfigset_base.dll+01075152 mds::postBdEvent+00000144 [ 28] 0x00000000ffeb1035 bin\win64\simulink_configset.dll+00069685 detachConfigSet+00002597 [ 29] 0x00000000ffeb12d2 bin\win64\simulink_configset.dll+00070354 restoreOrigConfigSetForBuild+00000322 [ 30] 0x000000000acabbe4 bin\win64\libmwsimulink.dll+10140644 sldeutils::searchAvailableFunctions+00190052 [ 31] 0x000000000aca73f2 bin\win64\libmwsimulink.dll+10122226 sldeutils::searchAvailableFunctions+00171634 [ 32] 0x000000000aca8234 bin\win64\libmwsimulink.dll+10125876 sldeutils::searchAvailableFunctions+00175284 [ 33] 0x000000000b572804 bin\win64\libmwsimulink.dll+19343364 slstSetOutputPortRateID+00361588 [ 34] 0x000000000b5365e4 bin\win64\libmwsimulink.dll+19097060 slstSetOutputPortRateID+00115284 [ 35] 0x000000000ae232e7 bin\win64\libmwsimulink.dll+11678439 M2MIdentifySLClones+00138423 [ 36] 0x000000000bae8e2a bin\win64\libmwsimulink.dll+25071146 test::sl_startup+04405434 [ 37] 0x00007ffc53029d26 C:\WINDOWS\System32\ucrtbase.dll+00105766 execute_onexit_table+00000342 [ 38] 0x00007ffc53029c4b C:\WINDOWS\System32\ucrtbase.dll+00105547 execute_onexit_table+00000123 [ 39] 0x00007ffc53029c04 C:\WINDOWS\System32\ucrtbase.dll+00105476 execute_onexit_table+00000052 [ 40] 0x000000000b6ba73a bin\win64\libmwsimulink.dll+20686650 test::sl_startup+00020938 [ 41] 0x000000000b6ba838 bin\win64\libmwsimulink.dll+20686904 test::sl_startup+00021192 [ 42] 0x00007ffc554c5021 C:\WINDOWS\SYSTEM32\ntdll.dll+00151585 RtlActivateActivationContextUnsafeFast+00000289 [ 43] 0x00007ffc5550b102 C:\WINDOWS\SYSTEM32\ntdll.dll+00438530 LdrShutdownProcess+00000306 [ 44] 0x00007ffc5550afad C:\WINDOWS\SYSTEM32\ntdll.dll+00438189 RtlExitUserProcess+00000173 [ 45] 0x00007ffc546bcdda C:\WINDOWS\System32\KERNEL32.DLL+00118234 ExitProcess+00000010 [ 46] 0x00007ffbec542541 D:\ricardo\documents\PROGRAMAS\nrel_open_fast\bin\OpenFAST-Simulink_x64.dll+44770625 FAST_OpFM_Init+44675569 [ 47] 0x00007ffbec5424f7 D:\ricardo\documents\PROGRAMAS\nrel_open_fast\bin\OpenFAST-Simulink_x64.dll+44770551 FAST_OpFM_Init+44675495 [ 48] 0x00007ffbeaeb7b5a D:\ricardo\documents\PROGRAMAS\nrel_open_fast\bin\OpenFAST-Simulink_x64.dll+21134170 FAST_OpFM_Init+21039114 [ 49] 0x00007ffbe9b7bc82 D:\ricardo\documents\PROGRAMAS\nrel_open_fast\bin\OpenFAST-Simulink_x64.dll+00965762 FAST_OpFM_Init+00870706 [ 50] 0x00007ffbe9afaa54 D:\ricardo\documents\PROGRAMAS\nrel_open_fast\bin\OpenFAST-Simulink_x64.dll+00436820 FAST_OpFM_Init+00341764 [ 51] 0x00007ffbe9b4b42b D:\ricardo\documents\PROGRAMAS\nrel_open_fast\bin\OpenFAST-Simulink_x64.dll+00767019 FAST_OpFM_Init+00671963 [ 52] 0x00007ffbe9b4c4ef D:\ricardo\documents\PROGRAMAS\nrel_open_fast\bin\OpenFAST-Simulink_x64.dll+00771311 FAST_OpFM_Init+00676255 [ 53] 0x00007ffbe9aa5aba D:\ricardo\documents\PROGRAMAS\nrel_open_fast\bin\OpenFAST-Simulink_x64.dll+00088762 FAST_End+00000074 [ 54] 0x00000002b2f5155c D:\ricardo\documents\PROGRAMAS\nrel_open_fast\bin\FAST_SFunc.mexw64+00005468 [ 55] 0x00000002b2f520bf D:\ricardo\documents\PROGRAMAS\nrel_open_fast\bin\FAST_SFunc.mexw64+00008383 [ 56] 0x00000002b2f524ac D:\ricardo\documents\PROGRAMAS\nrel_open_fast\bin\FAST_SFunc.mexw64+00009388 [ 57] 0x00000002b2f541bc D:\ricardo\documents\PROGRAMAS\nrel_open_fast\bin\FAST_SFunc.mexw64+00016828 mexFunction+00001596 [ 58] 0x00000000fc635524 bin\win64\libmex.dll+00349476 MexRetrieveVersion+00003348 [ 59] 0x00000000fc63571c bin\win64\libmex.dll+00349980 MexRetrieveVersion+00003852 [ 60] 0x00000000fc635884 bin\win64\libmex.dll+00350340 MexRetrieveVersion+00004212 [ 61] 0x00000000fc619059 bin\win64\libmex.dll+00233561 mexUnlock_800+00025273 [ 62] 0x0000000016f0e007 bin\win64\pgo\m_dispatcher.dll+00057351 Mfh_file::dispatch_fh_impl+00001111 [ 63] 0x0000000016f0da9e bin\win64\pgo\m_dispatcher.dll+00055966 Mfh_file::dispatch_fh+00000062 [ 64] 0x0000000016f78622 bin\win64\pgo\m_dispatcher.dll+00493090 mdDoMatlabFcnCall+00000122 [ 65] 0x000000025d08278a bin\win64\sl_utility.dll+00337802 SimpleUserException::~SimpleUserException+00000282 [ 66] 0x000000000da124f8 bin\win64\libmwsl_services.dll+02041080 CMatlabCommandNoWatermark::execute+00000056 [ 67] 0x000000025d083129 bin\win64\sl_utility.dll+00340265 slDoMatlabFcnCall+00000089 [ 68] 0x000000000b510fa2 bin\win64\libmwsimulink.dll+18943906 slSetStateflowChartStateAccessInterface+00252338 [ 69] 0x000000000b50ecb1 bin\win64\libmwsimulink.dll+18934961 slSetStateflowChartStateAccessInterface+00243393 [ 70] 0x000000000b511501 bin\win64\libmwsimulink.dll+18945281 slSetStateflowChartStateAccessInterface+00253713 [ 71] 0x000000000b4f1993 bin\win64\libmwsimulink.dll+18815379 slSetStateflowChartStateAccessInterface+00123811 [ 72] 0x000000000b4f1dca bin\win64\libmwsimulink.dll+18816458 slSetStateflowChartStateAccessInterface+00124890 [ 73] 0x000000000b4f3737 bin\win64\libmwsimulink.dll+18822967 slSetStateflowChartStateAccessInterface+00131399 [ 74] 0x000000000b4b503c bin\win64\libmwsimulink.dll+18567228 StateflowAccessStateInterface::~StateflowAccessStateInterface+00037084 [ 75] 0x000000000b301ecb bin\win64\libmwsimulink.dll+16785099 closeMaskEditor+00056683 [ 76] 0x000000000b3021c9 bin\win64\libmwsimulink.dll+16785865 closeMaskEditor+00057449 [ 77] 0x000000000b30f3c4 bin\win64\libmwsimulink.dll+16839620 BlockSetLocation+00006420 [ 78] 0x000000000b30b424 bin\win64\libmwsimulink.dll+16823332 closeMaskEditor+00094916 [ 79] 0x000000000fb5a04b bin\win64\sl_lang_blocks.dll+07118923 SubsystemBlock::DrawSubsystemVariants+00006491 [ 80] 0x000000000fb59631 bin\win64\sl_lang_blocks.dll+07116337 SubsystemBlock::DrawSubsystemVariants+00003905 [ 81] 0x000000000fb93d53 bin\win64\sl_lang_blocks.dll+07355731 SubsystemCopyContext::srcBdIsHighlighting+00007491 [ 82] 0x000000000fb4e013 bin\win64\sl_lang_blocks.dll+07069715 SubsystemBlock::CheckPrmsAndCreateDlgPrmCache+00001139 [ 83] 0x000000000b301f00 bin\win64\libmwsimulink.dll+16785152 closeMaskEditor+00056736 [ 84] 0x000000000b3021c9 bin\win64\libmwsimulink.dll+16785865 closeMaskEditor+00057449 [ 85] 0x000000000b30f3c4 bin\win64\libmwsimulink.dll+16839620 BlockSetLocation+00006420 [ 86] 0x000000000b30b424 bin\win64\libmwsimulink.dll+16823332 closeMaskEditor+00094916 [ 87] 0x00000002622387c2 bin\win64\sl_compile.dll+05539778 EvalAllBlockParamsAndModelArgs+00003586 [ 88] 0x0000000261f544ef bin\win64\sl_compile.dll+02508015 SLCompEvalAllBlockParamsAndModelArgs+00001439 [ 89] 0x000000000afd3e2b bin\win64\libmwsimulink.dll+13450795 ssSetBlockIsPurelyCombinatorial+00033739 [ 90] 0x000000000afd4014 bin\win64\libmwsimulink.dll+13451284 ssSetBlockIsPurelyCombinatorial+00034228 [ 91] 0x000000000ae33fd5 bin\win64\libmwsimulink.dll+11747285 M2MIdentifySLClones+00207269 [ 92] 0x000000000ae26bf7 bin\win64\libmwsimulink.dll+11693047 M2MIdentifySLClones+00153031 [ 93] 0x000000000ae33929 bin\win64\libmwsimulink.dll+11745577 M2MIdentifySLClones+00205561 [ 94] 0x000000000ae2ea7c bin\win64\libmwsimulink.dll+11725436 M2MIdentifySLClones+00185420 [ 95] 0x000000000b538177 bin\win64\libmwsimulink.dll+19104119 slstSetOutputPortRateID+00122343 [ 96] 0x000000000b53d10e bin\win64\libmwsimulink.dll+19124494 slstSetOutputPortRateID+00142718 [ 97] 0x000000000b5439c1 bin\win64\libmwsimulink.dll+19151297 slstSetOutputPortRateID+00169521 [ 98] 0x000000000b5431a7 bin\win64\libmwsimulink.dll+19149223 slstSetOutputPortRateID+00167447 [ 99] 0x000000000b576d05 bin\win64\libmwsimulink.dll+19361029 slstSetOutputPortRateID+00379253 [100] 0x000000000ad7960a bin\win64\libmwsimulink.dll+10982922 slAccPostBlock+00178826 [101] 0x000000000abc8e73 bin\win64\libmwsimulink.dll+09211507 QueryMLFcnTable_libmwsimulink+00088563 [102] 0x0000000016f0b724 bin\win64\pgo\m_dispatcher.dll+00046884 Mdispatcher::getDispatcher+00002228 [103] 0x0000000016f0cbe7 bin\win64\pgo\m_dispatcher.dll+00052199 Mfh_MATLAB_fn_impl::dispatch_fh+00000343 [104] 0x0000000017de4ead bin\win64\pgo\m_lxe.dll+00347821 [105] 0x0000000017f7e9b6 bin\win64\pgo\m_lxe.dll+02025910 MathWorks::lxe::ShutdownLxeEngine+00004034 [106] 0x0000000017edfd3c bin\win64\pgo\m_lxe.dll+01375548 mwboost::archive::detail::iserializer<mwboost::archive::binaryTerm_iarchive,MathWorks::lxe::function_descriptor>::load_object_data+00493568 [107] 0x0000000017ee091c bin\win64\pgo\m_lxe.dll+01378588 mwboost::archive::detail::iserializer<mwboost::archive::binaryTerm_iarchive,MathWorks::lxe::function_descriptor>::load_object_data+00496608 [108] 0x0000000017ee1c92 bin\win64\pgo\m_lxe.dll+01383570 mwboost::archive::detail::iserializer<mwboost::archive::binaryTerm_iarchive,MathWorks::lxe::function_descriptor>::load_object_data+00501590 [109] 0x0000000017ee28f8 bin\win64\pgo\m_lxe.dll+01386744 mwboost::archive::detail::iserializer<mwboost::archive::binaryTerm_iarchive,MathWorks::lxe::function_descriptor>::load_object_data+00504764 [110] 0x0000000017ee1ddf bin\win64\pgo\m_lxe.dll+01383903 mwboost::archive::detail::iserializer<mwboost::archive::binaryTerm_iarchive,MathWorks::lxe::function_descriptor>::load_object_data+00501923 [111] 0x0000000017ee1ede bin\win64\pgo\m_lxe.dll+01384158 mwboost::archive::detail::iserializer<mwboost::archive::binaryTerm_iarchive,MathWorks::lxe::function_descriptor>::load_object_data+00502178 [112] 0x0000000017de9a7d bin\win64\pgo\m_lxe.dll+00367229 [113] 0x0000000017dfb265 bin\win64\pgo\m_lxe.dll+00438885 [114] 0x0000000017dfa88c bin\win64\pgo\m_lxe.dll+00436364 [115] 0x0000000017df8779 bin\win64\pgo\m_lxe.dll+00427897 [116] 0x0000000017df90eb bin\win64\pgo\m_lxe.dll+00430315 [117] 0x0000000017df8a49 bin\win64\pgo\m_lxe.dll+00428617 [118] 0x0000000016f0e007 bin\win64\pgo\m_dispatcher.dll+00057351 Mfh_file::dispatch_fh_impl+00001111 [119] 0x0000000016f0da9e bin\win64\pgo\m_dispatcher.dll+00055966 Mfh_file::dispatch_fh+00000062 [120] 0x0000000017de4ead bin\win64\pgo\m_lxe.dll+00347821 [121] 0x0000000017f7e9b6 bin\win64\pgo\m_lxe.dll+02025910 MathWorks::lxe::ShutdownLxeEngine+00004034 [122] 0x0000000017edfd3c bin\win64\pgo\m_lxe.dll+01375548 mwboost::archive::detail::iserializer<mwboost::archive::binaryTerm_iarchive,MathWorks::lxe::function_descriptor>::load_object_data+00493568 [123] 0x0000000017ee091c bin\win64\pgo\m_lxe.dll+01378588 mwboost::archive::detail::iserializer<mwboost::archive::binaryTerm_iarchive,MathWorks::lxe::function_descriptor>::load_object_data+00496608 [124] 0x0000000017ee1c92 bin\win64\pgo\m_lxe.dll+01383570 mwboost::archive::detail::iserializer<mwboost::archive::binaryTerm_iarchive,MathWorks::lxe::function_descriptor>::load_object_data+00501590 [125] 0x0000000017ee28f8 bin\win64\pgo\m_lxe.dll+01386744 mwboost::archive::detail::iserializer<mwboost::archive::binaryTerm_iarchive,MathWorks::lxe::function_descriptor>::load_object_data+00504764 [126] 0x0000000017ee1ddf bin\win64\pgo\m_lxe.dll+01383903 mwboost::archive::detail::iserializer<mwboost::archive::binaryTerm_iarchive,MathWorks::lxe::function_descriptor>::load_object_data+00501923 [127] 0x0000000017ee1ede bin\win64\pgo\m_lxe.dll+01384158 mwboost::archive::detail::iserializer<mwboost::archive::binaryTerm_iarchive,MathWorks::lxe::function_descriptor>::load_object_data+00502178

This error was detected while a MEX-file was running. If the MEX-file is not an official MathWorks function, please examine its source code for errors. Please consult the External Interfaces Guide for information on debugging MEX-files.

[LaurenceWETI]

Hello @bjonkman, Hello @jjonkman , As I mentioned above I could vary the blade element masses within a given simulation. The change of the blade element masses generates an additional torque from the change in the angular moment. This torque. T_cor, can also be expressed in terms of Coriolis force, F_cor, acting on the variable radius of the moved masses, R_var, as described in the following equation.

T_cor=3∙F_cor∙R_var

As @jjonkman mentioned in previous comment:

I couldn’t find that terms in ElastoDyn source code that account the Coriolis force. I see that in ElastoDyn.f90\FUNCTION SignLSSTrq( p, m )the moment on the low-speed shaft MomLPRotis calculated. Is it correct to add the Coriolis at this point:

Where u%ExternalRvar and u%ExternalFcor are the variable radius and the Coriolis force from Simulink, respectively. Can you help me how to add the Coriolis torque the low speed shaft torque?

[jjonkman]

Dear @LaurenceWETI,

I would not change FUNCTION SignLSSTrq() as you propose. The Coriolis and other forces are intrinsically calculated within ElastoDyn. If you are changing the blade-element masses at each time step before the main dynamic calculations take place, the impact of these masses on the inertial forces should be intrinsically included.

Best regards,

[LaurenceWETI]

Dear @jjonkman,

Thank you for your replay. Exactly for the same reason that the change of blade-element masses should take place at each time step and before the main dynamic calculations take place, I called the masse changing subroutines at the beginning of SUBROUTINE ED_CalcOutput\ElastoDyn.f90. May I briefly summarize the flow of the call orders in the following figure

Where Subroutine Flywheel_Ini(p) called only at t=0 for initialization, Subroutine Flywheel(p, u) is called at every time step to overwrite the blade element masses, and Subroutine UpdateCoeff(p, ErrStat, ErrMsg) is called after the blade masses are changed to update the parameters of Subroutine Coeff(p,InputFileData, ErrStat, ErrMsg). In order to enable the overwriting of the parameter data type p% I changed the intent of the parameter data structure from only IN to INOUT

Did I change the masses at the point before the main dynamic calculations tykes place?

Can you referee to the please in ElastoDyn code where is the Coriolis force calculated?

Is the Coriolis force that you mentioned calculated due to the change in the blade mass or because of the tower side to side movement?