Set Configuration Parameters for Model Hierarchies

A referenced model uses a configuration set the same way that it would if the model executed independently. By default, every model in a hierarchy has its own configuration set. Because each model can have its own configuration set, configuration parameter values can be different in different models.

Some parameter values are intrinsically incompatible with model references. The response to an inconsistent or unusable configuration parameter depends on the parameter.

• Where an inconsistency has no significance, or a trivial resolution without risk exists, the software ignores or resolves the inconsistency without issuing a warning.

• Where a nontrivial and possibly acceptable solution exists, the software resolves the conflict silently, resolves it and issues a warning, or issues an error. For details, see Diagnostics That Are Ignored in Accelerator Mode.

• Where no acceptable resolution is possible, the software issues an error.

Manage Configuration Parameters by Using Configuration References

To assign an externally stored configuration set to multiple models, you can use configuration references. Configuration references help you eliminate configuration parameter incompatibilities.

You can propagate the configuration reference of a top model to an individual referenced model or to all referenced models in the model hierarchy. For an example, see Share a Configuration Across Referenced Models.

Review Configuration Requirements for Simulation of Model Reference Hierarchies

Some configuration parameter settings can cause incompatibilities in model hierarchies. Where possible, the software resolves violations of these requirements automatically, but most cases require changes to the parameters in some or all models.

This table provides configuration parameter requirements for simulation of model reference hierarchies. For code generation requirements, see Set Configuration Parameters for Code Generation of Model Hierarchies (Simulink Coder).

Dialog Box Pane	Configuration Parameter	Requirement
Solver	Start time	The compiled start time of the top model and all referenced models must be the same. The compiled start time is the start time that the solver uses for the simulation. Often, the compiled start time value matches the value you specify using the Start time parameter. When you use a fixed-step solver and the start time you specify is not 0 or an integer multiple of the fixed step size for the simulation, the solver determines the compiled start time as the nearest integer multiple of the fixed step size, moving forward in time.
	Stop time	The software uses the stop time of the top model for simulation, overriding any differing stop time in a referenced model.
	Type	When no referenced models in the hierarchy use a local solver, the solver type of the top model applies throughout the hierarchy. To check compatibility, see Specify Compatible Solver Settings. Before R2025a: When you configure one or more referenced models to use a local solver, the local solver type must be fixed-step.
	Solver	When no referenced models in the hierarchy use a local solver, the solver of the top model applies throughout the hierarchy. When you configure one or more referenced models to use a local solver, the solver you select for the referenced model solves the model as a separate set of differential equations. For more information, see Configure Local Solver Settings.
	Treat each discrete rate as a separate task	When a multirate model treats each discrete rate as a separate task and references another multirate model, the referenced model must also treat each discrete rate as a separate task.
	Allow tasks to execute concurrently on target	A parent model and referenced model support different concurrent tasking settings only when the referenced model does not contain asynchronous sample times and one of these conditions is true: The referenced model contains only one periodic sample time. The referenced model contains multiple periodic sample times, and the parent model enables explicit partitioning. The software satisfies the rate-transition requirements with rate monotonic scheduling.
Data Import/Export	Initial state	When a top model specifies an initial model state or operating point for simulation, a referenced model must not also specify an initial model state or operating point.
Math and Data Types	Simulation behavior for denormal numbers	In a model reference hierarchy, you can simulate a top model using gradual underflow with any simulation mode. Models referenced by the top model can simulate the flush-to-zero behavior only if the instance of the referenced model uses an accelerated simulation mode and has this parameter set to Flush to zero (FTZ).
	Use division for fixed-point net slope computation	For simulations in normal or accelerator mode, a parent model and referenced model must be configured to perform Fixed-Point Designer™ net scaling computations in the same way.
Diagnostics > Compatibility	Block behavior depends on frame status of signal	When a model is configured to produce an error for this parameter, each referenced model must also be configured to produce an error.
Model Referencing	Total number of instances allowed per top model	A referenced model must specify that it is available to be referenced, and whether it can be referenced at most once or can have multiple instances. By default, a referenced model can be referenced multiple times. The total number of instances allowed per top model must not be zero for a referenced model.

Specify Compatible Solver Settings

Model referencing works with both fixed-step and variable-step solvers. When no referenced models use a local solver, all models in the model hierarchy use the solver specified by the top model.

Throughout the model hierarchy, the solver Type settings must be compatible.

Parent Model Solver Type	Referenced Model Solver Types
Fixed-step	Fixed-step only
Variable-step	Variable-step or Fixed-step For a referenced model solver type to be fixed-step: The referenced model must not reference a model with a variable-step solver. The referenced model must not have both continuous and discrete sample times.

For example, this model hierarchy has compatible solver Type settings:

• Model A specifies a variable-step solver and references model B.

• Model B specifies a fixed-step solver and has only discrete sample times. Model B references model C.

• Model C specifies a fixed-step solver and has only discrete sample times.

Suppose you replace model C with model D, which has both continuous and discrete sample times. The solver Type settings are no longer compatible.

To support a referenced model that has both continuous and discrete sample times, the models above the hybrid model must specify the same solver type. In this example, you can resolve the incompatibility by performing either of these actions:

• Specify a fixed-step solver for model A.

  

• Specify a variable-step solver for both models B and D.

  

For information about sample times, see Types of Sample Time.

For information about solvers, see Compare Solvers and Solver Selection Criteria.

Configure Local Solver Settings

You can configure one or more referenced models in a model hierarchy to use a local solver. Consider using a local solver when:

• A referenced model represents a component with much faster (since R2024a) or slower dynamics compared to the rest of the system and continuous states that are decoupled from the rest of the system.

• A different solver from the solver for the top model is better suited to solve the referenced model.

To use a local solver, set these configuration parameters for the referenced model:

1. Select the Use local solver when referencing model parameter.

2. Set the Type parameter to Fixed-step.

3. Set the Solver parameter to a value other than discrete (no continuous states).

4. Depending on the solver type, specify additional configuration parameters for the referenced model. For example, for a fixed-step solver, specify the Fixed-step size (fundamental sample time) parameter value as a scalar number or auto.

Local solvers for referenced models operate on continuous states in the referenced model. Because using a local solver for a referenced model with only discrete states has no effect on simulation results, local solvers are not supported for models that do not contain continuous states. When a model contains no continuous states, the software always uses the discrete solver. The discrete solver is not supported as a local solver.

For information about how local solvers work, how to configure instance-specific local solver settings, and a complete list of limitations and considerations, see Use Local Solvers in Referenced Models.

Diagnostics That Are Ignored in Accelerator Mode

When a referenced model simulates only in accelerator mode, the software does not issue warnings or errors for these diagnostic configuration parameters of the referenced model.

• Array bounds exceeded

• Inf or NaN block output

• Simulation range checking

• Division by singular matrix

• Wrap on overflow

• Detect read before write

• Detect write after read

• Detect write after write

To identify the referenced models with diagnostics that are ignored during simulation in accelerator mode, use the Model Advisor.

1. On the Modeling tab, click Model Advisor.

2. Select the top model, then click OK.

3. Select By Task > Model Referencing > Check diagnostic settings ignored during accelerated model reference simulation.

4. Click Run This Check.

To run the diagnostics for the identified referenced models, configure the corresponding configuration parameters to produce warnings or errors. Then, simulate the model in normal mode and check for diagnostic messages.

Note

Configuration parameters on the Code Generation pane of the Configuration Parameters dialog box do not affect simulation in either normal or accelerator mode. Code Generation parameters affect only Simulink^® Coder™ code generation. Accelerator mode simulation requires code generation to create a simulation target. Simulink software uses default values for all Code Generation parameters when generating the target and restores the original parameter values after code generation is complete.