Main Content

Determine Optimal Complexity Level for Reusable Components

The complexity level of the repeated components has significant impact on the scalable compilation results. You can try different ways of restructuring your model into repeated components to determine the optimal configuration.

For example, consider this battery pack model.

The entire model has a controller and a plant. The plant model, shown in the previous figure, is a battery pack that consists of 16 identical battery modules. Each of these battery modules, in turn, consists of two interconnected subsystems: a battery cell and a monitoring unit, as shown in the next figure.

Because the complexity of a reusable component has significant impact on scalable compilation performance, the model might need to be restructured into a different set of reusable components to improve performance. One important factor that has a negative impact on performance is the number of the interface variables (external connections) of a reusable component. Because of that, scalable compilation is likely to be more efficient if you base the reusable components on a module consisting of the two facing subsystems, rather than on each of the individual battery and monitoring unit subsystems.

Use the Advisory tool to analyze the different restructuring options and determine the optimal configuration:

  1. Run sscScalableAdvisor on the model and supply the names of the 32 individual subsystems (16 battery cells and 16 monitoring units), in a cell array, as the second input argument. Review the compilation statistics and component reusability results.

  2. Try a different configuration. Using the Create Subsystem from Selection option, create a virtual subsystem from each pair of the facing subsystems, so that each battery module is represented by one subsystem.

    The restructured model may look like this.

    Run sscScalableAdvisor again, and this time supply a cell array that contains the 16 module subsystem names as the second argument. Each of the module subsystems is more complex and has fewer external connections than the individual batteries and monitoring units, and therefore the scalable compilation performance is likely to be much better.

  3. You can probably improve the compilation performance even more by restructuring the model into eight repeated subsystems instead of 16. Analyze the performance results and make a decision based on both compilation performance and maintaining the modeling hierarchy. Even if restructuring the model into eight reusable components compiles slightly faster, you might want to maintain the structure where one battery module corresponds to one subsystem.

Once you have determined the optimal model configuration, replace the repeated subsystems with reusable components and enable scalable compilation, as described in the last two steps of Prepare Your Model for Scalable Compilation.

Selectively Disable Scalable Compilation of Certain Subsystems

Scalable compilation is hierarchical. When you enable scalable compilation of a model, the compiler tries to reuse compilation artifacts of every referenced subsystem and linked subsystem in the model hierarchy. However, for models with a deep hierarchy of referenced or linked subsystems this default behavior might not be optimal.

For example, in the battery model discussed earlier, the individual battery cells and monitoring units are virtual subsystems. Consider instead that these components are represented by referenced subsystems or linked subsystems. In this case, restructuring the model into 16 modules would not improve the scalable compilation results because the compiler would treat each of the 16 modules as consisting of two reusable components. To get the benefit of fewer external connections and increased complexity of each of the reusable components, in addition to restructuring the model into 16 modules you must disable scalable compilation of the underlying subsystems in each module.

Similarly, if your model contains linked subsystems with deep hierarchy, such as linked libraries, disable scalable compilation inside the library subsystem. For example, if you have a refrigerator model with several identical tanks and each tank, in turn, uses a linked library of water pipes, you might want to disable scalable compilation of these linked libraries. This way, the compiler treats the whole tank as one reusable component, rather than trying to reuse compilation artifacts from within the water pipe library.

To disable scalable compilation for a specific referenced subsystem or linked subsystem within a model, type:

simscape.reuse.setConfig(blockPath,'off')

where blockPath is the path to an instance of a Subsystem Reference block, or a Subsystem block with a library link, from the root of the model. This setting affects all instances of this subsystem in the model.

For example, typing:

simscape.reuse.setConfig('Refrigerator/Tank1/WaterPipeLibrary','off')

disables scalable compilation for all instances of WaterPipeLibrary in all the tanks in the Refrigerator model.

To restore the default setting, type:

simscape.reuse.setConfig(blockPath,'on')

To query the subsystem setting, type:

setting = simscape.reuse.getConfig(blockPath)

This subsystem parameter setting takes effect only if scalable compilation is enabled for the whole model. Then, the compiler tries to reuse compilation artifacts of subsystems with the auto setting but does not consider subsystems with the off setting reusable.

Related Topics