Question

Can anyone give me a hint what “algebraic loop” means — and how I am supposed to cope with this situation by adding “pre”-operators? I’m seriously not getting it…

Error: Failed to generate code for an algebraic loop
involving when equations or algorithms with when parts.
Unknowns:
  pump.Hb_flow
  pump.medium.d
  pump.medium.h
  pump.medium.state.melting
  pump.medium.state.T
  pump.V_flow
  pump.V_flow_single
  pump.W_single

Equations:
  algorithm 
    when Modelica.SIunits.Conversions.to_degC(pump.medium.state.T) < 13.9 then
      pump.medium.state.melting := true;
    elsewhen Modelica.SIunits.Conversions.to_degC(pump.medium.state.T) > 32.8       then
      pump.medium.state.melting := false;
    end when;
  // [removed set of equations that contained no "when"]

You may be able to cut the loop 
by putting 'pre' around some of the references to
unknown continuous time variables in when parts or when conditions.

Thanks in advance,
best regards

TIMO.

Answer 1

This problem is, in general, because the equations within the when clause impact the conditional statement that triggers them.

The thing that you need to understand with Modelica is that a solver will evaluate equations using “candidate solutions” as part of the simulation process. These are not necessarily the solution it will eventually choose, but it nevertheless needs to evaluate them as it approaches the eventual solution.

How is this related? Well in your case I see that you are changing the value of a “melting” variable. But if that value then influences the medium temperature (which triggered the change in the value of “melting”) then the tool will detect an inconsistency in the system of equations. A tool might be able to iterate to find a consistent candidate solution, but Dymola just “punts” and says it doesn’t support such situations.

Now, the important thing to understand here is that basically this is usually all irrelevant. Why? Because for the most part user’s really don’t want the default semantics of when clauses in such cases. What most users want is to treat the condition in the when clause as a “cause” and the equations inside the when clause as an “effect”. In this sense, they are sequential and the effect should not turn around and affect the cause (although the White Stripes wrote a great song about such situations ;-)).

The general pattern here is to isolate the condition and then add a “pre” operator around it in the when clause. If the original model looked like this:

model Test
...
equation
  when x>12.5 then
    // equations involving y
  end when;
  // equations coupling x to y
end Test;

You just need to refactor the model into something like this:

model Test2
...
  Boolean cond;
equation
  cond = x>12.5;
  when pre(cond) then
    // equations involving y
  end when;
  // equations coupling x to y
end Test;

The essential thing here is that the equations involving y only come after the condition is true. The ‘pre’ in this case basically says that if, at current time minus some epsilon, the value of condition was true then (in response) the equations in the when clause kick in.

Such situations can lead to a condition called “chattering” where the value of the condition flips for every “epsilon” of time that passes, but this means that the problem is not well posed.

I hope this makes some sense. I admit that in complex cases, it can be hard to detect exactly where the algebraic loops exist (although Dymola tries to give you some diagnostics). Also, in some cases you do want the default behavior of Modelica so you don’t always want to add gratuitous ‘pre’ qualifiers.

Let me know if you have any questions on this explanation.