Why does using set_param() in a for loop run Simulink models so fast when compared with the sim() function?

Hi,

For the longest time I have been using the sim() function within for loops to programatically execute Simulink simulatons with iteratively changing inputs. Per iteration, the loop hangs while the simulation is running (which seems to take the same amount of time as if I were to manually run a single simulation).

However, today I was doing some reading and found the set_param() function, which can also be used to start simulations. This no longer causes the for loop to hang and seems to just send 'i' number of calls to run the simulation almost at once.

My question is, why is set_param() so much faster than sim()?

Is this running the simulations in parallel or is it something more else, like defaulting to some kind of accelerated mode with a call to set_param()? I did have a try changing between execution modes, fast restart, etc. but sim() still seems to run one-by-one very slowly.

For reference, here is the sort of code I am using to run my simulations using a script:

for i = 1:length(f_xg)

trans(i,1) = i;

trans(i,2) = f_xg(i);

w_xg = 2*pi*f_xg(i); %Convert input frequency to [rad/s]

ddx_g = -x_g*w_xg^2; %Calculate acceleration input amplitude [m]

%sim('Multi_layer_isolator')

set_param('Multi_layer_isolator',"SimulationCommand","start");

end

Thanks in advance for any contributions.

p.s. If you found this post looking into how to speed up your simulations, you may be in luck. This has resulted in my simulations completing within 9% of the time needed previously, reducing average execution time down from 6.5 sec per to 0.6 sec per. With 100 iterations, for example, that is 10.8 mins down to 1 min flat. Amazing!

Cheers

[Walter Roberson]

If I understand correctly, "start" is able to proceed from the existing state, without having to re-initialize.

However, you would typically need to configure an end time if you are stepping state.

If you are wanting to run the same simulation over a number of different values for the same parameters then parsim

[Matt]

Thanks for the reply, Walter.

I have since played a bit more with the fast restart function which should prevent re-initialization, however sim() still seems to run very slowly. With fast restart disabled, set_param() seems to run the simulations in parallel (or at least presents a progress bar that reflects the progress of the total number of requested iterations). Either way, set_param() wins.

I'll take a look at parsim() to see if I can get even better speeds. Thanks for the suggestion there.

Cheers

[Paul]

@Matt

At the risk of asking a silly question, did you verify that that results from your loop using sim or set_param are exactly the same? I don't see why they wouldn't be, but thought I'd ask anyway.

Can you expand on your comment that set_param seems to run the simulations in parallel when fast restart is enabled? I don't understand how that could be the case in the construct of the for loop in your code, and so would like to learn more about it. What is the evidence that multiple simulations may be running in parallel? Is this progress bar a result of the set_param command itself, or is it something you've constructed in your loop, using waitbar for example?

Fast restart can also be used with sim.

Also, it probaby won't address your question, but you may be interested in the workflow using the Simulink.SimulationInput object. Check its doc page for more info.

@Walter Roberson

Based on my reading of the doc, "start" is used to start a simulation that is not currently running. "continue" is used to resume a simulation that's paused, if that's what you meant by "proceed from the existing state."

[Matt]

Hi @Paul,

Thanks for your reply. Regarding the output, yes, both set_param and sim yield the exact same results. I was a bit shocked by the performance so I too questioned this first.

Now, for my interpretation of what's happening, with or without fast restart enabled, set_param always yields a result more quickly. As for why I feel the simulations run in parallel, manually running a single simulation or using the sim function both take the same amount of time. However, set_param pushes out the results of numerous simulations all at once at a substantially faster rate. It makes me wonder if Simulink just handles a queue of calls by default by running them in parallel. In terms of my script, the calls to set_param occur very quickly, e.g. 100 loops within a fraction of a second. The progress bar I am referring to is the one on the bottom of the Simulink window when opened.

Thanks for the tip about the SimulationInput object – while researching this whole set_param business, I realised there are numerous ways to get data in and out of Simulink which I never considered. I’ve just been declaring variables in the workspace and referencing them in Simulink models to get data in, then using SimOut blocks to retrieve data following a simulation. Seems like I’ve been taking somewhat of a crude approach.

Kind Regards

Matt

Answer 1

[Harimurali]

Hi Matt,

I understand that you want to know why using the “set_param” function inside a for loop run Simulink models much faster than when simulated using the “sim” function.

The “sim” function supports fast restart which ensure that the model is only compiled once, and simulation is not terminated when iterative simulations are performed. There are a few cases when a simulation does not support fast restart. Please refer to the Limitations section of the following documentation to learn about the limitations of fast restart:

https://www.mathworks.com/help/releases/R2018b/simulink/ug/how-fast-restart-improves-iterative-simulations.html

Without fast restart, iterative simulations run using the “sim” function will appear slow.

Both the “set_param” and “sim” functions run simulations sequentially, but “set_param” may appear faster inside a for loop due to the following reasons:

• Overhead reduction: By using "set_param" to modify simulation parameters inside the loop, you avoid the overhead of re-initializing the model and recompiling the generated code, which can occur when calling "sim" repeatedly within the loop. This can result in some performance improvement.
• Caching effects: When "set_param" is used inside a loop, the model and its associated data may be cached in memory, reducing the overhead of loading, and initializing the model for each iteration. This can lead to faster execution times compared to running "sim" repeatedly within the loop.

Please refer the following links for more information on running simulations programmatically:

https://www.mathworks.com/help/releases/R2018b/simulink/ug/using-the-sim-command.html

Hope this helps.

[Matt]

Thanks @Harimurali, I believe given fast restart not offering the same performance boost that is found with set_param, it must be the 'chaching effects' that result in the rapid speed boost. While I cannot verify this is definitely why it is faster, I feel this is a reasonable answer.