Use operating point with a block, S-functions and model changes.
loggedStates to get or set the states of blocks. If
xout is the state log that Simulink® exports to the workspace, then the
has the same structure as
With dataset logging,
ModelOperatingPoint captures the current
logged states snapshot, as a non-
ModelOperatingPoint final state save
would, and stores it on the
ModelOperatingPoint object. When you
query this logged state, a copy of the saved dataset is returned.
With dataset logging format, the answers returned by
ModelOperatingPoint always match those returned by state logging
(non-Operating Point save). Logged states for blocks inside of accelerator-mode model
reference are visible and editable. Logged states for many blocks with custom operating
point functions, for example, Simscape, model reference accel and variable transport
delay are editable.
You cannot change the states that are not logged. Simulink does not allow this modification as it could cause the state to be inconsistent with the simulation.
You can use APIs for C-MEX and Level-2 MATLAB® S-functions to enable S-functions to work with the
ModelOperatingPoint object. For information on how to implement these
APIs within S-functions, see S-Function Compliance with the ModelOperatingPoint.
S-functions that have PWork vectors, which store pointers to data structures but do not declare their operating point compliance level or declare it to be unknown or disallowed do not support operating point. For more information, see S-Function Compliance with the ModelOperatingPoint.
After saving the operating point of a model, you can change the model and restore an operating point with those changes.
You can rename a model between saving and restoring its operating point.
The operating point interface checksum is primarily based on the configuration settings in a model and sample times used in the model. You can make some nonstructural changes to the model between saving and restoring an operating point. In the Configuration Parameters dialog box, in the Diagnostics pane, use the Operating point interface checksum mismatch diagnostic to track such changes. You can then find out if the interface checksum of the restored operating point matches the current interface checksum. See Operating point interface checksum mismatch.
You can make the following nonstructural changes to the model without affecting your ability to restore a previously saved operating point:
Changes to model-level signal logging settings in the Model Configuration Parameters: Data Import/Export.
Logging of specific signals.
Addition and removal of Level-2 MATLAB or C S-Functions that are configured as simulation viewing devices and do not set the operating point compliance to Custom or Disallowed. See S-Function Compliance with the ModelOperatingPoint for more information.
These modifications may change the number of sample times in the model. This can
cause the model's interface checksum to be different from the operating point save and
restore checksum. Configure the Operating point interface checksum mismatch
diagnostic to display a
none to not compare
You cannot make structural changes to the model between the time you save the operating point and the time you restore the simulation using the operating point. Examples include, adding or removing a block after saving the operating point, changing the sample time of a model, and changing the type of solver from variable-step to fixed-step.
Mismatches can occur when you try to simulate using a solver that is different from
the one that generated the saved operating point. Simulink permits solver changes. For example, you can use the
ode15s solver to solve the initial stiff portion of a simulation
and save the final operating point. You can then continue the simulation with the
restored operating point using
ode45. In other words, this diagnostic
helps you see the solver changes but does not signal a problem with the
When you use a variable-step solver with the maximum step size set to
auto, Simulink uses the maximum step size from the restored
ModelOperatingPoint object for the new simulation. To ensure that the
concatenated operating point trajectory of two simulations matches that of an
uninterrupted simulation, specify a value for the maximum step size.
In some cases, saving partial state information avoids some of the limitations of using operating point. For a comparison of the two ways to save state data, see Comparison of Operating Point and Final State Logging.
The following blocks do not support operating point:
In the Stack and Queue blocks, the default setting
for the Push full stack option is Dynamic
reallocation. This default setting does not support
ModelOperatingPoint object. Other settings
(Ignore, Warning and
Simscape™ Multibody™ First Generation blocks
Simulink tries to save the output of a block as part of an operating point. For S-functions, this happens even if the functions declare that no operating point is required. If the block output is of custom type, Simulink cannot save the operating point and displays an error. For more information about operating point use with S-functions, see S-Functions.
Model reference offers partial support for operating point. For details, see Model Referencing.
You can use only the normal or the accelerator simulation mode.
You cannot save operating point in normal mode and restore it in accelerator mode, or vice versa.
You cannot change the states of certain blocks that are not logged. For more information, see Change the States of a Block Within Operating Point.
The operating point feature does not support Simulink Coder™ or Embedded Coder® code generation.
You cannot modify logged states of blocks that are inside a referenced model in accelerator mode.
The following blocks do not support operating point when included in a model referenced in accelerator mode:
Level 2 MATLAB S-Function
n-D Lookup Table
S-Function (with custom operating point or
For additional information, see State Information for Referenced Models.
You cannot input the operating point to the