Simulink Model simulation: huge time differences between simulation "arrangements"

Hi,

this is my first post here and I am a MATLAB newbie...

I "inherited" a certain nonlinear system described via a Simulink "schematic", consisting essentially of interlinked:

• Matlab Function blocks, implementing a static nonlinearity (using exp,abs,phase...)
• First order filters described in the s-domain

So far, with ChatGPT's help I should not be ashamed to say, I managed to create a staircase input for my model within a *.m script, and through it, launch a time-domain simulation via:

%% --- Model & Common Inputs ---

model = 'my_simulink_model';

[..]

ds1 = Simulink.SimulationData.Dataset;

ds1 = ds1.addElement(Pin_ts1,'Pin');

[..]

simIn1 = Simulink.SimulationInput(model);

simIn1 = simIn1.setExternalInput(ds1);

simIn1 = simIn1.setModelParameter('SolverType','Variable-step',...

'Solver',solver,...

'RelTol',RelTol,...

'AbsTol',AbsTol,...

'StopTime',num2str(tf1));

simOut1 = sim(simIn1);

This way, by setting solver type (it's a nonlinear "stiff" system, I'm using ode15), variable-step and the rest, I managed to get a satisfyingly fast and accurate simulation.

I then ran into issues when I wanted to extract a linearized version of the system at a certain timepoint (I'm not asking about that here, I'll do separately in case) and I could not find a working answer from ChatGPT, so I decided I needed to understand the tool better...

Since what I could find about linearization in help is all GUI/Simulink based (I do have the Control Design Toolbox license, btw, I bought exactly for this purpose), I then decided to learn to simulate from the Simulink interface directly...

I then instantiated my model in another Simulink canvas, created the various constant inputs to the system, and added a time-varying staircase input which, at least in my understanding, should be equivalent to the one I created programmatically.

The code to create the staircase is:

t_step1 = 50e-3;

I_max = 9.8e-3;

I_min = 0;

N1 = 50;

I_HTR_sweep1 = linspace(I_max, I_min, N1);

tf1 = t_step1 * N1;

t_edges1 = 0:t_step1:tf1;

t_plot1 = reshape([t_edges1(1:end-1); t_edges1(2:end)],1,[]);

I_plot1 = repelem(I_HTR_sweep1, 2)';

% Timeseries

I_HTR_ts1 = timeseries(I_plot1, t_plot1);

I don't know whether this is MATLAB coding at its finest, but it does make sense to me and it results in a descending staircase of t_step1 seconds plateau for each step.

In the Simulink/GUI approach, I feed to the same model port a "repeating sequence stair" block, whose vector expression I've filled with:

linspace(9.8e-3,0,50)

and "sample time" with a variable I created on purpose, named t_step and set at 50e-3.

I also changed the setting in the "model setup" tab, which is responsible for solver options and such - To the values I have programmatically set before.

However - now the simulation takes AGES to complete! Actually, it takes so long that I got bored before I could see the first step happening.

Now, since the model is absolutely the same, I am assuming that something BIG is missing from my Simulink/GUI setup which isn't or is set automatically "right" when the model is simulated from a script.

Do you have any suggestions and/or hints on what to look for that could cause such vastly different behaviour?

Despite the fact that the time step is variable in both cases, the GUI based simulator seems to take very, very tiny steps. Which is bizarre, because the time constants of the system are much larger, so I wonder where am I driving it nuts?

[Sam Chak]

Hi @Michele

I plotted the staircase signal from your code. However, I am unsure whether the ode15s solver in Simulink can handle this "stiff" situation. The slope of the perfectly right-angled staircase at each time interval of 0.05 is infinite (∞). ODE solvers like ode15s can approximate the Jacobian matrix internally using the finite difference method. However, from the t_plot1 data, I anticipate that there will be many division-by-zero events.

t_step1  = 50e-3;
I_max    = 9.8e-3;
I_min    = 0;
N1       = 50;
I_HTR_sweep1 = linspace(I_max, I_min, N1);
tf1      = t_step1 * N1;
t_edges1 = 0:t_step1:tf1;
t_plot1  = reshape([t_edges1(1:end-1); t_edges1(2:end)],1,[]);
I_plot1  = repelem(I_HTR_sweep1, 2)';

t_plot1(1:8)

ans = 1×8

0 0.0500 0.0500 0.1000 0.1000 0.1500 0.1500 0.2000

<mw-icon class=""></mw-icon>

<mw-icon class=""></mw-icon>

plot(t_plot1, I_plot1, '.'), grid on, 
title('Descending staircase signal')
xlabel('t'), ylabel('I')

●

Have you tried something that is mathematically simpler?

x   = linspace(0, 2.5, 2501);
amp = 0.01;     % amplitude
y   = amp*(1 - floor(x/0.05)/48);
plot(x, y), grid on
ylim([0, 0.01])

[Michele]

Thank you @Sam Chak,

that's a nice suggestion! The ChatGPT generated staircase, with time instants where the input has two values, might cause issues down the line. It doesn't in this particular instance, meaning that I don't see no warnings and the simulation runs fast and smooth, but it might be that I need to increase accuracy parameters to avoid numerical ringing - as I did - and it's the input shape that's causing issues, not the actual system characteristics... Thanks for the tip!

Answer 1

[Michele]

Alright, I think I found the culprit, thanks to an interaction with a MATLAB support representative :)

When instantiatiing the model in the "test bench", I took care to set it up to use the intended solver, variable step and the rest, like I did in the programmatic approach.

However, I was changing the simulation properties of the test bench, while the properties of the so called "referenced model", just a few pixels down the menu, were left unchanged. These happened to be the "wrong" ones, with fixed-step and automatically chosen solver.

When I finally got to change those to the intended ones, the simulation ran smoothly and quickly.

Answer 2

[Ritika Thusoo]

Hi,

You can check a couple of things to understand why simulation takes ages for you.

First, check the sample time that you have selected. Simulink® allows you to specify a block sample time directly as a numerical value or symbolically by defining a sample time vector. You can read about this from the following documentation page:

https://www.mathworks.com/help/simulink/ug/how-to-specify-the-sample-time.html?searchHighlight=sample+time+simulation&s_tid=srchtitle_support_results_1_sample+time+simulation

Next, you can check the type of Solver that is better suited for your system considering that you’re also working with a linearised model at one point. Check the following documentation page to read more about the solver:

https://www.mathworks.com/help/simulink/gui/solver.html?s_tid=srchtitle_site_search_2_solver

In order to decide which solver to select for the GUI Simulation you can check out the following documentation:

https://www.mathworks.com/help/simulink/gui/solver-pane.html?searchHighlight=solver+for+GUI+simulation&s_tid=srchtitle_support_results_2_solver+for+GUI+simulation

Furthermore, you can check zero crossing detection in your system which might cause additional time in simulation. You can read about this on the following documentation page:

https://www.mathworks.com/help/simulink/ug/zero-crossing-detection.html?searchHighlight=zero+order+detection&s_tid=srchtitle_support_results_1_zero+order+detection

https://www.mathworks.com/help/simulink/gui/enablezerocrossingdetectionforfixedstepsimulation.html?searchHighlight=solver+for+GUI+simulation&s_tid=srchtitle_support_results_5_solver+for+GUI+simulation

[Michele]

Hi!

Thanks for your detailed and informative answer, I certainly need to read all your pointers :)

Also, sorry for the late reaction, I was out for a couple of days.

I checked the sample time of the block through the Model Data Editor and all ports are set to -1, i.e. "inherited". The system is - at this modeling stage - fully continuous, no time discretization other than the one necessary to produce numerical results at simulation time. So I'm thinking that this might play havoc with the staricase input "repeating sequence stair" block I'm giving it.

The solver and step settings should be equal between the script based and the GUI based approach, they're ode15s and variable-step in both cases.

As a way to explore the issue, I started adding the internal elements of the model, one by one, in a separate canvas, checking for "the culprit" that would explode my sim time. Bit by bit, I added the complete model to this new canvas, and it simulates as fast as the one I call from script!

So, right now I have:

• A script that loads my model, feeds it a certain input via the Dataset structure, sets various simulator options, and goes
• A Simulink canvas with the model represented as a box, a staircase input where it needs to be, simulator options as in first case but set with the GUI, that takes ages to simulate
• A Simulink canvas with the same staircase input, but this time with the model internal arrangement flattened out. This simulates as fast as the first one.

There probably is some setting that's escaping me for the second scenario, where I try to use my model as a block in a larger test bench.

Since the third option works fine, I'll go with it for now and look further to the linearization operation through the GUI, just because it's more pressing now. But I'll come back to the topic to understand what's missing in my second scenario to have it work correctly.

Thanks a lot for your help!

Michele