This is machine translation

Translated by Microsoft
Mouseover text to see original. Click the button below to return to the English version of the page.

Note: This page has been translated by MathWorks. Click here to see
To view all translated materials including this page, select Country from the country navigator on the bottom of this page.

Classic Initialization Mode

When to Use Classic Initialization

Initialization mode controls how Simulink® handles the initialization values for conditionally executed subsystems.

Classic mode was the default initialization mode for Simulink models created in R2013b or before. You can continue to use classic mode if:

  • The model does not include any modeling elements affected by simplified mode.

  • The behavior and requirements of simplified mode do not meet your modeling goals.

  • The work involved in converting to simplified mode is greater than the benefits of simplified mode. See Convert from Classic to Simplified Initialization Mode.

Set Initialization Mode to Classic

To set classic initialization mode:

  1. Open the Configuration Parameters dialog box.

  2. In the search box, enter Underspecified initialization detection.

  3. From the drop-down list, select Classic.

Classic Initialization Issues

Using classic initialization mode can result in one or more of the following issues. You can address these issues by using simplified mode. The description of each issue includes an example of the behavior in classic mode, the behavior when you use simplified mode, and a summary of the changes you must make to use simplified mode.

  • Identity Transformation Can Change Model Behavior.

    Conditional subsystems that include identical subsystems can display different initial values before the first execution if both of the following apply:

    • The model uses classic initialization mode.

    • One or more of the identical subsystems outputs to an identity transformation block.

  • Inconsistent Output with Discrete-Time Integrator or S-Function Block

    Conditional subsystems that use classic initialization mode and whose output connects to a Discrete-Time Integrator block or S-Function block can produce inconsistent output.

  • Sorted Order Affecting Merge Block Output

    The sorted order of conditional subsystems that used classic mode initialization, when connected to a Merge block, can affect the output of that Merge block. A change in block execution order can produce unexpected results.

  • When you rename the Merge block source subsystem blocks, the initial output of the Merge block can change.

    When two or more subsystems are feeding different initial output values to a Merge block that does not specify its own initial output value, renaming one of the subsystems can affect the initial output of the Merge block in classic initialization mode.

For additional information about the tasks involved to convert a model from classic to simplified mode, see Convert from Classic to Simplified Initialization Mode.

Identity Transformation Can Change Model Behavior

Conditional subsystems that include identical subsystems can display different initial values before the first execution if both of the following apply:

  • The model uses classic initialization mode.

  • One or more of the identical subsystems outputs to an identity transformation block.

An identity transformation block is a block that does not change the value of its input signal. Examples of identify transform blocks are a Signal Conversion block or a Gain block with a value of 1.

In the ex_identity_transform_cl model, subsystems A and B are identical, but B outputs to a Gain block, which in turn outputs to an Outport block.

When you simulate the model, the initial value for A (the top signal in the Scope block) is 2, but the initial value of B is 0, even though the subsystems are identical.

If you update the model to use simplified initialization mode (see ex_identity_transform_simpl), the model looks the same. The steps required to convert ex_identity_transform_cl to ex_identity_transform_simpl are:

  1. Set Underspecified initialization detection to Simplified.

  2. For the Outport blocks in subsystems A and B, set the Source of initial output value parameter to Input signal.

    You can also get the same behavior by setting the Source of initial output value parameter to Dialog and the Initial output parameter to 3.

When you simulate the updated model, the connection of an identity transformation does not change the result. The output is consistent in both cases.

Inconsistent Output with Discrete-Time Integrator or S-Function Block

Conditional subsystems that use classic initialization mode and whose output connects to a Discrete-Time Integrator block or S-Function block can produce inconsistent output.

In the ex_discrete_time_cl model, the enabled subsystem includes two Constant blocks and outputs to a Discrete-Time Integrator block. The enabled subsystem outputs to two Display blocks.

When you simulate the model, the two display blocks show different values.

The Constant1 block, which is connected to the Discrete-Time Integrator block, executes, even though the conditional subsystem is disabled. The top Display block shows a value of 2, which is the value of the Constant1 block. The Constant2 block does not execute, so the bottom Display block shows a value of 0.

If you update the model to use simplified initialization mode (see ex_discrete_time_simpl), the model looks the same. The updated model corrects the inconsistent output issue by using simplified mode. The steps required to convert ex_discrete_time_cl to ex_discrete_time_simpl are:

  1. Set Underspecified initialization detection to Simplified.

  2. For the Outport blocks Out1 and Out2, set the Source of initial output value parameter to Input signal. This setting explicitly inherits the initial value, which in this case is 2.

    You can also get the same behavior by setting the Source of initial output value parameter to Dialog and the Initial output parameter to 2.

When you simulate the updated model, the Display blocks show the same output. The output value is 2 because both Outport blocks inherit their initial value.

Sorted Order Affecting Merge Block Output

The sorted order of conditional subsystems that use classic mode initialization, when connected to a Merge block, can affect the output of that Merge block. A change in block execution order can produce unexpected results. The behavior depends on how you set the Output When Disabled parameter.

The ex_basic_merge_sorted_order_1_cl model has two identical enabled subsystems (Enable A and Enable B) that connect to a Merge block. When you simulate the model, the red numbers show the sorted execution order of the blocks.

When you simulate the model, the Scope block looks like the following:

The ex_basic_merge_sorted_order_2_cl model is the same as ex_merge_sorted_1_cl, except that the block execution order is the reverse of the default execution order. To change the execution order:

  1. Open the Properties dialog box for the Enable A subsystem and set the Priority parameter to 2.

  2. Set the Priority of the Enable B subsystem to 1.

When you simulate the model using the different execution order, the Scope block looks like the following:

The change in sorted order produces different results from identical conditional subsystems.

To update the models to use simplified initialization mode (see ex_basic_merge_sorted_order_1_simpl and ex_basic_merge_sorted_order_2_simpl):

  1. Set Underspecified initialization detection to Simplified.

The Initial Output parameter of the Merge block is an empty matrix, [], by default. Hence, the initial output value is set to the default initial value for this data type, which is 0. For information on default initial value, see Initializing Signal Values. When you simulate each simplified mode model, both models produce the same results.

Using Output When Disabled Parameter Set to Reset

The ex_merge_sorted_1_cl model has two enabled subsystems (Enable A and Enable B) that connect to a Merge block. When you simulate the model, the red numbers show the sorted execution order of the blocks.

When you simulate the model, the Scope block looks like the following:

The ex_merge_sorted_2_cl model is the same as ex_merge_sorted_1_cl, except that the block execution order is the reverse of the default execution order. To change the execution order:

  1. Open the Properties dialog box for the Enable A subsystem and set the Priority parameter to 2.

  2. Set the Priority of the Enable B subsystem to 1.

When you simulate the model using the different execution order, the Scope block looks like:

The change in sorted order produces different results from identical conditional subsystems.

To update the models to use simplified initialization mode (see ex_merge_sorted_1_simpl and ex_merge_sorted_2_simpl):

  1. Set Underspecified initialization detection to Simplified.

  2. For the Outport blocks in Enable A and Enable B, set the Output when disabled parameter to held. Simplified mode does not support reset for output ports of conditional subsystems driving Merge blocks.

When you simulate each simplified mode model, both models produce the same results.

Related Topics