There are several possibilities that could be causing your simulation to run slowly:
1. You have a MATLAB Function Block - When a MATLAB Fcn block is present, the MATLAB interpreter is called at each time step. This drastically reduces the simulation speed. So, you should use the built-in Fcn block whenever possible.
2. S-functions written as MATLAB files - S-functions are evaluated at every time step. By converting the MATLAB file to a MEX-file, performance can be greatly improved. Also, whenever possible, use the built-in blocks to model the S-functions.
3. Small step sizes or sample times (or a mixture of sample times that are not multiples of each other). It is important to keep the step size small enough to capture important events during the simulation. Conversely, a step size that is too small will produce more output points than necessary and slow down the simulation.
4. The maximum step size is too small. If you changed the maximum step size, try running the simulation with the default value (set to auto).
5. You may have asked for too much accuracy. The default relative tolerance (0.1% accuracy) is usually sufficient. For models with states that go to zero, if the absolute tolerance parameter is too small, the simulation may take too many steps around the near-zero state values. For more information on Error Tolerances, see page 5-13 of the Using Simulink Manual. Please remember that all tolerance values to be entered are absolute values. So the default relative tolerance value when it is set to 1e-3 , it means the relative tolerance is 0.001 or in terms of percentage it is 0.1%.
6. The time scale may be too long. Reduce the time interval.
7. Your model includes a Memory block. Using a Memory block causes the variable-order solvers (ode15s and ode113) to be reset back to order 1 at each time step.
8. Any masked blocks in the Extras library that incorporate one of the three above (i.e., graph scopes, autoscaling scopes, spectrum analyzers, etc). Unmask the blocks to see if they call an S-function.
9. Built in-scope blocks, although their effect is most likely very small.
10. Algebraic loops - The solutions to algebraic loops are iterative and performed at every time step. Therefore, they severely degrade speed. For more information on Algebraic loops, see page 3-18 of the Using Simulink Manual.
11. Do not feed a White Noise block into an Integrator. For continuous systems use the band-limited white noised block in the Extras/Sources library.
12. The problem may be stiff but you are using a non-stiff solver. Try using ode15s.
13. You may be hitting a zero crossing continuously and the simulation is getting 'stuck' causing it to take a very long (and possibly infinite time to complete). To fix this, you can disable the zero crossing detection. This can be done by selecting the Disable zero crossing detection option on the Advanced pane of the Simulation Parameters dialog box. In R11, this can be done by going under the Simulation -> Parameters -> Diagnostics section of the model.
For more information on zero crossing detection, please reference page 5-44 of the "Using Simulink" manual.
14. You may also want to try setting the Model Parameter Configuration dialog box so that your Simulink model uses the "Inline Parameters" option. Selecting this option enables Simulink to treat the specified parameters as constants, thereby speeding up the simulation. Please see page 5-30 of the "Using Simulink" manual for more information.
15. The Simulink Accelerator increases the simulation speed of your model by accelerating model execution and using model profiling to help you identify performance bottlenecks.
16. The simulation speed could also be affected if the model is very complex (involves a lot of model referencing and subsystems) and involves a lot of data logging. Disabling the data logging feature also improves simulation speed.
Otherwise, simulation speed is governed by the system (i.e., processor, RAM, amount of swapping that is occurring, etc.)
There are a few things to consider with regard to simulation speed:
- Graphics engine speed
- CPU speed
- Amount of memory
In light of that, here are a few hints:
- If you have any graph scopes or other visual output devices open during simulation, this will degrade performance.
- Performance is directly proportional to CPU speed.
- If the memory used by variables stored during the simulation is greater than the amount of RAM on the system, performance will be poor. The solution is to run smaller simulations or add more memory.