# Equations¶

Although equations are probably the single most important mathematical aspect of Modelica, they are also the simplest to explain.

## Basic Equations¶

There are really no complicated semantics to explain about equations.
All equations are composed of a left hand expression and a right hand
expression separated by an equals sign, *i.e.,*

```
<left-hand expression> = <right-hand expression>;
```

Through the examples presented in this chapter, the reader has been
exposed to this pattern over and over again in each example. The only
real deviation from the syntax shown above is the case where a
description of the equation is included as well, *e.g.,*

```
V = i*R "Ohm's law";
m*der(v) = F "Newton's law";
```

As was pointed out previously, the left hand and right hand sides of
an equation in Modelica are expressions, not assignments. In other
words (and in contrast to most programming languages), the left hand
side does **not** have to be a variable (as we can see in the case of
Newton’s law above).

## Initial Equations¶

As we saw in many of the examples in this chapter, it is possible to
specify equations within a model to be used to solve for initial
conditions. This entire topic of initialization will be discussed in
detail in the next section, titled Initialization. For now,
all we will say on this topic is that if an equation is to be applied
*only* to solve for initial conditions, the `equation`

section must
be qualified by the `initial`

keyword as follows:

```
initial equation
x = 0; // Only used to solve for initial conditions
```

## Conditional Equations¶

In the next chapter, we’ll discuss how to use `if`

statements to
represent conditional behavior. It is worth getting ahead of
ourselves a little bit to point out that equations can be
conditional. There are really two forms of conditional equations.
The first is the balanced form, *e.g.,*

```
if a>b then
x = 5*time;
else
x = 3*time;
end if;
```

In the balanced case, the number of equations is always the same (1 in
the code above), but *which* equation can change. This is important
because to simulate a model in Modelica, the number of variables must
equal the number of equations and the number of equations must be
fixed during the simulation.

The other type of conditional equations are ones where the number of
equations is unbalanced. This means that the number of equations on
the `if`

side may not be equal to the number of equations on the
`else`

side (like it was in the balanced case, previously).

But remember, the number of equations cannot change during a
simulation. So how is it then that the number of equations can be
different from the `if`

side to the `else`

side? It can only
happen if **the value of the conditional expression cannot change
during the simulation**. In order to be able to ensure that the
conditional expression can never change, it is necessary that all
variables in the conditional expression have so-called *parametric
variability*.

Remember in our discussion of Variability the fact that
variables with the `parameter`

qualifier cannot change during a
simulation? If a variable with the `parameter`

qualifier cannot
change during a simulation and all the variables in an expression have
this parametric variability then the entire expression must also have
parametric variability (*i.e.,* the value of the expression cannot
change during a simulation).

At this point, you might be asking yourself why this unbalanced case
would be useful? Again, we are getting ahead of ourselves here, but
one use case would be the conditional application of initial
equations, *e.g.,*

```
..
parameter Boolean steady_state;
initial equation
if steady_state then
der(x) = 0;
der(y) = 0;
..
```

In other words, if the Boolean parameter `steady_state`

is true,
then the initial equations are enforced. But if the parameter is
false, they are not. The conditional expression here clearly has
parametric variability because the expression contains only a variable
and that variable is a parameter.

That’s all we’ll say on this topic for now, since discrete and conditional behavior will be discussed in detail in the next chapter.