Main Content

This section describes important characteristics of the mathematical representations of physical systems, and how Simscape™ software implements such representations. You might find this overview helpful if you:

Require details of such representations to improve your model fidelity or simulation performance.

Are constructing your own, custom Simscape components using the Simscape language.

Need to troubleshoot Simscape modeling or simulation failures.

Mathematical representations are the foundation for physical simulation. For more information about simulation, see How Simscape Simulation Works.

The mathematical representation of a physical system contains *ordinary
differential equations* (ODEs), *algebraic equations*, or
both.

ODEs govern the rates of change of

*system variables*and contain some or all of the time derivatives of the system variables.Algebraic equations specify functional constraints among system variables, but contain no time derivatives of system variables.

Without algebraic constraints, the system is differential (ODEs).

Without ODEs, the system is algebraic.

With ODEs and algebraic constraints, the system is mixed

*differential-algebraic*(DAEs).

A system variable is differential or algebraic, depending on whether or not its time derivative appears in the system equations.

A mathematical problem is *stiff* if the solution you are seeking
varies slowly, but there are other solutions within the error tolerances that vary rapidly.
A stiff system has several intrinsic time scales of very different magnitude [1].

A stiff physical system has one or more components that behave “stiffly” in the ordinary sense, such as a spring with a large spring constant. Mathematical equivalents include quasi-incompressible fluids and low electrical inductance. Such systems often exhibit high frequency oscillations in some of their components or modes.

Events are discontinuous changes in system state or dynamics as the system evolves in time; for example, a valve opening, or a hard stop. For more information on how events are represented in the Simscape language, see Discrete Event Modeling.

A *zero crossing* is a specific event type, represented by the value
of a mathematical function changing sign. Variable-step solvers take smaller steps when they
detect a zero-crossing event. Smaller steps help to capture the dynamics that cause the zero
crossing, but they also significantly slow down the simulation. Various methods of zero
crossing detection and analysis help you strike the right balance between the simulation
speed and accuracy. For more information, see Managing Zero Crossings in Simscape Models.

A Simscape model is equivalent to a set of equations representing one or more physical systems as physical networks.

Start by assuming that your physical network is a DAE system: a mix of differential and algebraic equations and variables.

Remember that some physical networks are represented by ODEs only.

Physical networks may contain stiff differential equations.

Identify discrete and continuous components that might change discontinuously during a simulation.

Your model can contain zero-crossing conditions arising from several sources:

Simscape and Simulink

^{®}blocks copied from their respective block librariesCustom blocks programmed in the Simscape language

Simulink software has global methods for managing zero-crossing events. For more information, see Zero-Crossing Detection.

You can disable zero-crossing detection on individual blocks, or globally across the entire model. Zero-crossing detection often improves simulation accuracy, but can slow simulation speed.

**Tip**

If the exact times of zero crossings are important in your model, then keep zero-crossing detection enabled. Disabling it can lead to major simulation inaccuracies.

In addition to generic Simulink methods, Simscape software has specific tools that let you detect and manage zero-crossings in your models:

Prior to simulation, you can use the Statistics Viewer to identify the potential zero-crossing signals in the model. These signals are typically generated from operators and functions that contain discontinuities, such as comparison operators,

`abs`

,`sqrt`

functions, and so on. During simulation it is possible for none of these signals to produce a zero-crossing event or for one or more of these signals to have multiple zero-crossing events. For more information, see View Model Statistics.When logging simulation data for a model, you can select the

**Log simulation statistics**option. The data log then includes the actual zero-crossing data during simulation. For more information, see Log Simulation Statistics.You can access and analyze zero-crossing data logged during simulation by using the Simscape Results Explorer. For more information, see About the Simscape Results Explorer.

The

`sscprintzcs`

function prints information about zero crossings detected during simulation, based on logged simulation data. Before you call this function, you must have the simulation log variable, which includes simulation statistics data, in your current workspace. For more information and examples, see`sscprintzcs`

.

Managing zero crossing is especially important when you prepare your models for real-time simulation. See Reduce Zero Crossings for a detailed example of this workflow.

When writing code for your own custom blocks using the Simscape language, you can create or avoid zero-crossing conditions in your model by switching between different implementations of discontinuous conditional expressions. You can:

Use relational operators, which create zero-crossing conditions. For example, programming the operator relation:

`a < b`

creates a zero-crossing condition.Use relational functions, which do not create zero-crossing conditions. For example, programming the functional relation:

`lt(a,b)`

does not create a zero-crossing condition. For more information on whether a particular function creates discontinuities when used in Simscape language, see`equations`

.

**Note**

Using relational functions, like `lt(a,b)`

, in event predicates
always creates a zero-crossing condition. For more information about event predicates,
see Discrete Event Modeling.

[1] Moler, C. B., *Numerical Computing with
MATLAB,* Philadelphia, Society for Industrial and Applied Mathematics, 2004,
chapter 7

[2] Horowitz, P., and Hill, W., *The Art of
Electronics*, 2nd Ed., Cambridge, Cambridge University Press, 1989, chapter
2

[3] Brogan, W. L., *Modern Control Theory*,
2nd Ed., Englewood Cliffs, New Jersey, Prentice-Hall, 1985