Errors in the selection of start attributes within alias variable sets

[casella]

Please run the PowerGrids.Electrical.Test.OneBusTransmissionLineOneLoad test case from the attached library. I get the following warning:

Translation Warning
Alias set with conflicting start values
 * Candidate: transmissionLine.portB.i.re(start = -577.3502691896258, confidence number = 9)
 * Candidate: loadPQ.port.i.re(start = -577.3502691896258, confidence number = 9)
 * Candidate: transmissionLine.portA.i.re(start = 577.3502691896258, confidence number = 9)
=> Select value from transmissionLine.portA.i.re(start = 577.3502691896258) for variable: transmissionLine.iB.re

There are two fishy things in here. First of all, the start attribute of loadPQ.port.i.re, which is loadPQ.port.iStart.re, should be +577.35, not -577.35. In fact, the value of that parameter is correctly reported in the variable broser as being +577.35, but for some reason it gets the wrong sign in the alias set start attribute selection. The other two reported start attributes are correct.

Secondly, I'm not sure why the start attribute of transmissionLine.portA.i.re is selected to initialize the alias variable transmissionLine.iB.re, which is among the tearing variables of the system. That could be ok, but then, as the two values sum to zero in the alias set, the initial guess value for transmissionLine.iB.re should be -577.35; unfortunately, turning on LOG_NLS_V reveals that the initial guess value is actually +577.35, and that somehow leads to a solver failure.

Both issues should be fixed for consistency and correctness. I tried to reproduce the problem on a simpler test case, but I failed, so please check this larger case out. As the model is confidential, it was encrypted with the PGP key stored on dev.openmodelica.org, as agreed.

[casella]

Encrypted library with test case

[ptaeuber]

As far as I can see, there is no issue with the alias module and the behaviour is correct.

---

First of all, the start attribute of loadPQ.port.i.re, which is loadPQ.port.iStart.re, should be +577.35, not -577.35.

The printed start values for the alias variables are the start values the chosen alias variable would adopt.
I figured out the following equality chain:

transmissionLine.iB.re = transmissionLine.portB.i.re = transmissionLine.terminalB.i.re = transmissionLine.portA.i.re = transmissionLine.iA.re = -loadPQ.terminal.i.re = -loadPQ.port.i.re

So variable transmissionLine.iB.re would adopt the negative start value of loadPQ.port.i.re, which is -577.3502691896258.
So one alias conflict is:

transmissionLine.portA.i.re (start=+577.350) = -loadPQ.port.i.re (start=+577.350)

---

Secondly, I'm not sure why the start attribute of transmissionLine.portA.i.re is selected to initialize the alias variable transmissionLine.iB.re, which is among the tearing variables of the system.

The selection of the alias variable is done by the confidence number. As all of them have the same value, the first (or last) one in the list is chosen. This behaviour should be improved when the new Frontend provides the "real" confidence numbers (see #4603).
Whether a variable might become an iteration variable is not known at that point of the compilation, because alias elimination is performed way before the tearing module (and even before matching/sorting). So this property cannot be taken into account.

---

That could be ok, but then, as the two values sum to zero in the alias set, the initial guess value for transmissionLine.iB.re should be -577.35;

As you can see in the above equality chain the two variables transmissionLine.iB.re and transmissionLine.portA.i.re do not add up to zero, they are equal to each other.

To avoid the selection of that bad alias start value, the start value has to be changed (resolve the conflict).

[casella]

Sorry for wasting your time, there was a stupid copy&paste bug in my Modelica code, so the equality chain was wrong. After fixing that, everything works fine.

I have one comment though, which relates to this experience. The transformational debugger allows to trace the solved equations in the runtime code all the way back to the original Modelica code. Unfortunately, alias variables and alias equations do not show up there, so it is not possible to trace them back.

In this specific case, I knew from the physics that the equality

transmissionLine.terminalB.i.re = transmissionLine.portA.i.re

that you figured out was wrong, because the currents entering from the two sides should sum to zero, and it was not too difficult to spot the few places in the source code where the error could have been and eventually track it down. However, in general

• I have no idea how to "figure out" these equalities myself
• I could not trace from where these equalities come from in the source code

@sjoelund.se, is there any way to add alias equations and variables to the debugging experience?

[pierre.haessig@…]

For the reference, I created a ticket about @casella comment on alias variable missing in Transformational Debugger https://trac.openmodelica.org/OpenModelica/ticket/5922