I once faced a problem where Simulink reported, “Cannot solve algebraic loops...”

Algebraic loops can be solved by Simulink, but often slow down the simulation. For this reason, we have the algebraic loop diagnostic that can be set to Error, Warning or None. What was peculiar about this model was that the algebraic loop diagnostic was set to Warning, yet the model would report an error, and not simulate! To makes things more difficult, all I had to work with was a screen shot of the model, not the model it self.

What are algebraic loops?

Algebraic loops exist when a variable shows up on both sides of the equation. For example,

Algebraic loops generally occur in Simulink when there are un-modeled delays, for example, sensors that just feed through a signal from input to output.

Read the error message

The first step in debugging a problem like this is to read and understand the error message. Algebraic loop errors occur for different reasons. To understand the cause of the error I had to understand the message.

Cannot solve algebraic loop involving 'model/.../Sensor System' because it consists of blocks that cannot be assigned algebraic variables, i.e., blocks with discrete-valued outputs, blocks with non-double or complex outputs, Stateflow blocks, or nonvirtual subsystems.

Picking apart this message, we learn that Simulink cannot solve algebraic loops unless it can assign an algebraic variable. The blocks that cannot be assigned algebraic variables are listed in the error.

• Discrete-valued outputs, like logic blocks [0 or 1]
• Blocks that have non-double outputs
• Blocks that output complex values (3+2i)
• Stateflow blocks
• Nonvirtual subsystems

Figure out how the message relates to the model

Next, I looked at the screen shot and see if I could find those blocks. This is roughly similar to the screen shot sent to technical support:

The first thing I noticed was that all the signals are of type uint8. Those are non-double types, so that could be part of the problem. Another thing I noticed was the heavy lines on the subsystems. That means these are atomic subsystems. Atomic subsystems are nonvirtual, and those are on the list of blocks that could cause this problem.

Possible Resolution

Because these were atomic subsystems, I suggested enabling the Minimize algebraic loop occurrences optimization.

The subsystem can be thought of a function of its inputs and states

In some systems, the output signal calculations do not directly rely on the inputs. If this is true, you can separate the system into two equations.

This option is also available for model reference blocks through the configuration parameters on the Model Referencing entry.

How did this happen?

This model was the result of integrating components from many different teams. The original model contained virtual subsystems, and the new components used to upgrade the model were atomic subsystems. Switching back to virtual might have resolved this error also.

The algebraic loop diagnostic did not control this error because this was part of the check for the minimum solvability requirements for this type of problem.

Now it’s your turn

There is additional information in the technical support solutions on understanding algebraic loops, and how does Simulink solve them. Have you encountered this error? How did you work around it? Leave a comment here about your experience.