Operating point restore interface checksum mismatch
Diagnostic behavior when interface checksum does not match between initial operating point and model
Model Configuration Pane: Diagnostics
This parameter specifies whether the software issues a warning, an error, or no diagnostic
when the model interface checksum differs from the interface checksum saved in the
Simulink.op.ModelOperatingPoint object specified as the value for
the Initial state parameter. The
interface checksum tracks a collection of model settings that might affect the
simulation results, including the solver settings and the sample times in the model. A
difference in the interface checksum might indicate that a simulation started from the
initial operating point could produce different results than a simulation of the model
that runs from the start. This diagnostic can flag that the interface checksum has
changed but cannot indicate the exact effect of the difference on the simulation
Model Changes Between Saving and Restoring Model Operating Points
The model operating point is meant to resume simulation from the specified operating point as though the simulation ran from the beginning without interruption. Changes you make in a model between saving and restoring an operating point might lead to differences in the results of a simulation that starts from the operating point.
When changes to the model affect the structure or algorithmic behavior of the model, the model operating point object is no longer valid, and the software always issues an error. For some nonstructural changes in the model, the differences in simulation results might not be significant.
The software always issues an error when you make these structural or algorithmic changes between saving and restoring a model operating point:
Adding or removing blocks other than logging and visualization blocks
Changing the type of solver from variable-step to fixed-step or from fixed-step to variable-step
Changing connections between blocks
Changing nontunable block parameter values such as data types, sample times, and dimensions
In general, you can make these kinds of nonstructural changes to a model between saving and restoring the model operating point:
Renaming the model.
Changing the solver without changing the solver type.
For example, you might use the
ode15sstiff solver for the initial portion of a simulation then switch to the
ode45solver for the remainder.
Changing model-level logging settings using the model configuration parameters on the Data Import/Export pane of the Configuration Parameters dialog box.
Changing which signals are marked for logging.
Adding or removing of visualization and logging blocks such as the Scope block, Floating Scope block, To Workspace block, and To File block.
Adding or removing a Level-2 MATLAB® S-function that has the
SetSimViewingDeviceflag set to
trueand operating point compliance set to a value other than custom or disallowed. For more information, see Level-2 MATLAB S-Function Compliance with Model Operating Point.
Adding or removing a C S-function that has the
SS_OPTION_SIM_VIEWING_DEVICEoption set and has the operating point compliance set to a value other than custom or disallowed. For more information, see
While these changes generally do not affect your ability to restore a model operating point, they might affect the interface checksum for the model or lead to differences in the simulation results. When these changes affect the interface checksum, the software issues a diagnostic based on the setting for this parameter when you specify the initial state for a simulation as an operating point saved before modifying the model.
The software issues a warning.
The software issues an error and terminates the simulation.
The software does not issue a diagnostic.
|Safety precaution||No impact|
Version HistoryIntroduced in R2019a
R2019a: SimState interface checksum mismatch parameter renamed to Operating point restore interface checksum mismatch
The Operating point restore interface checksum mismatch parameter
replaces the SimState interface checksum mismatch parameter,
which was introduced in R2009b. To programmatically configure the parameter in
previous releases, you used the
SimStateInterfaceChecksumMismatchMsg parameter. Starting in
R2019a, use the
SimStateInterfaceChecksumMismatchMsg parameter continues to work and
results in the same behavior as the