boolean_array index assertion failed

[Rüdiger Franke]

Today five simulations fail for the PowerSystems library that worked so far:

PowerSystems.Examples.Spot.AC1ph_DC.Inverter
PowerSystems.Examples.Spot.AC3ph.Inverter
PowerSystems.Examples.Spot.InvertersAC1ph_DC.InverterToGrid
PowerSystems.Examples.Spot.InvertersAC1ph_DC.InverterToLoad
PowerSystems.Examples.Spot.InvertersAC3ph.InverterToLoad

They all produce the same simulation error:

PowerSystems.Examples.Spot.AC1ph_DC.Inverter: util/boolean_array.c:387: index_boolean_array: Assertion `j == dest->ndims' failed.
Aborted

Is this related to r24887?

[Adrian Pop]

Should be fixed in r24892. I'll add a test for it to be sure and then close the ticket.

[Adrian Pop]

Test using PowerSystems.Examples.Spot.AC1ph_DC.Inverter simulation added in r24893.

[Mahder Alemseged Gebremedhin]

Seems like I was late to this. Thanks for fixing it Adrian.
I promise I will check PowerSystems after commit every morning from now on :)

[Adrian Pop]

No problem Mahder, you can fix #3188 :)

[Mahder Alemseged Gebremedhin]

I don't know if you have noticed but now we have 38 models failing (+16 from yesterday).
There are no compilation problems anymore and it seems all the models failing are because of assertion failures in initialization. More or less the same error messages for all models. Plus all the models failing are from PowerSystems.Examples.Spot package. so they are probably caused by the same piece of code.

This is good in a sense because we can now better locate the issue and maybe it can help fix other models with the same issue.

[Adrian Pop]

Mahder, I think the simulation issues have to do with #3186 as we're missing some of the bindings in record sub-components and because of that we get uninitialized records.

[Rüdiger Franke]

All the Inverter models fail again. Additionally some more models failed today that worked so far, e.g.:

PowerSystems.Examples.Spot.AC3ph.Breaker
PowerSystems.Examples.Spot.AC3ph.Fault
PowerSystems.Examples.Spot.AC3ph.Impedance
PowerSystems.Examples.Spot.AC3ph.ImpedanceYD

I think it's not related to #3186. It must be something new introduced yesterday. All produce the same error message:

assert            | debug   | No system for the symbolic initialization was generated.
assert            | info    | simulation terminated by an assertion at initialization

[Adrian Pop]

I think i found what the problems are with the new failures.
It seems to be r24947 the changes to SimCodeUtil.mo, especially SimCodeUtil.createSingleArrayEqnCode
because we get messages like:

"[Compiler/SimCode/SimCodeUtil.mo:6306:7-6306:48:writable] Error: Internal error for Eqn: 1 : {$DER.ind.i[1], $DER.ind.i[2], $DER.ind.i[3]} = PowerSystems.AC3ph.Impedances.Inductor$ind.j_dq0({ind.i[1], ind.i[2], ind.i[3]}) * ind.omega[1]
array equations currently only supported on form v = functioncall(...)

I have a fix for it, I'm running the testsuite now to see if I don't break anything else.

[Adrian Pop]

The new failures should be fixed by r24961. I will re-run the library coverage and see where we are before closing the ticket.

[Mahder Alemseged Gebremedhin]

Adrian I added that cref check speicifically. I thought the case above the one you just fixed should take care of the non-cref cases. Because we need to generate TMP variables for them. Shouldn't the errors here have been handled by the case above it?

The thing is you might not always have the full array in the lhs. It might as well be something like

{a, b, c} = fcall();

or

{a[1], a[3]} = fcall();

instead of

{a[1], a[2], a[3]} = fcall();

What do you think? I can't start now but I will have a look later in the afternoon.

[Adrian Pop]

No. The case above can only handle arr = fcall(); but the equation is der(array) = fcall() * some_other_array; which was handled by the second case.

The problem with the check is that it wasn't there before and equations of the form der(array) = fcall() * some_other_array; started to fail after the check was added.

Please have a look and fix it as you like (you might need to resurrect some cases you removed in r24947).

[Mahder Alemseged Gebremedhin]

Okay this issue should be fixed in r24970. Now we should be able to handle

{a, b, c} = anyexp;

and

{a[1], a[2], a[3]} = anyexp;

properly.