Opened 9 years ago
Closed 9 years ago
#3187 closed defect (fixed)
boolean_array index assertion failed
Reported by: | rfranke | Owned by: | somebody |
---|---|---|---|
Priority: | high | Milestone: | 1.9.2 |
Component: | Backend | Version: | trunk |
Keywords: | Cc: | mahge930, lochel |
Description (last modified by rfranke)
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?
Change History (13)
comment:1 Changed 9 years ago by rfranke
- Description modified (diff)
comment:2 Changed 9 years ago by adrpo
comment:3 Changed 9 years ago by adrpo
- Resolution set to fixed
- Status changed from new to closed
Test using PowerSystems.Examples.Spot.AC1ph_DC.Inverter simulation added in r24893.
comment:4 Changed 9 years ago by mahge930
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 :)
comment:5 Changed 9 years ago by adrpo
No problem Mahder, you can fix #3188 :)
comment:6 Changed 9 years ago by mahge930
- Cc lochel added
- Resolution fixed deleted
- Status changed from closed to reopened
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.
comment:7 Changed 9 years ago by adrpo
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.
comment:8 Changed 9 years ago by rfranke
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
comment:9 Changed 9 years ago by adrpo
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.
comment:10 Changed 9 years ago by adrpo
The new failures should be fixed by r24961. I will re-run the library coverage and see where we are before closing the ticket.
comment:11 Changed 9 years ago by mahge930
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.
comment:12 Changed 9 years ago by adrpo
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).
comment:13 Changed 9 years ago by mahge930
- Resolution set to fixed
- Status changed from reopened to closed
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.
Should be fixed in r24892. I'll add a test for it to be sure and then close the ticket.