Running Parallel Simulations

Overview of Calling sim from within parfor

The MATLAB parfor command allows you to run parallel Simulink simulations. Calling sim from within a parfor loop is often advantageous for performing multiple simulation runs of the same model for different inputs or for different parameter settings. For example, you may save significant simulation time performing parameter sweeps and Monte Carlo analyses by running them in parallel. Note that running parallel simulations using parfor does not currently support decomposing your model into smaller connected pieces and running the individual pieces simultaneously on multiple workers.

Normal, Accelerator, and Rapid Accelerator simulation modes are supported by sim in parfor. (See Choosing a Simulation Mode for details on selecting a simulation mode and Designing Your Model for Effective Acceleration for optimizing simulation run times.) For other simulations modes, you need to address any workspace access issues and data concurrency issues in order to produce useful results. Specifically, the simulations need to create separately named output files and workspace variables; otherwise, each simulation will overwrite the same workspace variables and files, or possibly have collisions trying to write variables and files simultaneously.

For details about the parfor command, see parfor.

Note   All simulation modes require a homogeneous file system. The workers and the callers must be on the same operating system and have the same type of file system (for example, NTFS or FAT).

Back to Top

sim in parfor with Rapid Accelerator Mode

Running Rapid Accelerator simulations in parfor combines speed with automatic distribution of a prebuilt executable to the parfor workers. As a result, this mode eliminates duplication of the update diagram phase.

To run parallel simulations in Rapid Accelerator simulation mode using the sim and parfor commands, you must:

• Configure the model to run in Rapid Accelerator simulation mode

• Ensure that the Rapid Accelerator target is already built and up to date

• Disable the Rapid Accelerator target up-to-date check by setting the sim command option RapidAcceleratorUpToDateCheck to 'off'.

To satisfy the second condition, you can only change parameters between simulations that do not require a model rebuild. In other words, the structural checksum of the model must remain the same. Hence, you can change only tunable block diagram parameters and tunable run-time block parameters between simulations. For a discussion on tunable parameters that do not require a rebuild subsequent to their modifications, see Determining If the Simulation Will Rebuild.

As for the third condition, the following sample code demonstrates how to disable the up-to-date check using the sim command.

matlabpool open
% Load the model and set parameters
mdl = 'vdp';
load_system(mdl)
% Build the Rapid Accelerator target
rtp = Simulink.BlockDiagram.buildRapidAcceleratorTarget(mdl);
% Run parallel simulations
parfor i=1:4
   simOut{i} = sim(mdl,'SimulationMode', 'rapid',...
               'RapidAcceleratorUpToDateCheck', 'off',...
               'SaveTime', 'on',...
               'StopTime', num2str(10*i));
end

matlabpool close

In this example, the call to the buildRapidAcceleratorTarget function generates code once. Subsequent calls to sim with the RapidAcceleratorUpToDateCheck option off guarantees that code is not regenerated. Data concurrency issues are thus resolved.

For a detailed demonstration of this method of running parallel simulations, refer to the Rapid Accelerator Simulations Using PARFOR demo.

Back to Top

Workspace Access Issues

In order to run sim in parfor, you must first open a MATLAB pool of workers using the matlabpool command. The parfor command then runs the code within the parfor loop in these MATLAB worker sessions. The MATLAB workers, however, do not have access to the workspace of the MATLAB client session where the model and its associated workspace variables have been loaded. Hence, if you load a model and define its associated workspace variables outside of and before a parfor loop, then neither is the model loaded, nor are the workspace variables defined in the MATLAB worker sessions where the parfor iterations are executed. This is typically the case when you define model parameters or external inputs in the base workspace of the client session. These scenarios constitute workspace access issues.

Back to Top

Resolving Workspace Access Issues

When a Simulink model is loaded into memory in a MATLAB client session, it is only visible and accessible in that MATLAB session; it is not accessible in the memory of the MATLAB worker sessions. Similarly, the workspace variables associated with a model that are defined in a MATLAB client session (such as parameters and external inputs) are not automatically available in the worker sessions. You must therefore ensure that the model is loaded and that the workspace variables referenced in the model are defined in the MATLAB worker session by using the following two methods.

• In the parfor loop, use the sim command to load the model and to set parameters that change with each iteration. (Alternative: load the model and then use the g(s)et_param command(s) to set the parameters in the parfor loop)

• In the parfor loop, use the MATLAB evalin and assignin commands to assign data values to variables.

Alternatively, you can simplify the management of workspace variables by defining them in the model workspace. These variables will then be automatically loaded when the model is loaded into the worker sessions. There are, however, limitations to this method. For example, you cannot have tunable parameters in a model workspace. For a detailed discussion on the model workspace, see Using Model Workspaces.

Specifying Parameter Values Using the sim Command

Use the sim command in the parfor loop to set parameters that change with each iteration.

% Run parallel simulations of a model that does not
% result in data concurrency issues
mdl = 'vdp';
paramName = 'StopTime';
paramValue = {'10', '20', '30', '40'};
parfor i=1:4
    simOut{i} = sim(mdl, ...
                    paramName, paramValue{i}, ...
                    'SaveTime', 'on');
end

An equivalent method is to load the model and then use the set_param command to set the paramName in the parfor loop.

Specifying Variable Values Using the assignin Command

You can pass the values of model or simulation variables to the MATLAB workers by using the assignin or the evalin command. The following example illustrates how to use this method to load variable values into the appropriate workspace of the MATLAB workers.

parfor i = 1:4
    assignin('base', 'extInp', externalInput{i})
    % 'extInp' is the name of the variable in the base 
    % workspace which contains the External Input data
    simOut{i} = sim(mdl, 'ExternalInput', 'extInp');
end

For further details, see the Rapid Accelerator Simulations Using PARFOR demo.

Back to Top

Data Concurrency Issues

Data concurrency issues refer to scenarios for which software makes simultaneous attempts to access the same file for data input or output. In Simulink, they primarily occur as a result of the nonsequential nature of the parfor loop during simultaneous execution of Simulink models. The most common incidences arise when code is generated or updated for a simulation target of a Stateflow, Model block or MATLAB Function block during parallel computing. The cause, in this case, is that Simulink tries to concurrently access target data from multiple worker sessions. Similarly, To File blocks may simultaneously attempt to log data to the same files during parallel simulations and thus cause I/O errors. Or a third-party blockset or user-written S-function may cause a data concurrency issue while simultaneously generating code or files.

A secondary cause of data concurrency is due to the unprotected access of network ports. This type of error occurs, for example, when a Simulink product provides blocks that communicate via TCP/IP with other applications during simulation. One such product is the HDL Verifier™ for use with the Mentor Graphics® ModelSim® HDL simulator.

Back to Top

Resolving Data Concurrency Issues

The core requirement of parfor is the independence of the different iterations of the parfor body. This restriction is not compatible with the core requirement of simulation via incremental code generation, for which the simulation target from a prior simulation is reused or updated for the current simulation. Hence during the parallel simulation of a model that involves code generation (such as Accelerator mode simulation), Simulink makes concurrent attempts to access (update) the simulation target . However, you can avoid such data concurrency issues by creating a temporary folder within the parfor loop and then adding several lines of MATLAB code to the loop to perform the following steps:

1. Change the current folder to the temporary, writable folder.

2. In the temporary folder, load the model, set parameters and input vectors, and simulate the model.

3. Return to the original, current folder.

4. Remove the temporary folder and temporary path.

In this manner, you avoid concurrency issues by loading and simulating the model within a separate temporary folder. Following are examples that use this method to resolve common concurrency issues.

A Model with Stateflow, MATLAB Function Block, or Model Block

In this example, either the model (mdl) is configured to simulate in Accelerator mode or it contains a Stateflow, a MATLAB Function block, or a Model block (for example, sf_bounce, sldemo_autotrans, or sldemo_modelref_basic). For these cases, Simulink generates code during the initialization phase of simulation. Simulating such a model in parfor would cause code to be generated to the same files, while the initialization phase is running on the worker sessions. As illustrated below, you can avoid such data concurrency issues by running each iteration of the parfor body in a different temporary folder.

parfor i=1:4
   cwd = pwd;
   addpath(cwd)
   tmpdir = tempname;
   mkdir(tmpdir)
   cd(tmpdir)
   load_system(mdl)
   % set the block parameters, e.g., filename of To File block
   set_param(someBlkInMdl, blkParamName, blkParamValue{i})
   % set the model parameters by passing them to the sim command
   out{i} = sim(mdl, mdlParamName, mdlParamValue{i});
   cd(cwd)
   rmdir(tmpdir,'s')
   rmpath(cwd)
end

Note that you can also avoid other concurrency issues due to file I/O errors by using a temporary folder for each iteration of the parfor body.

A Model with To File Blocks

If you simulate a model with To File blocks from inside of a parfor loop, the nonsequential nature of the loop may cause file I/O errors. To avoid such errors during parallel simulations, you can either use the temporary folder idea above or use the sim command in Rapid Accelerator mode with the option to append a suffix to the file names specified in the model To File blocks. By providing a unique suffix for each iteration of the parfor body, you can avoid the concurrency issue.

parfor i=1:4
	  sim(mdl, ...
       'ConcurrencyResolvingToFileSuffix', num2str(i),...
       'SimulationMode', 'rapid'); 
end

Back to Top

Using the set_param Command

Error Handling in Simulink Using MSLException

Related Products & Applications

• Simulink
• Control Design
• Signal Processing & Communications
• Model-Based Design
• Physical Modeling
• Verification & Validation

Get Simulink trial software

Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.

Get this Simulink Kit