Why use ode4 solver in simulink for simulation with FAST ?

Wind & Water Computer-Aided Engineering Software Tools
1

Hi,

First, I would like to thank you to provide the FAST software.

My name is Benjamin Maréchal. I’m a engineer at D-ICE engineering and we are working on a controller for off-shore wind turbine.

We are using FAST (v7.02.00d-bjj) in the simulink environment using the S-Function of FAST.

In the FAST documentation, it says:
“The fixed step solver, ode4, most closely emulates the solver used by FAST.”

Now, I looked at the FAST source code which is used to generate the FAST_SFunc.mex file and I see that the S-Function does not provide any state nor derivative when simulink is asking for them.
The concerned file is “FASTGateway.f90” and the concerned lines of code are:

   !=================================================================================================
   ! Set the MDLsizes vector, which determines Simulink model characteristics
   !=================================================================================================

      MDLsizes(1) = 0                        ! number of continuous states
      MDLsizes(2) = 0                        ! number of discrete states
      MDLsizes(3) = NDOF + NumOuts           ! number of outputs: qdotdot + NumOuts
      MDLsizes(4) = 2 + 2 + NumBl + NDOF*2   ! number of inputs:  Gen(2), Yaw(2), BlPitch, q, qdot
      MDLsizes(5) = 0                        ! number of discontinuous roots in the system
      MDLsizes(6) = 1                        ! Direct feedthrough of U
         ! *** Output argument y2 contains the initial states (ptr_X0) ***

      IF (NLHS > 1) THEN  ! [y1, y2]=FAST_SFunc();                                ! bjj: Since we have no states, this creates an empty array
         PLHS(2) = mxCreateDoubleMatrix(MDLsizes(1)+MDLsizes(2), 1, mxREAL)
      ENDIF
         CASE (1, -1)

            !-----------------------------------------------------------------------------------------
            !     Return state derivatives: mdlDerivatives()
            !-----------------------------------------------------------------------------------------

               ! We don't have any so just create an empty array and return;

            IF (NLHS >= 0) THEN
               PLHS(1) = mxCreateDoubleMatrix(MDLsizes(1), 1, mxREAL)
            ENDIF

I must add that the variable MDLSizes does not change.

Since the S-Function does not return the state to simulink (only an empty array), I don’t understand the interest of using ode4 solver.
My opinion is that, in this particular case, using the ode4 solver is just increasing the number of calls made by simulink to the S-Function.
Let’s say for example that I have a step time for my simulation: DT = 0.05s. Then, if simulink uses ode4 solver, it will call the S-Function every 0.025s.

I based what I wrote on what I understood of the comportment of simulink with S-Functions, here is a link which explains it:
https://fr.mathworks.com/help/simulink/sfg/how-s-functions-work.html

Now, I have a problem.
I did a little experimentation to validate my deductions.

I launch “OpenLoop.mdl” which is included in FAST files and which is using ode4 solver. The simulation works.
After that, I modified 'OpenLoop.mdl" so that it should use ode1 (euler) solver. I also changed the “Fixed-step size (fundamental sample time)” parameter in the solver configuration : DT/2.
I though it would give me the same result that the first simulation but FAST stopped after 1.7 second. I got this error :

So I have two questions:

  • Why the FAST documentation recommends to use ode4 ?
  • Why don’t I get the same results in the two simulations explained above ?

Thank you for reading this long post. I hope there are simple explanations for my observations.

Benjamin Maréchal

2

Hi again,

I found what I was missing.

Here is the simulink view of how FAST is integrated as a S-Function:

I didn’t notice there were two integrators after the S-Function. Because of this two integrators, Simulink needs to use a solver with continuous integration.

Bye,
Benjamin