Improving Simulation Performance in Simulink

Transcription

1 See more articles and subscribe at mathworks.com/newsletters. Improving Simulation Performance in Simulink By Seth Popinchalk, MathWorks Whatever the level of complexity of the model, every Simulink user wants to improve simulation performance. This article presents tips and techniques to help you make the most of your memory and processing power. It covers the following topics: Selecting a simulation mode Identifying simulation bottlenecks Modifying and simplifying your model Running multiple simulations in parallel While every situation is unique, the techniques described here can be applied to a wide range of projects. Use them as a list of things to try whenever you need to increase the speed of your simulations. Selecting a Simulation Mode In Simulink, three modes affect simulation performance: Normal, Accelerator, and Rapid Accelerator (Figure 1). As their names imply, Accelerator is faster than Normal, and Rapid Accelerator is faster still. Each increase in speed typically means sacrificing another capability for example, flexibility, interactivity, or diagnostics. In many cases, if you can work without one of these capabilities at least temporarily simulation performance will improve. Figure 1. Simulink simulation modes. In Normal mode, Simulink interprets your model during each simulation run. If you change your model frequently, this is generally the preferred mode to use because it requires no separate compilation step. In Accelerator mode, Simulink compiles a model into a binary shared library or DLL where possible, eliminating the block-to-block overhead of an interpreted simulation in Normal Mode. Accelerator mode supports the debugger and profiler, but not runtime diagnostics. In Rapid Accelerator mode, Simulink compiles a standalone executable for the model, which can run on a separate processing core. You can use Rapid Accelerator mode only when the full model is capable of generating code, and this mode restricts interaction with the model during simulations. For example, Rapid Accelerator mode does not support debugging. As with Accelerator mode, it s best to use Rapid Accelerator mode when your simulations take much more time than the one-time cost of compilation. Learn more about how the acceleration modes work, choosing a simulation mode, and comparing performance. 1

2 You can trade off compile-time speed for simulation speed by setting the compiler optimization level. Compiler optimizations for accelerations are disabled by default. Enabling them (Figure 2) will accelerate simulation runs but result in longer build times. The speed and efficiency of the C compiler used for Accelerator and Rapid Accelerator modes also affects the time required in the compile step. Learn more about setting the compiler optimization level. Figure 2. Compiler optimizations. When Accelerator Modes Might Not Substantially Improve Performance Accelerator or Rapid Accelerator mode may not improve performance much in the following situations: Your model s algorithm is primarily contained in a few complex blocks, such as the Fast Fourier Transform block or lookup tables. A small model may run slower in an accelerator mode because native blocks are highly optimized. In contrast, a model with many basic blocks is more likely to benefit from compilation. Your model contains compiled code, such as code from S-functions, Stateflow blocks, and MATLAB functions. Using the compilation step will not speed the model further. Your model contains blocks that cannot be compiled, such as Interpreted MATLAB Function blocks. Your simulation runs include initialization or termination phases. Because the accelerator modes work only on the simulation phase of each run, they may not offer much improvement if they require time-consuming initialization or termination phases. For details, see the Accelerating the Initialization Phase section of this article. Your system lacks sufficient memory. Memory issues can slow simulations, particularly for large models running on 32-bit operating systems. You can monitor Simulink memory usage with the sldiagnostics function. If you use a 32-bit Windows system, consider using the Windows 3GB startup switch or switching to a 64-bit system. You log large data sets. When logging large amounts of data (for example, in models that include the Workspace I/O, To Workspace, To File, or Scope blocks), use decimation or limit the logged output to the last part of the simulation. Avoid logging redundant data (for example, log the time only once) and extraneous data (for example, log integer values instead of doubles when feasible). To File blocks save data incrementally in an array format, so use them for logging tasks when managing memory usage for long simulations is a priority. Learn more about exporting simulation data. Identifying Simulation Bottlenecks If the acceleration modes do not provide the simulation speed you require, use the sldiagnostics function, Simulink Profiler, and Simulink Model Advisor to identify and eliminate simulation bottlenecks. The sldiagnostics function examines your Simulink model without running it and displays diagnostic information, including how many instances of each block are in your model and how much time and memory compilation requires. 2

3 As you review the results produced by sldiagnostics, note how many interpreted MATLAB functions your model uses (Figure 3). Because data exchange between MATLAB and Simulink passes through several software layers, Interpreted MATLAB Function blocks usually slow simulations, particularly if the model needs many data exchanges. Additionally, because interpreted MATLAB functions cannot be compiled, Interpreted MATLAB Function blocks impede attempts to use an acceleration mode to speed up simulations. Figure 3. Sample output of sldiagnostics. The model uses three MATLAB Function blocks. Simulink Profiler lets you quantify exactly how much time each phase of your simulation takes and how much time each block takes to simulate (Figure 4). This procedure can generate a great deal of data. To minimize the amount of data that you need to review, focus on those methods that consume the most time and those that are most frequently called. Learn more about capturing performance data. Figure 4. A sample Simulink Profiler report. Using MATLAB Functions Instead of Interpreted MATLAB Function Blocks To call a MATLAB function within your Simulink model, use a MATLAB Function block instead of an Interpreted MATLAB Function block or a MATLAB S-function. (The MATLAB Function block was previously called the Embedded MATLAB block, and the Interpreted MATLAB Function block was previously called the MATLAB Function block.) The MATLAB Function is the faster alternative. It supports the generation of embeddable C code, and does not incur the data packaging overhead required by the Interpreted MATLAB Function block. While the MATLAB Function block does not support all MATLAB functions, the subset of the MATLAB 3

4 language that it does support is extensive. By replacing your interpreted MATLAB code with code that uses only this embeddable MATLAB subset, you can significantly improve performance. To quickly find all the Interpreted MATLAB Function blocks in your model, open Model Explorer and search your model by Block Type, selecting MATLABFcn as the type. Learn more about working with the MATLAB Function block. Modifying and Simplifying Your Model Most of the techniques described so far require few, if any, changes to the model itself. You can achieve additional performance improvements by applying techniques that involve modifications to the model. Accelerating the Initialization Phase Large images and complex graphics take a long time to load and render. As a result, masked blocks that contain images might make your model less responsive. To accelerate the initialization phase of a simulation, remove complex drawings and images. If you don t want to remove an image, you can still improve performance by replacing it with a smaller, low-resolution version. To do this, use the Mask Editor and edit the icon drawing commands to change the image that is loaded by the call to image(). Learn more about using the Simulink Mask Editor. When you update or open a model, Simulink runs the mask initialization code. If you have complicated mask initialization commands that contain many calls to set_param, consider consolidating consecutive calls to set_param()into a single call with multiple argument pairs. This can reduce the overhead associated with these calls. Learn more about mask code execution. If you use MATLAB scripts to load and initialize data, you can often improve performance by loading MAT-files instead. The drawback is that the data in a MAT-file is not in a human-readable form, and can therefore be more difficult to work with than a script. However, load typically initializes data much more quickly than the equivalent script. Learn more about loading data from a MAT-file into your workspace. Reducing Interactivity In general, the more interactive the model, the longer it will take to simulate. The tips in this section illustrate ways to improve performance by giving up some interactivity. Enable inline parameters optimization. When you enable this optimization in the Optimization pane of the Configuration Parameters dialog box, Simulink uses the numerical values of model parameters instead of their symbolic names. This substitution can improve performance by reducing the parameter tuning computations performed during simulations. Learn more about inlining parameters. Disable debugging diagnostics. Some enabled diagnostic features noticeably slow simulations. You can disable them in the Diagnostics pane of the Configuration Parameters dialog box. Note: Running the array bounds exceeded and solver data inconsistency diagnostics can cause a noticeable slowdown in model run-time performance. Disable MATLAB debugging and use BLAS library support. After verifying that your MATLAB code works correctly, disable debugging support. In the Simulation Target pane of the Configuration Parameters dialog box, disable debugging/animation, overflow detection, and echoing expressions without semicolons (Figure 5). Learn more about using the Simulation Target pane. 4

5 Figure 5. The Simulation Target pane of the Configuration Parameters dialog box. If your simulation involves low-level MATLAB matrix operations, enable the Basic Linear Algebra Subprograms (BLAS) Library feature to make use of highly optimized external linear algebra routines. Learn more about speeding up simulation with the basic linear algebra subprograms (BLAS) library. Disable Stateflow animations. By default, Stateflow charts highlight the current active states and animate the state transitions that take place as the model runs. This feature is useful for debugging, but it slows the simulation. To accelerate simulations, either close all Stateflow charts or disable the animation. Similarly, if you re using Simulink 3D Animation, SimMechanics visualization, FlightGear, or another 3D animation package, consider disabling the animation or reducing scene fidelity to improve performance. Learn more about speeding up simulation in Stateflow. Adjust viewer-specific parameters and manage viewers through enabled subsystems. If your model contains a scope viewer that displays a large number of data points and you can t eliminate the scope, try adjusting the viewer parameters to trade off fidelity for rendering speed. Be aware, however, that by using decimation to reduce the number of plotted data points, you risk missing short transients and other phenomena that would be obvious with more data points. You can place viewers in enabled subsystems to more precisely control which visualizations are enabled and when. Learn more about how scope signal viewer parameter settings can affect performance. Reducing Model Complexity Simplifying your model without sacrificing fidelity is an effective way to improve simulation performance. Here are three ways to reduce model complexity. Replace a subsystem with a lower-fidelity alternative. In many cases, you can simplify your model by replacing a complex subsystem model with one of the following: A linear or nonlinear dynamic model created from measured input-output data using System Identification Toolbox A high-fidelity, nonlinear statistical model created using Model-Based Calibration Toolbox A linear model created using Simulink Control Design A lookup table Learn more about working with lookup tables, optimizing breakpoint spacing in lookup tables, and optimizing generated code for lookup table blocks. You can maintain both representations of the subsystem in a library and use variant subsystems to manage them. Learn more about using configurable subsystem blocks. Reduce the number of blocks. When you reduce the number of blocks in your model, fewer blocks will need to be updated during simulations, leading to faster simulation runs. Vectorization is one way to reduce your block count. For example, if you have several parallel signals that undergo a similar set of computations, try combining them into a vector and performing a single computation. 5

6 Another way is to simply enable the Block Reduction optimization in the Optimization > General section of the configuration parameters. Use frame-based processing. In frame-based processing, samples are processed in batches instead of one at a time. If your model includes an analog-to-digital converter, for example, you can collect the output samples in a buffer and process the buffer with a single operation, such as a fast Fourier transform. Processing data in chunks in this way reduces the number of times that blocks in your model must be invoked. In general, scheduling overhead decreases as frame size increases. However, larger frames consume more memory, and memory limitations can adversely affect the performance of complex models. Experiment with different frame sizes to find one that maximizes the performance benefit of frame-based processing without causing memory issues. Choosing and Configuring a Solver Simulink provides a comprehensive library of solvers, including fixed-step and variable-step solvers to handle stiff and nonstiff systems. Each solver determines the time of the next simulation step and applies a numerical method to solve ordinary differential equations that represent the model. The solver you choose and the solver options you specify will affect simulation speed. Learn more about choosing a solver. Select a solver that matches the stiffness of your system. A stiff system has both slowly and quickly varying continuous dynamics. Implicit solvers are specifically designed for stiff problems, whereas explicit solvers are designed for nonstiff problems. Using nonstiff solvers to solve stiff systems is inefficient and can lead to incorrect results. If a nonstiff solver uses a very small step size to solve your model, it may be because you have a stiff system. Choose a variable-step or fixed-step solver based on your model s step size and dynamics. Exercise caution when deciding whether to use a variable-step or fixed-step solver; otherwise, your solver could take additional time steps to capture dynamics that are not important to you, or it could perform unnecessary calculations to work out the next time step. In general, simulations run with variable-step solvers are faster than those run with fixed-step solvers: You use fixed-step solvers when the step size is less than or equal to the fundamental sample time of the model. With a variable-step solver, the step size can vary because variable-step solvers dynamically adjust the step size. As a result, the step size for some time steps is larger than the fundamental sample time, reducing the number of steps required to complete the simulation. As a rule, choose a fixed-step solver when the fundamental sample time of your model is equal to one of the sample rates. Choose a variable-step solver to capture continuous dynamics, or when the fundamental sample time of your model is less than the fastest sample rate. Decrease the solver order. Decreasing the solver order improves simulation speed because it reduces the number of calculations that Simulink performs to determine state outputs. Of course, the results become less accurate as the order of the solver decreases. The goal is to choose the lowest solver order that will produce results that meet your accuracy requirements. Increase the solver step size or the error tolerance. Similarly, increasing the solver step size or increasing the solver error tolerance usually increases simulation speed at the expense of accuracy. Such changes should be made with care because they can cause Simulink to miss potentially important dynamics during simulations. Learn more about speeding up the simulation and improving accuracy. Disable zero-crossing detection. Variable-step solvers dynamically adjust the step size, increasing it when a variable changes slowly and decreasing it when a variable changes rapidly. This behavior causes the solver to take many small steps in the vicinity of a discontinuity because this is when a variable is rapidly changing. Accuracy improves, but it often comes with long simulation times. To avoid the small time steps and long simulations associated with these situations, Simulink uses zero-crossing detection to accurately locate such discontinuities. For systems that exhibit frequent fluctuation betweens modes of operation a phenomenon known as chattering this zero-crossing detection can actually have the opposite effect and slow simulations. In these situations, it may be possible to adjust zero-crossing detection to improve performance. 6

7 Note: Zero-crossing detection can be enabled or disabled for specific blocks in the model. You can improve performance by disabling zero-crossing detection for blocks that do not affect the accuracy of the simulation. Learn more about when to enable zero-crossing detection. Saving the Simulation State Engineers typically simulate a Simulink model repeatedly for different inputs, boundary conditions, and operating conditions. In many situations, these simulations share a common startup phase in which the model transitions from its initial state to some other state. An electric motor, for example, may be brought up to speed before various control sequences are tested. Using the Simulink SimState feature, you can save the simulation state at the end of the startup phase and then restore it for use as the initial state for future simulations. This technique does not improve simulation speed per se, but it can reduce total simulation time for consecutive runs because the startup phase needs to be simulated only once. Learn more about saving and restoring the simulation state as the SimState. Running Multiple Simulations in Parallel You can reduce the total amount of time it takes to run multiple independent simulations by distributing simulation tasks among multiple processing cores with Simulink and Parallel Computing Toolbox. You can further reduce overall simulation time by using MATLAB Distributed Computing Server to run the simulations on a computer cluster. Common use cases for running simulations in parallel include Monte Carlo analysis and design optimization. For example, you might set up a Monte Carlo simulation in which you vary the value of a parameter across a predetermined range. You can then perform simulations for each parameter value independently and in parallel on multiple cores. You can parallelize many of the tasks involved in design optimization, including estimating model parameters from test data, tuning controller gains to achieve a desired response, optimizing design parameters, performing sensitivity analysis, and performing robustness analysis. The total simulation time decreases as the number of processors in use increases (Figure 6). 7

8 Figure 6. Speedup (measured by the ratio of time needed to complete iterations sequentially over the time need to complete them in parallel) as a function of the number of workers used. Often, you can convert a sequential algorithm to a parallel algorithm by simply changing a for-loop to a parfor-loop. The parfor construct in Parallel Computing Toolbox is similar to a standard for-loop. The key difference is that parfor distributes the computations performed within the loop to worker processors. Learn more about running parallel simulations. Parallel Computing Toolbox is integrated with Simulink Design Optimization and SystemTest to help you speed parameter tuning using numerical optimization and test execution, respectively. Learn more about improving Simulink Design Optimization performance using parallel computing and integrating SystemTest and Parallel Computing Toolbox. Simulink Performance Advisor Starting with Simulink R2012b, you can use the Performance Advisor to check for conditions and configuration settings that might cause inefficient simulation performance (Figure 7). The Performance Advisor analyzes the model and produces a report that lists the suboptimal conditions or settings that it finds. It suggests better model configuration settings where appropriate, and provides mechanisms for fixing issues automatically or manually. The techniques recommended in this article, as well as other approaches, can be automatically tested in the Performance Advisor. 8

9 Figure 7. The Simulink Performance Advisor. Applying the Techniques and Measuring the Results To illustrate the relative effectiveness of these techniques on a realistic project, we measured the simulation time performance improvement provided by applying some of the changes suggested above to a model of an automatic transmission system (Figure 8). Figure 8. Simulink model of an automatic transmission system. To improve performance, we made the following changes: Simplified the graphics used in the model (changed the engine image file format from TIF to JPG, removed the transmission image, simplified the car line art) Loaded data via a MAT-file instead of a script in PreLoadFcn, and decimated logged signal vehicle_speed by 10 Replaced Interpreted MATLAB Function blocks with MATLAB functions (This change has the greatest single effect.) Enabled the following optimizations: Block reduction, Implement logic signals as Boolean (vs. double) data, and Inline parameters Disabled expensive diagnostics that check for solver data inconsistency, division by singular matrix, Inf or NaN block output, simulation range checking, and array bounds exceeded Removed Scopes and enabled optimizations for Accelerator mode Replaced an ode3 fixed-step solver with an ode23 variable-step solver, and set max step size to auto 9

10 These changes reduced simulation time from 9.06 seconds to 0.98 seconds! Using the optimized model, we can now apply rapid acceleration and parallel simulation to compare the performance of those techniques (Table 1). Original Model, Normal Mode, Serial Execution Improved Model, Normal Mode, Serial Execution Improved Model, Rapid Accelerator Mode, Serial Execution Improved Model, Normal Mode, Parallel Simulation (6 local workers) Improved Model, Rapid Accelerator Mode, Parallel Simulation (6 local workers) Improved Model, Rapid Accelerator Mode, Parallel Simulation (12 local workers) 453 seconds 49.1 seconds 31.4 seconds 13.2 seconds 8.58 seconds 4.86 seconds Table 1. Time for 50 iterations of each model for 1000 seconds of simulation time. System used: Lenovo S20 with Intel Xeon W3690 (3.46 GHz, 12 MB cache), 24 GB DDR MHz PC SDRAM, Drive 1: 500 GB 7200 RPM, Drive 2: 160 GB SSD with TRIM Support; MATLAB R2011b is installed on Drive 2. Products Used MATLAB Simulink MATLAB Distributed Computing Server Model-Based Calibration Toolbox Parallel Computing Toolbox Simulink Control Design Simulink Design Optimization Stateflow System Identification Toolbox SystemTest Learn More Five Resources for Simulation Performance Tips for Simulation Performance Video: Speeding Up Simulink for Control System Applications 46:37 Video: Speeding Up Simulink for Signal Processing Applications 60:47 See more articles and subscribe at mathworks.com/newsletters. Published v01 mathworks.com 2012 The MathWorks, Inc. MATLAB and Simulink are registered trademarks of The MathWorks, Inc. See for a list of additional trademarks. Other product or brand names may be trademarks or registered trademarks of their respective holders. 10