[picture:OPTI-NUM header graphic]


Newsletters
November 2008

November 2008


Back to main newsletter

Built-In Support for Parallel Computing

As the complexity of modern systems and algorithms increase, the need to thoroughly test, analyse, verify and validate as well as have an optimal design in the shorter time frames is called for. The MathWorks have a number of tools that are essential to complete these tasks successfully, and here we will focus on ways to improve the computation time for testing and optimisation.

Running tests and analysing results for system verification and validation

As part of any design process, test and analysis is an essential step. One may want to run tests to verify and validate the design, or run a Monte Carlo simulation to see what the effect of unknown parameters will be on the overall performance. In short, the more we know about the system up front, the lower the risk and we are able to handle unforeseen issues quicker.

To simplify testing one could use SystemTest™ software. SystemTest lets you develop and execute tests that exercise MATLAB algorithms and Simulink models. SystemTest includes predefined test elements that let you build and maintain standard test routines, as well as map test variables into a result set for analysis.

These types of tests typically take a long time to complete because they will involve many scenarios or require parameter sweeps over large ranges or multiple parameters. With SystemTest you can easily leverage the power of Parallel Computing Toolbox to distribute the main test iterations to multiple processors to be performed simultaneously.

Design Optimization

The Optimization Toolbox , Genetic Algorithm and Direct Search Toolbox and Simulink Response Optimization can now access built-in parallel functionality through the Parallel Computing Toolbox.

A common task in control design is time-domain response optimization of a Simulink model, such as for PID tuning. Using parallel computing can speed up the optimization time in the following situations:

  • The model contains a large number of either tuned or uncertain parameters.
  • The model is complex and takes a long time to simulate.

For more information about using parallel computing for time-domain response optimization, see Speeding Up Response Optimization Using Parallel Computing in the Simulink Response Optimization documentation.

Example: Running a Monte Carlo Analysis on an Image Processing Algorithm

For complex designs it is often the case that the gold standard (reference design) will be different to the hardware design. This is because when the reference design is built little consideration given to hardware implementation since the main focus at this level is to see if the algorithm meets the project requirement.

As part of the Model-Based Design approach the gold standard design is then elaborated to make it suitable for hardware implantation. An example would be converting double precision to fixed point so that it can run on an FPGA.

In this example an edge detection algorithm was designed where the implementation is required to be within 10% of the gold standard over a range of image noise. Since the implementation is different to the gold standard the correct threshold for the implementation needs to be found. To do this, System test was used to sweep over the following parameters:

  • Threshold values ranging from 365 to 535
  • Noise levels ranging from 0 to 100

This particular sweep over the two parameters results in 108 iterations.
The reporting functionality of the System test was also used to generate an automatic pass fail report.

Sample test report showing a failed and passed iteration. Click here for a larger image.
The overall test report gives an overview of how many tests passed and failed.

Final test report. Click here for a larger image.

Parallel Computing Speeds up Test Times

This test was run in serial on a single machine, and then using the distributed computing cluster in our offices. The serial version took 98 seconds on the serial machine. This test time was reduced to 27 seconds using only 5 workers. By utilising more workers, the time could have been reduced even further.

Again, the time taken to distribute the task over the cluster includes communication of the entire problem to the cluster, running the sub-tasks on each cluster, and gathering the results. Most importantly (for the user) the process consisted of defining a few options in the SystemTest user interface, to tell SystemTest to distribute the task, which cluster configuration to use, and how many tasks to provide to each worker as a single “job”.

More Information

For more information about how SystemTest can use Parallel Computing Toolbox to speed up testing, see the online documentation (MathWorks Account login required).

 

Back to main newsletter